Hi Manfred -
Unfortunately I don't have much time to discuss now (more time next
week), but I wanted to suggest that we strongly consider re-parenting
the Flash implementation on top of the HttpSession instead of
re-inventing session-like functionality on top of Application.
We've discussed this on the expert group more than once, though I could
only locate this thread in the archives:
https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2011-04/message/37
Arjan mentioned this in the issue tracker as well, along with some words
of caution:
> arjan tijms added a comment - 16/Feb/12 12:35 PM
>> Another solution could be to (optionally) store flash data in the
>> HTTP session and thus piggyback on the security of the JSESSIONID.
>
>
> I just noticed the same thing was proposed as a solution for
> JAVASERVERFACES-1449, but as it appears some users are strongly
> against ever using the session for flash data:
>
>> I just contacted my user advocate at Garmin corporation, who
>> advocated for a
>> "never use the session" option for the flash. I'll try to get a quote
>> from them to
>> sway the EG.
I don't remember seeing the follow up from this.
The case for avoiding HttpSession use would have be extremely compelling
given that doing so means re-implementing much of the functionality
provided by HttpSession at the JSF layer. JSF should be leveraging the
underlying platform rather than replacing bits of it.
Arjan
Andy
On 5/21/13 3:38 PM, Manfred Riem wrote:
> Hi all,
>
> We are about to start work on issue #2126, see
> https://java.net/jira/browse/JAVASERVERFACES-2126
>
> Please let us know if you have any insights on how to tackle this one.
>
> Regards,
> Manfred