[
https://issues.apache.org/jira/browse/MYFACES-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898642#action_12898642
]
Werner Punz edited comment on MYFACES-2881 at 8/14/10 4:32 PM:
---------------------------------------------------------------
Hi I did an additional testrun against Mojarra 2.0.3 again. The status in 2.0.2
was that it only could assign properly the viewstate if the second form was
part of the render part.
First it worked on the testcase I have given above, but then:
I tried again, added a bunch of inputs in both forms and then changed the
inputs on one side while doing 500 refreshes.
Then I submitted the second form, and mojarra gave me the lost viewroot
exceptiom which we have all come to love so much. So this means following.
a) Mojarra does some additional state saving optimisations by skipping entirely
non changed view states from the history.
Hence if you dont have any inputs which change their values mojarra always will
restore the same viewstate here.
We probably dont do this for security reasons because we also have alternating
public keys in our viewstate.
b) Mojarras behavior regarding the viewstate handling has not changed, to
resolve it properly you have to push the second form into the render part
otherwise it wont work. Sorry to say that, but the myfaces solution in this
regard is better.
So to make the code working on both side of things, you simply have to push the
second form into the render part, myfaces simply is more tolerant than Mojarra
by allowing also outer elements of forms and inner elements of forms in their
render part.
I could copy the behavior from Mojarra in this area but I guess this is not a
good idea :-)
was (Author: werpu):
Hi I did an additional testrun against Mojarra again. The status in 2.0.2
was that it only could assign properly the viewstate if the second form was
part of the render part.
First it worked on the testcase I have given above, but then:
I tried again, added a bunch of inputs in both forms and then changed the
inputs on one side while doing 500 refreshes.
Then I submitted the second form, and mojarra gave me the lost viewroot
exceptiom which we have all come to love so much. So this means following.
a) Mojarra does some additional state saving optimisations by skipping entirely
non changed view states from the history.
Hence if you dont have any inputs which change their values mojarra always will
restore the same viewstate here.
We probably dont do this for security reasons because we also have alternating
public keys in our viewstate.
b) Mojarras behavior regarding the viewstate handling has not changed, to
resolve it properly you have to push the second form into the render part
otherwise it wont work. Sorry to say that, but the myfaces solution in this
regard is better.
So to make the code working on both side of things, you simply have to push the
second form into the render part, myfaces simply is more tolerant than Mojarra
by allowing also outer elements of forms and inner elements of forms in their
render part.
I could copy the behavior from Mojarra in this area but I guess this is not a
good idea :-)
> Server state saving with two forms, ajax and normal request is broken
> ---------------------------------------------------------------------
>
> Key: MYFACES-2881
> URL: https://issues.apache.org/jira/browse/MYFACES-2881
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
> Affects Versions: 2.0.1, 2.0.2-SNAPSHOT
> Environment: myfaces 2.0.1 or trunk;
> Reporter: Martin Kočí
> Priority: Blocker
> Fix For: 2.1.0
>
>
> Use simple xhtml with:
> <h:form id="form1">
> <h:commandButton value="Partial">
> <f:ajax execute="@this" render="@this" />
> </h:commandButton>
> </h:fom>
> </h:form>
> <h:form id="form2">
> <h:commandButton value="Full" />
> </h:form>
> then:
> 1) click "Partial" button 20x or more
> 2) click "Full" button
> -> ViewExpiredException appears. If you click "Partial" 19 times or less
> ViewExpiredException does not appear.
> 20 is default for NUMBER_OF_VIEW_IN_SESSION - it you set this param to 1 you
> reproduce this problem with two clicks. Maybe there is more simple test case
> for reproducing this issue but I didn't find it yet.
> This bug is present in 2.0.1 already and is related to server state saving:
> myfaces 2.0.1:
> PSS + server: failed
> PSS + client: ok
> FSS + server: failed
> FSS + client: ok
> myfaces 2.0.2-SNAPSHOT:
> PSS + server: failed
> PSS + client: ok
> FSS + server: failed
> FSS + client: ok
> Very likely this causes MYFACES-2877 too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
