[
https://issues.apache.org/jira/browse/MYFACES-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898635#action_12898635
]
Werner Punz commented on MYFACES-2881:
--------------------------------------
Hi Martin Mojarra seems to have fixed the issue in 2.0.3, it was not working
for 2.0.2, but the main issue here is the mechanism, if they really fixed it by
updating all forms, then they broke definitely portlets that way, which was a
major issue why I pulled the update all forms from my code and introduced the
marker elements cause form updates code.
But to give you a full picture I have to give you a complete history of the
issue.
But I will give a complete history. I discovered this bug sometime after 2.0
was released and immediately tested against Mojarra (2.0.2 back then). Mojarra
had some fixup code which worked only if you had the element updated as child
of the form, but it failed if the form was not even touched.
I then implemented an all forms update solution, and brought the entire issue
to the expert group and also filed a bugreport.
Then someone pointed out in a bugreport that the update all forms solution
cannot work in a portlet specific environment where you have multiple
viewroots. Now the next problem I am facing here is that there is no viewroot
detection.
So I tried to opt for a solution which basically works satisfactory and does
not break compatibility to mojarra. I did this by the mechanism described
above,
a) Update all forms which nest elements which are updated, update the original
form consisting the issuing element, and update all forms which might have been
childs of updated elements.
That way you can write code which works on both platforms and does not break
any compatibility to future upgrades in this area. If this is not satisfactory
then I will need a viewroot detection mechanism coming from the server which
can give me a dedicated viewroot id in a portlet scenario, than I can move over
to an update all forms mechanism.
Another option to resolve this would be to reuse the existing script config
param no_portlet_env to enable the update all forms mechanism. None of this is
entirely satisfactory because the first one has to be added ont he server, the
second one
is not a plug and play mechanism. Or inverse that param so that it can be set
in a portlet environment.
And the issue is, I have filed all this to the EG for 2.1 I hope it will be
tackled and resolved, this issue has been a major pain for me for ages.
> 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.
