Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Jetty 9 + Websocket Modules

I think the breakdown is fine like this....we just don't want to creep
beyond these 5 websocket-* artifacts so they need to be able to hold a
the implementation bits behind that jsr356 in a sane meaningful way.

I foresee another couple of milestone releases (one monday and another
in 2 more weeks) so now is the time to get these changes moving.

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx


On Thu, Nov 1, 2012 at 12:56 PM, 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
>


Back to the top