Join GitHub today
Support for WebSocket messaging [SPR-9356] #13994
The WebSocket protocol has been standardized by the IETF and the WebSocket API is almost standardized by the W3C. A number of Java implementations have become available including servlet containers like Jetty and Tomcat. The Servlet 3.1 spec JSR-340 will likely define the initial WebSocket upgrade request while JSR-356 will define a Java-based WebSocket API.
WebSockets results in a messaging-style architecture, in contrast to a REST-based HTTP architecture, and is arguably much more usable with some additional protocol like XMPP, AMQP, STOMP, etc. There are plans to support it in Spring Integration but there is also room for such support in web applications, support on which Spring Integration could potentially build upon.
If you'd like to see such support added please comment on specific uses cases (or experiences) and requirements for using the WebSocket protocol in a web application. Keep in mind the WebSocket protocol is full duplex and support should be usable on both the client and the server side.
50 votes, 60 watchers
Fran Serrano commented
I guess for Spring 3.2 the team had already enough things to consider it worth a release.
Bjorn Harvold commented
I built a gaming system using Jetty 7.x and CometD 2.x (with Spring). It's an ok stack to work with but there is a lot of room for improvement. Authentication. More control over the json marshaller. Overall, a tighter integration with Spring and Spring Security would make it feel like you weren't working on supporting 2 different controller layers with different requirements.
Rossen Stoyanchev commented
Bjorn Harvold, thanks for sharing your experience. Cometd provides a number of options for plugging in authentication and authorizations. Were those extension points insufficient or was it just the lack of Spring Security integration? Also what do you mean with the "2 controller layers"? Are you referring to having Spring MVC controllers side by side with Cometd messaging? Thanks for your feedback.
Bjorn Harvold commented
Yes, it's the lack of Spring Security integration. You kinda have to roll your own which I ended up doing by grabbing the Spring Security session from ThreadLocal inside the class that extends cometd's DefaultSecurityPolicy.
Yes, having cometd mappings and spring mvc mappings consolidated would be nice. There is no reason why they can't be unified.
Then it's the BayeuxServer creation which is a little bit of a hassle. I'd say if you're used to
Also, keeping cometd and jetty versions in sync was a bit of a problem for me. Updates kept on breaking the internals and I would have to stay put on older versions of Jetty.
All that said, the frameworks were robust enough to allow me to create a full featured game...but I am very excited to see what you guys are going to come up with.