[
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:39 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 :-)
Btw. I also repeated the same test for myfaces and it worked. So the issue here
simply is
Mojarra seems to be recycling non changed savestates which made your code work
because you did not have too much changes while testing, but in the end it
would have failed as well, because the second form is not part of the render
part of your ajax request.
Myfaces has failed earlier because it does not recycle the savestates,
definitely an area which we might be able to improve, I guess, given that the
savestating is a performance killer.
Myfaces has somewhat more tolerant but Mojarra backwards compatible methods on
how to enable multi form ajax.
To make your implementation work use Mojarras method and push the second form
as well into the render part of your f:ajax tag.
was (Author: werpu):
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 :-)
> 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.
