You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Andrew Robinson <an...@gmail.com> on 2008/02/21 03:28:25 UTC
[Trinidad] client (all) view state issue
After upgrading from 1.0.5 to 1.2.6 I am having my PPR fail. I keep
jetty expired view errors:
Caused by: javax.faces.application.ViewExpiredException:
viewId:/test.jsf - View /test.jsf could not be restored.
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:187)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
I have full client side state:
<context-param>
<param-name>org.apache.myfaces.trinidad.CLIENT_STATE_METHOD</param-name>
<param-value>all</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.trinidad.CACHE_VIEW_ROOT</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
I am seeing the viewState being sent back in the AJAX request.
I did a forum search and came up empty. Is there a problem with true
client side state in 1.2.6?
BTW - I am using client side state as I plan to host on a server that
won't have a very large heap so I want to conserve memory.
-Andrew
Re: [Trinidad] client (all) view state issue
Posted by Scott O'Bryan <da...@gmail.com>.
I broke it so the sooner I can put the embarrassment behind me the
better. O:-)
I still think Facelets needs a 1.2 state manager...
Scott
Matthias Wessendorf wrote:
> alright,
>
> let's try that next week ;-)
>
> On Fri, Feb 22, 2008 at 6:17 PM, Andrew Robinson
> <an...@gmail.com> wrote:
>
>>> perhaps worth to get out a new release ?
>>>
>> my opinion is yes
>>
>>
>
>
>
>
Re: [Trinidad] client (all) view state issue
Posted by Matthias Wessendorf <ma...@apache.org>.
alright,
let's try that next week ;-)
On Fri, Feb 22, 2008 at 6:17 PM, Andrew Robinson
<an...@gmail.com> wrote:
> > perhaps worth to get out a new release ?
>
> my opinion is yes
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [Trinidad] client (all) view state issue
Posted by Andrew Robinson <an...@gmail.com>.
> perhaps worth to get out a new release ?
my opinion is yes
Re: [Trinidad] client (all) view state issue
Posted by Matthias Wessendorf <ma...@apache.org>.
saw it;
thanks!
perhaps worth to get out a new release ?
-M
On Fri, Feb 22, 2008 at 5:15 PM, Andrew Robinson
<an...@gmail.com> wrote:
> Done on a new thread
>
>
>
> On Thu, Feb 21, 2008 at 11:00 PM, Matthias Wessendorf <ma...@apache.org> wrote:
> > Hi,
> >
> > On Thu, Feb 21, 2008 at 5:27 PM, Andrew Robinson
> >
> > <an...@gmail.com> wrote:
> >
> >
> > > It is a bug, not intentional. We need to fix this ASAP as it looks
> > > like the change made trinidad 1.2.6 no longer compatible with any JSF
> > > 1.1 state manager, not just facelets.
> > >
> > >
> > >
> > > > > Nevermind, it looks like Trinidad 1.2.6 is no longer compatible with facelets
> > > > >
> > > > > https://issues.apache.org/jira/browse/TRINIDAD-955
> > > >
> > > > yes, which is odd.
> > > > Perhaps we should *warn* users to upgrade to 1.2.6, when they are on Facelets ?
> > > > -M
> > >
> > > You mean *NOT* upgrade to 1.2.6 or 1.2.7-SNAPSHOT if they have any JSF
> > > 1.1 state managers in their technology stack
> >
> > thanks for fixing.
> > yes, I mean to *not* upgrade :-)
> >
> > Do you want to send out a mail, since you fixed it ?
> >
> > Thx,
> > Matthias
> >
> >
> >
> > >
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > mail: matzew-at-apache-dot-org
> >
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [Trinidad] client (all) view state issue
Posted by Andrew Robinson <an...@gmail.com>.
Done on a new thread
On Thu, Feb 21, 2008 at 11:00 PM, Matthias Wessendorf <ma...@apache.org> wrote:
> Hi,
>
> On Thu, Feb 21, 2008 at 5:27 PM, Andrew Robinson
>
> <an...@gmail.com> wrote:
>
>
> > It is a bug, not intentional. We need to fix this ASAP as it looks
> > like the change made trinidad 1.2.6 no longer compatible with any JSF
> > 1.1 state manager, not just facelets.
> >
> >
> >
> > > > Nevermind, it looks like Trinidad 1.2.6 is no longer compatible with facelets
> > > >
> > > > https://issues.apache.org/jira/browse/TRINIDAD-955
> > >
> > > yes, which is odd.
> > > Perhaps we should *warn* users to upgrade to 1.2.6, when they are on Facelets ?
> > > -M
> >
> > You mean *NOT* upgrade to 1.2.6 or 1.2.7-SNAPSHOT if they have any JSF
> > 1.1 state managers in their technology stack
>
> thanks for fixing.
> yes, I mean to *not* upgrade :-)
>
> Do you want to send out a mail, since you fixed it ?
>
> Thx,
> Matthias
>
>
>
> >
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>
Re: [Trinidad] client (all) view state issue
Posted by JoeJoseph <su...@dnbtransunion.com>.
Hi Matthias,
I am using Trinidad 1.2.10. In my application, I am using nested dialogs
with PPR used extensively. Suppose I open a dialog and then open another
dialog from that, and use partial submit on my second dialog continuously,
without any break, suddenly the state is lost and a ViewExpiredException
occurs. Here is a stack trace for your reference:
javax.faces.application.ViewExpiredException: /layout/layout.jspxNo saved
view state could be found for the view identifier: /layout/layout.jspx
at
org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:88)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:151)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:265)
at
org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:124)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
at
org.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:81)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
at
org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:110)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
at
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
at
org.acegisecurity.concurrent.ConcurrentSessionFilter.doFilter(ConcurrentSessionFilter.java:95)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
at
org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:149)
at
org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.dnb.rmp.nautilus.frwk.web.filter.UTFEncoderFilter.doFilter(UTFEncoderFilter.java:40)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Unknown Source)
Is there some problem with nested dialogs + PPR usage in JSF Trinidad
1.2.10? I am getting the exception so often that my application is not
usable at all. Any help would be great.
Thanks
Joseph
Matthias Wessendorf-4 wrote:
>
> Hi,
>
> On Thu, Feb 21, 2008 at 5:27 PM, Andrew Robinson
> <an...@gmail.com> wrote:
>> It is a bug, not intentional. We need to fix this ASAP as it looks
>> like the change made trinidad 1.2.6 no longer compatible with any JSF
>> 1.1 state manager, not just facelets.
>>
>>
>>
>> > > Nevermind, it looks like Trinidad 1.2.6 is no longer compatible with
>> facelets
>> > >
>> > > https://issues.apache.org/jira/browse/TRINIDAD-955
>> >
>> > yes, which is odd.
>> > Perhaps we should *warn* users to upgrade to 1.2.6, when they are on
>> Facelets ?
>> > -M
>>
>> You mean *NOT* upgrade to 1.2.6 or 1.2.7-SNAPSHOT if they have any JSF
>> 1.1 state managers in their technology stack
>
> thanks for fixing.
> yes, I mean to *not* upgrade :-)
>
> Do you want to send out a mail, since you fixed it ?
>
> Thx,
> Matthias
>
>>
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>
>
--
View this message in context: http://old.nabble.com/-Trinidad--client-%28all%29-view-state-issue-tp15603589p26404585.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] client (all) view state issue
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi,
On Thu, Feb 21, 2008 at 5:27 PM, Andrew Robinson
<an...@gmail.com> wrote:
> It is a bug, not intentional. We need to fix this ASAP as it looks
> like the change made trinidad 1.2.6 no longer compatible with any JSF
> 1.1 state manager, not just facelets.
>
>
>
> > > Nevermind, it looks like Trinidad 1.2.6 is no longer compatible with facelets
> > >
> > > https://issues.apache.org/jira/browse/TRINIDAD-955
> >
> > yes, which is odd.
> > Perhaps we should *warn* users to upgrade to 1.2.6, when they are on Facelets ?
> > -M
>
> You mean *NOT* upgrade to 1.2.6 or 1.2.7-SNAPSHOT if they have any JSF
> 1.1 state managers in their technology stack
thanks for fixing.
yes, I mean to *not* upgrade :-)
Do you want to send out a mail, since you fixed it ?
Thx,
Matthias
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [Trinidad] client (all) view state issue
Posted by Andrew Robinson <an...@gmail.com>.
It is a bug, not intentional. We need to fix this ASAP as it looks
like the change made trinidad 1.2.6 no longer compatible with any JSF
1.1 state manager, not just facelets.
> > Nevermind, it looks like Trinidad 1.2.6 is no longer compatible with facelets
> >
> > https://issues.apache.org/jira/browse/TRINIDAD-955
>
> yes, which is odd.
> Perhaps we should *warn* users to upgrade to 1.2.6, when they are on Facelets ?
> -M
You mean *NOT* upgrade to 1.2.6 or 1.2.7-SNAPSHOT if they have any JSF
1.1 state managers in their technology stack
Re: [Trinidad] client (all) view state issue
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi,
On Thu, Feb 21, 2008 at 5:05 AM, Andrew Robinson
<an...@gmail.com> wrote:
> Nevermind, it looks like Trinidad 1.2.6 is no longer compatible with facelets
>
> https://issues.apache.org/jira/browse/TRINIDAD-955
yes, which is odd.
Perhaps we should *warn* users to upgrade to 1.2.6, when they are on Facelets ?
-M
>
> Looks like I will have to use 1.2.5
>
> -Andrew
>
> On Wed, Feb 20, 2008 at 7:34 PM, Andrew Robinson
>
>
> <an...@gmail.com> wrote:
> > Removing the CLIENT_STATE_METHOD and CACHE_VIEW_ROOT parameters
> > doesn't help. This gets:
> >
> > Caused by: java.lang.ClassCastException: [Ljava.lang.Object; cannot be
> > cast to java.lang.String
> > at org.apache.myfaces.trinidadinternal.util.SubKeyMap._getBaseKey(SubKeyMap.java:116)
> > at org.apache.myfaces.trinidadinternal.util.SubKeyMap.get(SubKeyMap.java:75)
> > at org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView(StateManagerImpl.java:526)
> > at com.sun.faces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:290)
> > at org.jboss.seam.jsf.SeamViewHandler.restoreView(SeamViewHandler.java:93)
> > at org.jenia.faces.template.handler.ViewHandler.restoreView(ViewHandler.java:263)
> > at com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:316)
> > at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:193)
> > at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:260)
> > at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:141)
> >
> > at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
> > at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
> > ... 43 more
> >
> >
> >
> >
> > On Wed, Feb 20, 2008 at 7:28 PM, Andrew Robinson
> > <an...@gmail.com> wrote:
> > > After upgrading from 1.0.5 to 1.2.6 I am having my PPR fail. I keep
> > > jetty expired view errors:
> > >
> > > Caused by: javax.faces.application.ViewExpiredException:
> > > viewId:/test.jsf - View /test.jsf could not be restored.
> > > at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:187)
> > > at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
> > > at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> > > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
> > >
> > > I have full client side state:
> > > <context-param>
> > > <param-name>org.apache.myfaces.trinidad.CLIENT_STATE_METHOD</param-name>
> > > <param-value>all</param-value>
> > > </context-param>
> > > <context-param>
> > > <param-name>org.apache.myfaces.trinidad.CACHE_VIEW_ROOT</param-name>
> > > <param-value>false</param-value>
> > > </context-param>
> > > <context-param>
> > > <param-name>org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE</param-name>
> > > <param-value>false</param-value>
> > > </context-param>
> > > <context-param>
> > > <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
> > > <param-value>client</param-value>
> > > </context-param>
> > >
> > > I am seeing the viewState being sent back in the AJAX request.
> > >
> > > I did a forum search and came up empty. Is there a problem with true
> > > client side state in 1.2.6?
> > >
> > > BTW - I am using client side state as I plan to host on a server that
> > > won't have a very large heap so I want to conserve memory.
> > >
> > > -Andrew
> > >
> >
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [Trinidad] client (all) view state issue
Posted by Andrew Robinson <an...@gmail.com>.
Nevermind, it looks like Trinidad 1.2.6 is no longer compatible with facelets
https://issues.apache.org/jira/browse/TRINIDAD-955
Looks like I will have to use 1.2.5
-Andrew
On Wed, Feb 20, 2008 at 7:34 PM, Andrew Robinson
<an...@gmail.com> wrote:
> Removing the CLIENT_STATE_METHOD and CACHE_VIEW_ROOT parameters
> doesn't help. This gets:
>
> Caused by: java.lang.ClassCastException: [Ljava.lang.Object; cannot be
> cast to java.lang.String
> at org.apache.myfaces.trinidadinternal.util.SubKeyMap._getBaseKey(SubKeyMap.java:116)
> at org.apache.myfaces.trinidadinternal.util.SubKeyMap.get(SubKeyMap.java:75)
> at org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView(StateManagerImpl.java:526)
> at com.sun.faces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:290)
> at org.jboss.seam.jsf.SeamViewHandler.restoreView(SeamViewHandler.java:93)
> at org.jenia.faces.template.handler.ViewHandler.restoreView(ViewHandler.java:263)
> at com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:316)
> at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:193)
> at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:260)
> at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:141)
>
> at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
> ... 43 more
>
>
>
>
> On Wed, Feb 20, 2008 at 7:28 PM, Andrew Robinson
> <an...@gmail.com> wrote:
> > After upgrading from 1.0.5 to 1.2.6 I am having my PPR fail. I keep
> > jetty expired view errors:
> >
> > Caused by: javax.faces.application.ViewExpiredException:
> > viewId:/test.jsf - View /test.jsf could not be restored.
> > at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:187)
> > at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
> > at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
> >
> > I have full client side state:
> > <context-param>
> > <param-name>org.apache.myfaces.trinidad.CLIENT_STATE_METHOD</param-name>
> > <param-value>all</param-value>
> > </context-param>
> > <context-param>
> > <param-name>org.apache.myfaces.trinidad.CACHE_VIEW_ROOT</param-name>
> > <param-value>false</param-value>
> > </context-param>
> > <context-param>
> > <param-name>org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE</param-name>
> > <param-value>false</param-value>
> > </context-param>
> > <context-param>
> > <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
> > <param-value>client</param-value>
> > </context-param>
> >
> > I am seeing the viewState being sent back in the AJAX request.
> >
> > I did a forum search and came up empty. Is there a problem with true
> > client side state in 1.2.6?
> >
> > BTW - I am using client side state as I plan to host on a server that
> > won't have a very large heap so I want to conserve memory.
> >
> > -Andrew
> >
>
Re: [Trinidad] client (all) view state issue
Posted by Andrew Robinson <an...@gmail.com>.
Removing the CLIENT_STATE_METHOD and CACHE_VIEW_ROOT parameters
doesn't help. This gets:
Caused by: java.lang.ClassCastException: [Ljava.lang.Object; cannot be
cast to java.lang.String
at org.apache.myfaces.trinidadinternal.util.SubKeyMap._getBaseKey(SubKeyMap.java:116)
at org.apache.myfaces.trinidadinternal.util.SubKeyMap.get(SubKeyMap.java:75)
at org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView(StateManagerImpl.java:526)
at com.sun.faces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:290)
at org.jboss.seam.jsf.SeamViewHandler.restoreView(SeamViewHandler.java:93)
at org.jenia.faces.template.handler.ViewHandler.restoreView(ViewHandler.java:263)
at com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:316)
at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:193)
at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:260)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:141)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
... 43 more
On Wed, Feb 20, 2008 at 7:28 PM, Andrew Robinson
<an...@gmail.com> wrote:
> After upgrading from 1.0.5 to 1.2.6 I am having my PPR fail. I keep
> jetty expired view errors:
>
> Caused by: javax.faces.application.ViewExpiredException:
> viewId:/test.jsf - View /test.jsf could not be restored.
> at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:187)
> at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
>
> I have full client side state:
> <context-param>
> <param-name>org.apache.myfaces.trinidad.CLIENT_STATE_METHOD</param-name>
> <param-value>all</param-value>
> </context-param>
> <context-param>
> <param-name>org.apache.myfaces.trinidad.CACHE_VIEW_ROOT</param-name>
> <param-value>false</param-value>
> </context-param>
> <context-param>
> <param-name>org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE</param-name>
> <param-value>false</param-value>
> </context-param>
> <context-param>
> <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
> <param-value>client</param-value>
> </context-param>
>
> I am seeing the viewState being sent back in the AJAX request.
>
> I did a forum search and came up empty. Is there a problem with true
> client side state in 1.2.6?
>
> BTW - I am using client side state as I plan to host on a server that
> won't have a very large heap so I want to conserve memory.
>
> -Andrew
>