Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Jetty Websocket Impl
On Mon, Mar 3, 2014 at 10:49 AM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Joakim and Gunnar,

Thanks for your input.   I'm going to try to summarize below to figure out what to do next.

On 3/3/2014 6:01 AM, Joakim Erdfelt wrote:
<stuff deleted>

Starting with Jetty 9.1 we now support JSR-356 / javax.websocket and can function as either a client or server.

Scott, the contrib you received is for a dead-end API.  Would encourage you to either embrace Jetty 9's WebSocket API or javax.websocket.* API.

Ok.   Questions:

1) Is the javax.websocket.* api finalized/approved (is this essentially JSR-356...or are there other/competing websocket specs?).  Basically I'm just asking how likely is the spec to change over next couple of years.

JSR-356 is released as version 1.0 already.

You can find the official artifacts on maven central at:

Client API only at

Client + Server API at

The IP / CQs for these have been taken care of already

Client API only:
Client + Server API:

Note: This has confused people in the past, so I'll state it again here :)
javax.websocket is for the basic API, which is client side.
javax.websocket.server is for the server layer, which is built on-top of the client API.
It is impossible to have a server without the client API as a result.
The two artifacts you see are for different roles.  One for pure clients to use (such as android apps), the other is for everything else.

 

2) I assume from what you say Joakim that the 9.1 impl (that supports JSR-356) has jetty packages that provide impls of javax.websocket.   I don't know the JSR-356 spec [yet]...so I don't know what's appropriate...but are the jetty packages referenced directly by client code? (i.e. exported).  Or does client code only use javax.websocket?

Client code would only use javax.websocket API, no Jetty specifics.
The jetty specific implementation would be found via the javax.websocket.ContainerProvider techniques.

Hint: it uses ServiceLoader
 

3) I also assume that for the 9.1 API that the client and server/servlet are separated...at the package level and at the bundle level?

I'll look into the 9.1 api myself to answer 2 and 3...but this then leads to the important question...given Gunnar's post:

For the Jetty API yes, for the javax.websocket API no (see above).



Not sure if you know but Jetty left the release train repo. However, they are still in the repo because Gyrex includes them and will continue to contribute them to the repo. For Luna it will likely be 9.1 or higher. But AFAIK Equinox HttpService still requires Jetty 8.

What is the plan for Luna WRT Jetty version in Equinox+Eclipse (HttpService impl, help, etc)?    Will it be Jetty 9.1, 9.0, or Jetty 8, or some other version?  This may be a question more for Equinox than for you/Jetty team...I don't know how such things are decided.  I see from looking at org.eclipse.jetty.* in I20140227 integration build that it's currently 8.1.14.   If it's going to change (to 9.1 or something else), then when is that scheduled to happen?

We exited the release train for a number of reasons.
Our release schedule is more demanding than the Eclipse release cycle (and it never synchs or lines up nicely for either side).
Our active development is on Servlet API 3.1, which means we have a minimum JDK requirement of Java 7 (forcing this requirement on the rest of eclipse was undesired, so we stepped out)
We have no OSGi or P2 developers. (we have a jetty-osgi module that is unmaintained and has undergone several votes this past year for removal.)
The demand for OSGi this and that comes nearly exclusively from other Eclipse projects, hardly ever any external projects.

 

Obviously, if we are going to release this new websocket-based remote services provider in Luna (that's our plan), then ideally we would use the 9.1/javax.websocket API (not dead end)...and hope that it's stable/standardized...but if 9.1 is not planned/not going to be in Luna, then that's a tougher choice.

Can't speak for the Luna point of view, but the WebSocket API in Jetty 9.1 feels stable enough (so far).
We have a few requests for features in the API surrounding PING/PONG/FRAME access, but that's rather low level and we are looking for a minimal approach to allow them.

 

Thanks,


Scott

- Joakim 

Back to the top