Hi Paul then the issue will be harder to nail down.
The problem I was referring to is only client side based and can only
occur in multiple forms.
I doubt your problem has anything to do with the problem I was referring
to, at least not directly, there must be at least a second part to this
issue.
I was referring to following problem:
In an ajax update cycle you will get the ViewState from following part
of the protocol
<update id="javax.faces.ViewState><![CDATA[VieState]]>....
Now the viewstate is applied to the originating form and all forms which
are listed in the render targets. Per default.
Now in a multiform scenario if you dont define the render targets
properly you can get old viewstates because there can be forms which do
not get the updated value. Once you have a critical number of viewstate
updates reached in the main form, the old viewstate referred in the
second form is dropped from the state history and then you run into this
issue.
This is a spec issue because the spec clearly states the paragraph above
with the original form and the render targets. What I did was to add
some extensions to the core spec behavior to ease the problem a little
bit. But nevertheless the spec here has a leak, and this leak will be
fixed as it seems in jsf 2.2 by one way or the other.
But the main issue I see in your problem here is that I dont think that
this has anything to do with the problem that you guys lose the
ViewState in a db rollback scenario at least not directly. But the
problem could play in. Give the workarounds a try if it fixes your
problem if not then we have to dig deeper.
Sidequestion, does the problem also occur in a single form case or only
in the multi form case.
Nevertheless maybe Leonardo Uribe (our core maintainer) has an idea what
could happen here. A viewstate lost usually is a case of trying to reach
a component tree id which has been dropped of the state history.
(which in the non portlet case is 15-20 or so, dunno about the portlet case)
I will ping Leo so that he will jump into this thread.
Werner
Am 04.01.12 22:01, schrieb Paul Nicolucci:
No problem at all! Another quick query about this issue.....We only seem
to see this after our DB rolls back due to a deadlock, we don't see this
under normal use.
Is that an expected behavior to only see this after some sort of error
occurs? Just trying to broaden my understanding of what's going on!
Thanks again for all the information and help!
Regards,
Paul Nicolucci
Werner Punz
<werner.punz@gmai
l.com> To
users@myfaces.apache.org
01/04/2012 03:11 cc
PM
Subject
Re: How to troubleshoot
Please respond to ViewExpiredException ?
"MyFaces
Discussion"
<us...@myfaces.ap
ache.org>
Hi Paul, glad I could help,
sorry that I mixed up your first name before.
Werner
Am 04.01.12 20:30, schrieb Paul Nicolucci:
Thanks for your response Werner, I'll share the information with my
co-workers.
Regards,
Paul
Werner Punz
<werner.punz@gmai
l.com>
To
users@myfaces.apache.org
01/04/2012 01:56
cc
PM
Subject
Re: How to troubleshoot
Please respond to ViewExpiredException ?
"MyFaces
Discussion"
<us...@myfaces.ap
ache.org>
Hi Nick, the no_portlet_env is strictly a fix for non portlet cases.
Where you simply can update all forms given with a new viewstate.
The idea is that in a non portlet environment you simply can update all
forms at once. In a portlet environment things are more difficult
because you can have multiple viewroots.
This cannot and will not work in a portlet environment. Because it will
fix all forms from document.
The root cause of the issue is a spec issue which will be addressed
to my knowledge in JSF 2.2.
In your case you can work around the issue by other ways.
a) Use the affected forms as render targets, every form as render target
will get the updated viewstate. This works in both Mojarra and MyFaces.
b) For myfaces only there is a second workaround, use simply a render
target in every form you have (a hidden div) then all forms having those
render targets will be updated properly.
A third way would be to fix the protocol itself, this might break third
party component libs however. You theoretically could add the viewroot
information in the<extension> tag of the response via a custom partial
response writer.
Then on the client side parse this info to determine the viewroot of
your portlet and then update all forms within the portlet with the given
viewstate.
Another way would be to allow a custom parameter with the viewroot
parameter being passed down so that after the update the viewroot can be
determined by the client and all forms within its realm can be updated.
If you want this mechanism I can code it in this week for you guys. It
is merely an extension to the mechanims we already have so I see it as
non critical to add it.
It would look like jsf.ajax.request(...{execute...., render...,
myfaces:{viewRoot:"portletViewRootId",...}}
You really have to add this on javascript level, f:ajax usage however
would not work in this case.
Werner
Am 04.01.12 08:02, schrieb Paul Nicolucci:
Hello All,
I have a couple of questions regarding this.
1) With the suggested workaround :
<script type="text/javascript">
// fixup for an issue of the jsf2.0 and 2.1 ajax
// spec to deal with multiple forms per page.
// => ViewExpiredException occurs if you heavy use ajax within
// more than one form (MYFACES-3159)
window.myfaces = window.myfaces || {};
myfaces.config = myfaces.config || {};
myfaces.config.no_portlet_env = true;
</script>
Can you explain the importance of the
"myfaces.config.no_portlet_env=true?
We are experiencing this issue in a portlet environment, would that
change
the value or the chances of this workaround actually working for us?
2) It looks as though the workaround in number 1 was made in:
https://issues.apache.org/jira/browse/MYFACES-2881
@Werner, can you pinpoint what commits I need from this issue? It looks
as
though there were many changes in this one commit are they all needed?
Thanks for the help!
Regards,
Paul Nicolucci
Werner Punz
<werner.punz@gmai
l.com>
To
users@myfaces.apache.org
12/29/2011 11:23
cc
AM
Subject
Re: How to troubleshoot
Please respond to ViewExpiredException ?
"MyFaces
Discussion"
<us...@myfaces.ap
ache.org>
Here is the link to the spec bug
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790
Werner
Am 29.12.11 15:20, schrieb Michael Heinen:
See https://issues.apache.org/jira/browse/MYFACES-2881
It seems to be still required because it updates the viewstates of all
forms on the page.
Otherwise only the viewstate of the submitted form (or rerendered
forms)
is updated.
It's a workaround.
Michael
Am 29.12.2011 14:51, schrieb Rohit Kelapure:
Why do I need this Javascript ?
--Thanks,
Rohit
On Thu, Dec 29, 2011 at 5:39 AM, Milo van der
Zee<m...@vanderzee.org>wrote:
He probably has multiple forms and could try to add the famous piece
of
javascript. Even though I used RF2.1.0 and MyFaces 2.1.5 I still do
need
it as well.
<script type="text/javascript">
// fixup for an issue of the jsf2.0 and 2.1 ajax
// spec to deal with multiple forms per page.
// => ViewExpiredException occurs if you heavy use ajax within
// more than one form (MYFACES-3159)
window.myfaces = window.myfaces || {};
myfaces.config = myfaces.config || {};
myfaces.config.no_portlet_env = true;
</script>
MAG,
Milo
On Wed, 2011-12-28 at 22:55 +0100, Werner Punz wrote:
Do you use multiple forms in conjunction with JSF ajax?
Werner
Am 28.12.11 18:30, schrieb Rohit Kelapure:
Dear all,
We have run into an issue with our application in production
wherein
once a
database rollback occurs, our application state somehow gets messed
and we
repeatedly keep seeing ViewExpiredExceptions like so ...
[12/24/11 3:51:52:301 EST] 000003b3 SystemErr R
javax.faces.application.ViewExpiredException: /showItem.xhtml No
saved
view
state could be found for the view identifier: /showItem.xhtmlnull
[12/24/11 3:51:52:302 EST] 000003b3 SystemErr R at
org.apache.myfaces.lifecycle.RestoreViewExecutor.execute
(RestoreViewExecutor.java:128)null
[12/24/11 3:51:52:302 EST] 000003b3 SystemErr R at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase
(LifecycleImpl.java:171)null
[12/24/11 3:51:52:302 EST] 000003b3 SystemErr R at
org.apache.myfaces.lifecycle.LifecycleImpl.execute
(LifecycleImpl.java:118)null
Caused by: javax.faces.application.ViewExpiredException:
/showShoppingCart.xhtml No saved view state could be found for the
view
identifier: /showShoppingCart.xhtml
at
org.apache.myfaces.lifecycle.RestoreViewExecutor.execute
(RestoreViewExecutor.java:128)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase
(LifecycleImpl.java:171)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute
(LifecycleImpl.java:118)
at
com.ibm.faces20.portlet.FacesPortlet.processAction
(FacesPortlet.java:238)
This happens for ALL the JSF facelets *.xhtml files in our
application.
This is a JSF 2 application.
What is the next step in debugging these ViewExpiredExceptions ?
For starters I have enabled the trace *
*=info:org.apache.myfaces.lifecycle*=all*
*
*
All your tips are appreciated.
--Thanks,
Rohit Kelapure
