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:
https://web.liferay.com/web/cristina.gonzalez/blog/-/blogs/define-websocket-server-endpoints-using-liferay-websocket-whiteboard
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,
Neil