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 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>
Developer advice, services and support
from the Jetty & CometD experts



Back to the top