Hello Pax Web 8 has indeed a refactored mechanism for WebSocket handling - it's now much more close to JSR 356.
But the attribute should be there if you install proper websocket bundles. Which Karaf features did you install? There's special pax-web-jetty-websockets feature which installs 7 Jetty bundles for websockets. And javax-websocket-server-impl-9.4.50.v20221201.jar contains /META-INF/services/javax.servlet.ServletContainerInitializer which declares org.eclipse.jetty.websocket.jsr356.server.deploy.WebSocketServerContainerInitializer SCE which should properly install your endpoints. And definitely - Pax Web has to have custom implementation of ServletContext! However you're right - Pax Web 8 doesn't explicitly tests Spring's mechanism for WebSocket publishing... regards Grzegorz Grzybek pt., 24 lut 2023 o 23:59 [email protected] <[email protected]> napisał(a): > I am in the process of upgrading from pax web 7.3.9 to 8.0.6 and have > discovered issues with regard to spring integration with web sockets in > version 8 of Pax Web with Jetty. I have been using the > ServerEndpointExporter > <https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/socket/server/standard/ServerEndpointExporter.html> > APIs > in spring to register my web socket beans with Jetty and that was working > fine with version 7 of pax web. However, with the major refactor that > occurred in version 8, that spring integration does not appear to be > working anymore. It looks like the underlying ServletContext implementation > was changed and that due to that, the WebSocketInitializer is not getting > triggered any longer and therefore the ServerContainer is no longer being > assigned as an attribute in the servlet context with a key of > "javax.websocket.server.ServerContainer", which is how it is located by > spring in the exporter class. Was this change in behavior intentional? If > so, what is the correct way in pax web 8 to integrate with the > ServerEndpointExporter APIs. Thanks. > > -hs > > On Friday, July 30, 2021 at 7:19:40 AM UTC-5 [email protected] wrote: > >> Hello >> >> I'd like to share great news about Pax Web 8 state. >> >> For last few days I was working on tiny, single test related to >> Whiteboard-registration of WebSockets... >> >> Normally (WAR) websockets are registered by some >> ServletContainerInitializer based ONLY on the classes passed to >> SCI.onStartup() and scanned using (usually) the information like this: >> >> @HandlesTypes({ >> ServerEndpoint.class, >> ServerApplicationConfig.class, >> Endpoint.class >> }) >> >> WAR scenario in Pax Web 8 was easy - simply an existing SCI (or custom >> one for Undertow) was sufficient. >> >> The problem was the dynamics of Whiteboard approach. What should happen >> when you simply "add a websocket"? >> Pax Web 7, when registering a websocket was adding an SCI to be invoked >> at (re)start time of the target (Jetty, Tomcat, Undertow) context. So easy >> calculation - 10 websockets == 10 SCIs. >> >> This fact made me think wider - how restarts and SCIs should be handled? >> >> I got back to most trivial question - how many ways there are to register >> a servlet? In Pax Web case there are FIVE: >> >> 1. webcontainer.registerServlet() >> 2. Whiteboard registration of javax.servlet.Servlet service >> 3. an SCI may invoke servletContext.addServlet() >> 4. a ServletContextListener may invoke servletContext.addServlet() >> 5. an Undertow extension may add additional servlets to DeploymentInfo >> >> the same is for filters and listeners (except that a >> ServletContextListener can't register more ServletContextListeners) >> >> So when we register and SCI that registers a websocket we want it to be >> run, right? so we effectively want to "restart a context". But (and that's >> what I was working on during last 3 days): >> >> - we *don't want* to lose servlets/filters/listeners registered >> previously through Whiteboard/HttpService >> - we *want* to lose the servlets/filters/listeners registered by SCIs >> and ServletContextListeners, because if we call them again, we don't want >> conflicts! >> - we *want* to clear the context attributes that could've been set by >> SCIs/ServletContextListeners before, because that's how SCis "mark" the >> context as processed - leaving there some flags that prevents them from >> doing some tasks more than once >> >> And finally I have a working scenario: >> >> - an SCI is Whiteboard registered and calls sc.addFilter() in >> onStartup() >> - a ServletContextListener is Whiteboard registered and calls >> sc.setAttribute() and sc.addServlet() in contextInitialized() >> - a servlet is Whiteboard registered >> - a filter is Whiteboard registered >> - a WebSocket (1) is registered by instance >> - a WebSocket (2) is registered by class >> - a WebSocket (2) is unregistered >> >> In between the registrations, GET requests are performed to check the >> expected behavior - *and everything works consistently across all 3 >> container runtimes!* >> >> And yes - I added the possibility to register actual WebSocket instance - >> Pax Web 7, even if you've registered a @ServerEndpoint-annotated object as >> WebSocket, was simply taking its getClass() and was using this class >> (instantiated later by actual runtime). >> >> And what's more - even if you register/unregister more WebSockets, >> single, dedicated SCI is used to (re)register all needed WebSockets! >> >> I hope the actual 8.0.0.GA is finally coming. >> >> kind regards >> Grzegorz Grzybek >> > -- > -- > ------------------ > OPS4J - http://www.ops4j.org - [email protected] > > --- > You received this message because you are subscribed to the Google Groups > "OPS4J" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ops4j/fb3b3c75-e0a8-4179-8463-759904423333n%40googlegroups.com > <https://groups.google.com/d/msgid/ops4j/fb3b3c75-e0a8-4179-8463-759904423333n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAAdXmhqW66fdXEFbgDZ9Zy5daCf5%2B56zue1PdUupoCuCHs0yVA%40mail.gmail.com.
