Re: [jetty-dev] Jetty 9 + Websocket Modules

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

RE: the jsr draft api artifact...

If there is a solid implementation out there of the drafts we can use
those but they must go through CQ before we can release with those
bits in place.  Alternatively if there isn't an api that we are
comfortable running through CQ and using then we can roll our own but
I would personally like to keep it tucked away someplace out of the
way in our maven repo.

org.eclipse.jetty.drafts:javax.net.websocket:EDR-006

something like that...it is clear from the coordinates it is a draft
and when someone looks at jetty in maven central they don't see that
javax goop

it is also provides a location for future drafts we need to roll our own of

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx


On Thu, Nov 1, 2012 at 1:11 PM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
> I was incorrect in the statement about JSR-356 apparently not having a
> Client component.
>
> I see now a javax.net.websocket.ClientContainer component that can be used
> to initiate client WebSocket connections.
>
> That would mean the following updates to the proposed module list.
>
> /javax-websocket-api/
>    stays as is.
>
> /websocket-server/
>    now has a dependency on websocket-client
>
> /websocket-client/
>    now has an implementation of the following JSR-356 apis (at least)
>    javax.net.websocket.ClientContainer
>    javax.net.websocket.ClientContainerConfiguration
>    javax.net.websocket.DefaultClientConfiguration
>
> /websocket-common/
>    now has a common set implementations for the following JSR-356 apis (at
> least)
>    javax.net.websocket.EndPoint
>    javax.net.websocket.EndPointConfiguration
>    javax.net.websocket.Decoder
>    javax.net.websocket.Encoder
>    javax.net.websocket.CloseReason
>    javax.net.websocket.SendResult
>    javax.net.websocket.DecodeException
>    javax.net.websocket.EncodeException
>    javax.net.websocket.Session
>    javax.net.websocket.extensions.Extension
>    javax.net.websocket.extensions.FrameHandler
>    javax.net.websocket.extensions.Frame
>
>
> --
> Joakim Erdfelt <joakim@xxxxxxxxxxx>
> webtide.com
> Developer advice, services and support
> from the Jetty & CometD experts
> eclipse.org/jetty - cometd.org
>
>
>
> On Thu, Nov 1, 2012 at 10:56 AM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
>>
>> There's been a few filed issues around the websocket modules that I'd like
>> to get resolved.
>> Mostly it has to do with using websockets from a webapp, with the
>> classloader in play.
>>
>> This root cause seems to be the use of Callback and FutureCallback in the
>> exposed API itself.
>> This will need to change, i'm already investigating just moving to a pure
>> Future approach with the exposed API.
>>
>> There is also the new JSR-356 (Currently in the Early Draft 006) that
>> needs to be implemented and made available for webapps to use.
>>
>> So that leads me to believe we should take advantage of the fact that we
>> are in the Milestone releases to make the hard decisions on
>> packaging/modules now, before we hit 9.0.0 final release.
>>
>> So here's my plan, I'd appreciate anyone picking apart this plan (so I can
>> shore up the faults in it)
>>
>> First step: the proposed module layout
>> Rationale: To break apart what goes in the webapp's WEB-INF/lib and
>> simplify what we let peek through the WebAppClassloader from the server
>> side.
>>
>> /websocket-api/
>>   org.eclipse.jetty.websocket.api.*
>>   Holds the Jetty implemented WebSocket API that can be used to create
>> either Client or Server side WebSockets.
>>   This would be a package exposed on WebAppContext's systemClasses.
>>   This MUST NOT depend on the servlet-api.
>>   This would not depend on any other module within jetty.
>>
>> /websocket-servlet/
>>   org.eclipse.jetty.websocket.servlet.*
>>   This is the servlet specific classes for using WebSockets in a standard
>> webapp.
>>   For developers wanting to use the jetty api in their webapps, this is
>> the dependency they would use for their webapp's WEB-INF/lib.
>>   It would depend on websocket-api.
>>   This would be a package exposed on WebAppContext's systemClasses.
>>   This MUST depend on the servlet-api.
>>
>> /websocket-client/
>>   org.eclipse.jetty.websocket.client.*
>>   For those wanting to implement a WebSocket client in their java
>> application, this is what we recommend you depend on.
>>   This MUST NOT depend on the servlet-api.
>>
>> /javax-websocket-api/
>>   javax.net.websocket.*
>>   This is already exposed on WebAppContext's systemClasses via the "javax"
>> namespace.
>>   This MUST depend on the servlet-api
>>
>> /websocket-server/
>>  org.eclipse.jetty.websocket.server.*
>>   Holds the jetty server side specific components, along with the server
>> specific implementation details for JSR-356 (aka /javax-websocket-api/).
>>   So far, there seems to be no client component for JSR-356, so there will
>> likely be no reason to put the implementation of JSR-356 into any other
>> component (of course, this might change as the JSR isn't done yet)
>>   This MUST depend on the servlet-api
>>
>> /websocket-common/
>>   org.eclipse.jetty.websocket.common.*
>>   Holds common classes for /websocket-client/ and /websocket-server/,
>> these classes shouldn't be exposed to the webapp, as they are really just
>> server side implementation details.
>>   This MUST NOT depend on the servlet-api.
>>   All of the protocol, I/O, and extension handling is done here.
>>
>>
>> Next, we remove from /websocket-api/ and /websocket-servlet/ any exposed
>> use of org.eclipse.jetty.* classes.  (such as Callback and Log)
>>
>> Hopefully this made sense.
>>
>> --
>> Joakim Erdfelt <joakim@xxxxxxxxxxx>
>> webtide.com
>> Developer advice, services and support
>> from the Jetty & CometD experts
>> eclipse.org/jetty - cometd.org
>>
>
>
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>