[jsr372-experts] Re: [jsr372-experts mirror] Re: [JAVASERVERFACES-SPEC_PUBLIC-1396] f:socket for SSE and WebSocket PROPOSAL

From: Neil Griffin <neil.griffin_at_portletfaces.org>
Date: Thu, 20 Oct 2016 15:14:42 -0400

Hi Bauke,

Apologies -- as I was going through old messages, I realized that you asked me the following questions that I did not respond to:

> On Dec 19, 2015, at 8:09 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:
> Neil, as to the portlet case, as you can read above, I realized installing the security filter and endpoint unfortunately can't be done in FacesServlet itself after all. Is there something like a container initializer and context listener in portlets? Portlet has also its own concept of a servlet filter? It should just map to /javax.faces.push/* and check if that "/*" is allowed and otherwise return "bad request" error. In Mojarra, FacesInitializer is the container initializer and ConfigureListener is the context listener.

The JSR 362 EG decided that WebSocket was out-of-scope for Portlet 3.0. That means portlet container implementors would need to provide implementation-specific support for WebSocket. For example, Liferay's support is based on JSR 356 in an OSGi environment:

That also means that WebSocket will be out-of-scope for any successor to JSR 378, which would be for Portlet 3.0 + JSF 2.3.

However, the FacesBridge RI might be able to provide an SPI along with some implementation-specific functionality that makes f:websocket work in specific portlet containers.

Regarding your question about container initializers -- since a portlet application is deployed as a WAR in its own servlet context, ServletContainerInitializer can be used in a portlet environment. The com.sun.faces.tyrus.WebsocketInitializer class will be a helpful guide to us in the future.

Regarding your question about filters -- the Portlet API has a PortletFilter feature, but the filter-mapping is not based on a url-pattern.

Best Regards,