I googled a lot for this problem before posting this question and Accessing HttpSession from HttpServletRequest in a Web Socket @ServerEndpoint is one of the best Questions/Answers I was able to found, but it appears to not solve my problem.
I was able to access HttpSession from websocket in this way, but I can't access the same CDI session bean instances as from normal HTTP requests.
I tried to store in session the HttpSessionContextImpl
Weld instance too and tried to use it on WebSocket side, but it didn't expose previous beans.
Then my question: Is it possible to access the same CDI managed session bean instances in both cases (WebSocket events and HTTP normal requests)?
At the moment it is important for me to have this feature working in Wildfly 9/10, but it would be great to have a general solution working for example on Tomcat > 7 too (using jBoss Weld or any other implementation).
Thanks in advance for your support.
Then my question: Is it possible to access the same CDI managed session bean instances in both cases (WebSocket events and HTTP normal requests)?
Only during the handshake request, because that's a HTTP request. The HTTP session is only available during a HTTP request, not during a WS request. Hopefully the reason is by now obvious as CDI stores session scoped beans in HTTP session which is only identifiable by a HTTP request, and during a WS request there's no means of a physical HTTP request anywhere and therefore HTTP session is also unavailable.
Your best bet is generating an unique identifier, store it in a session scoped bean, add it to the WS URL (as either path or request parameter), extract it during onOpen
and store it in an application scoped bean. In normal Java EE servers, application scoped CDI beans are available via @Inject
in a WS endpoint class the usual way (but not in Tomcat/Jetty/etc, you'd have to manually grab it via BeanManager
). Finally, just let the session scoped bean containing the unique identifier consult the application scoped bean for any opened sockets by that identifier.
At least, I went this path while developing the OmniFaces <o:socket>
tag for JSF. It's all open source, you can find source code links at the bottom of its showcase page.