Enterprise Client Community

Are there any plans to support jsf 2.2?

What looks most interesting for us is the item described in http://jdevelopment.nl/jsf-22/#949, namely to identify a particular window with a ClientWindowId thus making it more easy to support scenarios where several applets are open concurrently by one user, a thing which regular conflicts with the browser's policy that cookies (and thus sessions) are shared among all windows.

Manfred

Hi,

two fast responses first, not to confuse "others":

1. in general of course you can use the 2.2 api/implementation for CaptainCasa as well. We did test CaptainCasa with it and did not find problems.

2. CaptainCasa by default opens up an own http session for each "window" (if it's a webstart window, an applet started in a tab). Even by default, two CaptainCasa applets running in one HTML page (if this makes sense...) are running in separate sessions. So the problem that is described in the link is typically not a problem at all with CaptainCasa. Background of this is that we internally do not use cookies for session management - just because of all the problems involved, but we use URL-sessionid-encoding.

This means, your question only is applicable, when using CaptainCasa in a special mode to take over an existing session - and not open up an own session instance. (If I do mis-interpret you, please tell me!). Only in this case, CaptainCasa on server side lives in the normal session management (e.g. based on cookies) because the application calling CaptainCasa decided to do so.

Here it could make sense, to deeply look into what you sent as link. We did not do this so far... Please give us some time...

Regards, Björn

You are right, this is not using standard captain-casa url-session-encoding, our special usecases come from embedding captainCasa screens in other applications, using either applets, or even plain html with captain-casa HT controls.

We do not object against having the same session here, in some of our usecases this is even the desired mode of operation, since e.g. user authentication (SSO) frameworks rely on this.
But then all JSF expressions run in the same "namespace" (meaning: #{d is the identical object for roundtrips from all screens) and it requires nasty tricks to keep view state distinct. From briefly looking at the new jsf2.2 feature mentioned here it looks promising to get rid of such tricks.

...@"looks promising": I definitely agree!
...@"HT controls": I somehow missed them in my explanations ;-)

Björn