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.
--
Developer advice, services and support
from the Jetty & CometD experts
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev
