We built some non-trivial WebSocket abstractions around Jetty 8's WebSockets. I found the API to be intuitive since it matched RFC 6455 pretty closely. We have been delaying an upgrade to Jetty 9 because it appears to be a lot of effort to rewrite our WebSocket library based on the new Jetty WebSocket abstractions.
If you don't mind helping out, I would love to share a bit of how we use Jetty and to try to come up with a reasonable path for migration to Jetty 9. I apologize in advance for the length of this email, but this is a pretty large system.
The quick summary is that there are three changes that are giving us the most trouble:
* The WebSocket.OnFrame interface, with the ability to return false in order to delegate to Jetty's usual handling. There appears to be no comparable mechanism in Jetty 9's WebSockets' annotated methods.
* Changing WebSocket.Connection to a Session callback parameter. It's unclear whether I can use the Session outside the scope of a callback method.
* The WebSocketServlet's doWebSocketConnect(HttpServletRequest req, String protocol) method. We actually passed off the `req` to Spring in order to make our mapped method calls, and we can no longer do this very easily, as Jetty 9 no longer passes an HttpServletRequest.
The (simplified) detailed usage follows:
We use Spring @RequestMapping-annotated methods for our HTTP requests, and I created a similar abstraction for WebSocket. To use a WebSocket, one can define a method like this in a @Controller-annotated class:
@WebSocketMapping("/upload/receiveFiles.ws")
public WebSocketHandler receiveFiles(
@ModelAttribute("user") User user,
@RequestParam("upload") int uploadId) {
return new FileUploadHandler(...);
}
A WebSocketHandler is internally defined, providing the following fields and methods: