[
https://issues.apache.org/jira/browse/MYFACES-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898635#action_12898635
]
Werner Punz edited comment on MYFACES-2881 at 8/14/10 4:00 PM:
---------------------------------------------------------------
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.
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.
Sorry for my bitter tone on this issue, but I have been fighting for a clean
solution here for months now, tried to make a solution for all scenarii without
breaking the spec, filed bug reports to all parties and even to Mojarra and
then again getting smacked again for a bug which I did not even introduce
firsthand.
The criticism regarding Mojarra doing and and we don´t makes me especially
bitter since I filed the bugreport on this one for Mojarra and I tried to find
a sane solution which works in a portlet and non portlet scenario until this
can be resolved properly on spec level.
I have not dug into the code what Mojarra does, but I assume they repeated my
mistake I did firsthand by just updating all forms given and not doing anything
regarding portlets.
was (Author: werpu):
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.
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.
