After talking to our testers it seems as though once the rollback happens
this occurs on pages with and without AJAX calls on them.
We are trying to reproduce again as we speak.
Thanks,
Paul Nicolucci
Werner Punz
<werner.punz@gmai
l.com> To
users@myfaces.apache.org
01/05/2012 02:31 cc
AM
Subject
Re: How to troubleshoot
Please respond to ViewExpiredException ?
"MyFaces
Discussion"
<us...@myfaces.ap
ache.org>
Before going further, does this problem also occur in a non ajax case or
is it entirely ajax related.
Werner
Am 05.01.12 08:24, schrieb Werner Punz:
> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>
