Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Requirements for a Jakarta WebSockets Whiteboard #598

Open
wants to merge 3 commits into
base: requirements/575
Choose a base branch
from

Conversation

tcalmant
Copy link

Initial version of the requirements for the proposal of Jakarta WebSocket Whiteboard as described in #575

@stbischof
Copy link
Contributor

@tcalmant could you look for your eclipse foundation eca declaration? and you need to sign-off the commits.

@timothyjward you may could assist.

…irements

Signed-off-by: Thomas Calmant <thomas.calmant@gmail.com>
Signed-off-by: Thomas Calmant <thomas.calmant@gmail.com>
Signed-off-by: Thomas Calmant <thomas.calmant@gmail.com>
@tcalmant
Copy link
Author

@tcalmant could you look for your eclipse foundation eca declaration? and you need to sign-off the commits.

Fixed. Sorry, I used the wrong email address for ECA.

@grgrzybek
Copy link
Contributor

For the record, Pax Web 8 implements whiteboard tracker for web sockets and the details are:

@tcalmant I checked your draft specification and it roughly matches to what is available in Pax Web.
I didn't think about dedicated annotations like @WebSocketWhiteboardServletPattern - I simply used the one from JSR 356 (@javax.websocket.server.ServerEndpoint)

Also while from JakartaEE point of view, Servlets and WebSockets are different specs, in Pax Web I treated servlets (+filters, listeners, error pages, ...) and websockets in exactly the same way. With this in mind I could look at this proposal as kind of "extension" of Http Whiteboard (now Servlet Whiteboard) OSGi CMPN specification. Of course it's nice to have separate chapter. I'd simply emphasize it's kind of like Servlet Whiteboard specification got extra service to track (WebSocket endpoint class or instance).

I definitely don't feel like I should dictate here. Simply if you want, please have a look at how Pax Web implements WebSocket whiteboard-tracking already.

regards
Grzegorz Grzybek

@timothyjward
Copy link
Contributor

After today's call it feels like we're moving beyond requirement gathering. Most of the discussion was about the feasibility of implementing the requirements as written.

At the next call we should consider whether we're ready to move to the next stage (i.e. spec and design)

As for implementation, it appears that most implementations are container specific, i.e. they cannot be deployed in a generic web container. The Tyrus Servlet Container however appears to be platform agnostic. This could be suitable for a generic websocket whiteboard implementation on top of the servlet whiteboard, implemented using a Filter or similar.

Other container specific implementations could be created using the native adapters (e.g. Jetty or Undertow)

@grgrzybek
Copy link
Contributor

For Tyrus I did a quick check

  • it indeed is a standalone WebSocket server implementation
  • org.glassfish.tyrus.servlet.TyrusServletFilter is a bridge from web application (web.xml, WAR) into Tyrus
  • this filter uses org.glassfish.tyrus.servlet.TyrusHttpUpgradeHandler which deals with WebSockets protocol by taking the data directly from jakarta.servlet.http.WebConnection (and its in/out streams)
  • this filter + upgrade handler are part of org.glassfish.tyrus:tyrus-container-servlet Maven module
  • the standalone implementation is org.glassfish.tyrus:tyrus-core

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants