On Dec 18, 2015, at 1:02 PM, Edward Burns <edward.burns_at_oracle.com> wrote:
>
>>>>>> On Wed, 16 Dec 2015 20:55:37 +0100, Bauke Scholtz <balusc_at_gmail.com <mailto:balusc_at_gmail.com>> said:
>
> B> While developing and testing the o:socket I wasn't satisfied with how WS
> B> session and HTTP session interacted with each other (among others, HTTP
> B> session timeout doesn't trigger a re-handshake of the WS session, causing
> B> its endpoint config to still refer the old HTTP session), so I have further
> B> improved the o:socket to be less dependent on that and made even more
> B> Portlet friendly as there are no hard javax.servlet dependencies
> B> anymore.
Thank you for considering the JSF portlet use-case by removing dependencies on javax.servlet and for avoiding dependencies on servlet-filters! :-)
>
> Yes, those two session objects are entirely disjoint, and necessarily
> so. To access the HttpSession from the WebSocket session, you must save
> it aside during the handshake. Perhaps we can make that easier so you
> can have access to it automatically?
>
> B> For security, there's currently in o:socket only a servlet filter in place
> B> which should return 400 on WS handshake requests on non-existing channels:
> B> https://github.com/omnifaces/omnifaces/blob/master/src/main/java/org/omnifaces/cdi/push/SocketChannelFilter.java <https://github.com/omnifaces/omnifaces/blob/master/src/main/java/org/omnifaces/cdi/push/SocketChannelFilter.java>.
>
> B> As this isn't Portlet compatible, I'm for Mojarra's f:socket thinking to
> B> programmatically add /javax.faces.push/* to servlet mapping and then do the
> B> job in FacesServlet instead. Would this be OK for Portlets too? Neil? Or
> B> perhaps I should append the current FacesServlet mapping to the push URL
> B> and then inspect the presence of the /javax.faces.push prefix as currently
> B> also done for /javax.faces.resource requests.
>
> This is my biggest beef with p:socket. It's a pain to set up. I'd
> really like to make it so you don't have to do any additional set up.
> We can bake this functionality straight into the FacesServlet.
Even though the FacesBridge does not make use of the FacesServlet, I am very much in favor of baking this functionality into the FacesServlet. We will simply have to make it a requirement for the FacesBridge to implement this functionality in a portlet environment, just like it does for other things like running the Faces lifecycle.
— Neil