jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: [1336-ViewScopeAndClientSideStateSaving]

From: Leonardo Uribe <leonardo.uribe_at_irian.at>
Date: Tue, 4 Nov 2014 17:16:24 -0500

Hi Manfred

I think the point is we have situations where the developer wants a
bean that specifically is stored on the client by design.

But another problem we have is, there is no flexibility about how the
state saving is handled. For example, there is a view and you need
that the view do not expire under any condition (server restart,
timeout, ...). So, all necessary information should be stored with the
page, usually inside javax.faces.ViewState hidden field. So, you set
the state saving mode to "client", hoping that just that could work,
but the are some problems with that:

- This applies to every view in the whole application (no flexibility
over state saving).
- Flash scope and flow scope are stored into session too, so these
beans will expire too.

I don't know if we can fix it with a specific client side scope, but
what raises my attention is the motivation behind this "usually" is a
developer decision. The problem is sometimes users try to switch from
server to client, aiming to achieve better performance, but sometimes
this is a security issue, because all information inside the beans
goes to the client (but the view state is encrypted and tampered), so
you want to move the view state but not the beans, because the beans
contains business information.

Other problem we have is on server side state saving, there is no
"expiration" policy for view scope beans. By the spec, these beans are
discarded when the session is expired. I fixed that problem in MyFaces
and I'm on the way to fix the expiration problem with flash and flow
scope.

In conclusion there is a lot of considerations involved here. I don't
know how to solve them all, I just hope to put these concerns on the
table, so we can discuss it in the future.

regards,

Leonardo Uribe

2014-11-04 16:04 GMT-05:00 manfred riem <manfred.riem_at_oracle.com>:
> Hi Leonardo,
>
> In 2.1.x we indeed had a view scope that was saving the view scoped managed
> beans with the view state. However that proved to be problematic as it was
> underspecified a bit.
>
> In the 2.2 specification we fixed this by solving the following problems:
>
> 1. Fix requirements for @PreDestroy
> 2. Fix requirements for @PostConstruct
> 3. Fix the CDI and non-CDI variant of @ViewScoped to work the same way
> 4. Fix client-side and server-side state saving variant of a @ViewScoped
> bean to work the same way.
>
> We did that by primarily requiring a @ViewScoped bean to live in the
> session.
>
> But what does it mean if you really want to just have a client side variant
> of the 2.1 @ViewScoped style, well with the current state you are out of
> luck. Should we create a @ClientScoped that stores the beans in the client
> side view state (and mandates it to be only supported for client side state
> saving)? And if so, how do we define @PostConstruct and @PreDestroy, or do
> we not support those on a @ClientScoped bean as we can't clearly define when
> those should be called?
>
> Anyway that is the information behind the issue. Feel free to comment.
>
> Regards,
> Manfred
>
>
> On 11/4/14, 2:39 PM, Leonardo Uribe wrote:
>>
>> Hi
>>
>> I saw this issue on the issue tracker:
>>
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1336
>> ViewScope and client side state saving is broken
>>
>> I just wanted to mention that JSF 2.2 javadoc of
>> UIViewRoot.getViewMap(boolean create) says this:
>>
>> "... For reasons made clear in ViewScoped, this map must ultimately be
>> stored in the session. For this reason, a true value for the create
>> argument will force the session to be created with a call to
>> ExternalContext.getSession(boolean). ..."
>>
>> In JSF 2.1 and earlier, view scope was stored with the view state on
>> client side state saving.
>>
>> I remember a discussion about that in myfaces users list long time ago:
>>
>> http://markmail.org/message/ojbet3r2iicdxcmh
>>
>> I think the change was done to support @PreDestroy annotation when the
>> session is expired.
>>
>> What do I miss? I understand there are reasons to have a view scope
>> stored with the view state (avoid ViewExpiredException or view scope
>> bean expiration).
>>
>> Please note flow scope and flash scope are stored in session too, so
>> what's the deal?
>>
>> Isn't better to provide a client side view scope that specifically is
>> stored with the view state?
>>
>> regards,
>>
>> Leonardo Uribe
>>
>