JSF 2.3 fails to support WebSocket with Jetty 9.4.7

[ren-zhijun-oracle]

I tried to test new WebSocket feature with JSF 2.3.3(Glassfish implementation). I used Jetty 9.4.7 as web server and followed this guide(https://javaserverfaces.github.io/whats-new-in-jsf23.html)

I created a managed bean:

    @Named
    @ApplicationScoped
    public class Controller {

        @Inject @Push
        private PushContext cityChannel;

        public void send() {
            cityChannel.send("test");
        }
    }

updated index.xhtml:

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
    xmlns:ui="http://java.sun.com/jsf/facelets"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:f="http://java.sun.com/jsf/core"
    template="/WEB-INF/layout/standard.xhtml">

    <ui:define name="content">
        <f:websocket channel="cityChannel"
            onmessage="function(message){alert(message)}" />
    </ui:define>
</ui:composition>

updated web.xml:

    <context-param>
        <param-name>javax.faces.ENABLE_CDI_RESOLVER_CHAIN</param-name>
        <param-value>true</param-value>
    </context-param>
    <context-param>
        <param-name>javax.faces.ENABLE_WEBSOCKET_ENDPOINT</param-name>
        <param-value>true</param-value>
    </context-param>

And created fake endpoint:

public class FakeEndpoint extends Endpoint {
    @Override
    public void onOpen(Session session, EndpointConfig config) {}
}

Jetty starts up properly but when I open index.xhtml I get a lot of error messages like that:

java.lang.NullPointerException at com.sun.faces.cdi.CdiUtils.getBeanReferenceByType(CdiUtils.java:222) at com.sun.faces.cdi.CdiUtils.getBeanReference(CdiUtils.java:205) at com.sun.faces.push.WebsocketSessionManager.getInstance(WebsocketSessionManager.java:240) at com.sun.faces.push.WebsocketEndpoint.onOpen(WebsocketEndpoint.java:88)

So the issue is that WebsocketSessionManager bean cannot been found. And WebSocket feature is not available.

Thanks.

[ren-zhijun-oracle]

• Issue Imported From: https://github.com/javaserverfaces/mojarra/issues/4306
• Original Issue Raised By:@sergey-morenets
• Original Issue Assigned To: Unassigned

[ren-zhijun-oracle]

@sergey-morenets Commented I made small investigation effort and it turned out that WebsocketSessionManager cannot be found because this code is run in the separate thread created by Jetty(not connected to JSF lifecycle) and FacesContext is null.

[ren-zhijun-oracle]

@arjantijms Commented A small comment: "FakeEndpoint" is typically only needed for Tyrus based Websocket implementations and not a general requirement for the feature.

[ren-zhijun-oracle]

@sergey-morenets Commented Hi @arjantijms

Thank you for the comment. Unfortunately issue reproduces even if I remove this FakeEndpoint

[ren-zhijun-oracle]

@arjantijms Commented That's indeed expected, just wanted to mention that the FakeEndPoint is by far not always needed, but when it's there it shouldn't hurt either. @BalusC is the one most up to date with the actual specifics of what might go wrong here.

Thanks for the report btw! ;)

[ren-zhijun-oracle]

@edburns Commented Please see this important message regarding community contributions to Mojarra.

https://javaee.groups.io/g/jsf-spec/message/30

Also, please consider joining that group, as that group has taken the place of the old dev@javaserverfaces.java.net mailing list.

Thanks,

Ed Burns

[Edwardiv1]

I also have this exact problem using Tomcat 8.5 and JSF 2.3.

[sergey-morenets]

I also have this exact problem using Tomcat 8.5 and JSF 2.3.

@Edwardiv1 The next month Jakarta EE 9 (with JSF 3.0) will be released. I guess we can try to check this issue on the latest RC.

[arjantijms]

As per the above comment, the activation of WebSocket was problematic. At the time Tomcat just seemed to did the right thing, but maybe something changed here. For Tyrus (Eclipse WebSocket implementation) I kinda hacked support for it in as per this code:

https://github.com/eclipse-ee4j/mojarra/blob/master/impl/src/main/java/com/sun/faces/config/FacesInitializer.java#L190

For EE 10 we have the first opportunity to handle this in a spec compliant way. For Mojarra, if needed, we would have to resort to extra hacks.

[Edwardiv1]

Is there any update on how to handle this? Does JSF 3.0 work? I'm still having this issue, now with Tomcat 9.0 and JSF 2.3

[mnriem]

For Mojarra 2.3 and earlier please contact your vendor for support (RedHat, IBM, Oracle, Omnifish, Payara, etceteras)