myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <werner.p...@gmail.com>
Subject Re: How to troubleshoot ViewExpiredException ?
Date Thu, 05 Jan 2012 07:24:51 GMT
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"
>               <users@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"
>>                <users@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"
>>>                 <users@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<milo@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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>
>



Mime
View raw message