> You simply set the context parameter PARAM_BUILD_BEFORE_RESTORE > to true. > Correction. I provided the name of the constant in the Facelets API. The parameter name is facelets.BUILD_BEFORE_RESTORE. The context parameter configuration is shown below: <web-app ...> ... <context-param> <param-name>facelets.BUILD_BEFORE_RESTORE</param-name> <param-value>true</param-value> </context-param </web-app> -Dan

This feature was added in Facelets 1.1.12 according to this URL: http://sfjsf.blogspot.com/2006/03/facelets-112-is-out.html To test this feature, set the session timeout to 1 minute, visit the login page, and go grab a cup of coffee (yes, there are other ways, but this is the real world test). When you get back, try to use the login page. You should see that you can successfully login even though the session is dead and the previously rendered login view cannot be found during postback. -Dan On Sun, Sep 7, 2008 at 8:01 PM, Shane Bryzak <shane.bryzak(a)jboss.com&gt; wrote: > Is this a recent change to Facelets? I tried this in the seamspace example > and still got the "View /home.seam could not be restored" exception. > > Dan Allen wrote: > >>> You simply set the context parameter PARAM_BUILD_BEFORE_RESTORE >>> to true. >>> >>> >> Correction. I provided the name of the constant in the Facelets API. >> The parameter name is facelets.BUILD_BEFORE_RESTORE. The context >> parameter configuration is shown below: >> >> <web-app ...> >> ... >> <context-param> >> <param-name>facelets.BUILD_BEFORE_RESTORE</param-name> >> <param-value>true</param-value> >> </context-param >> </web-app> >> >> -Dan >> >> >> > >

Do you have this context parameter as well? <context-param> <param-name>com.sun.faces.disableVersionTracking</param-name> <param-value>true</param-value> </context-param> I'm not sure this makes a difference, but it has something to do with JSF detecting the wrong version of JSF due to RichFaces faces-config.xml files on the classpath. When JSF is not working in 1.2 mode, it handles the restore logic differently. Check with this enabled and report the results. -Dan On Sun, Sep 7, 2008 at 9:12 PM, Shane Bryzak <shane.bryzak(a)jboss.com&gt; wrote: > I tested by browsing to the login page, then killing JBossAS and restarting > it (same effect as session timing out) yet still get the same exception. My > web.xml has the following entry: > > <context-param> > <param-name>facelets.BUILD_BEFORE_RESTORE</param-name> > <param-value>true</param-value> > </context-param> > > Here's the stack trace. I checked the version of Facelets that we have in > Seam and it's 1.1.15.B1. > > javax.faces.application.ViewExpiredException: viewId:/home.seam - View > /home.seam could not be restored. > > com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:186) > com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100) > > com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:104) > com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) > javax.faces.webapp.FacesServlet.service(FacesServlet.java:265) > > org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83) > org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38) > > org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) > org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85) > > org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) > org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64) > > org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) > org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) > > org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) > > org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) > org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:150) > org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:267) > > org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:379) > org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:506) > org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56) > > org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) > org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58) > > org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) > org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) > > org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) > > > > Dan Allen wrote: > >> This feature was added in Facelets 1.1.12 according to this URL: >> >> http://sfjsf.blogspot.com/2006/03/facelets-112-is-out.html >> >> To test this feature, set the session timeout to 1 minute, visit the >> login page, and go grab a cup of coffee (yes, there are other ways, >> but this is the real world test). When you get back, try to use the >> login page. You should see that you can successfully login even though >> the session is dead and the previously rendered login view cannot be >> found during postback. >> >> -Dan >> >> On Sun, Sep 7, 2008 at 8:01 PM, Shane Bryzak <shane.bryzak(a)jboss.com&gt; >> wrote: >> >> >>> Is this a recent change to Facelets? I tried this in the seamspace >>> example >>> and still got the "View /home.seam could not be restored" exception. >>> >>> Dan Allen wrote: >>> >>> >>>>> You simply set the context parameter PARAM_BUILD_BEFORE_RESTORE >>>>> to true. >>>>> >>>>> >>>>> >>>> Correction. I provided the name of the constant in the Facelets API. >>>> The parameter name is facelets.BUILD_BEFORE_RESTORE. The context >>>> parameter configuration is shown below: >>>> >>>> <web-app ...> >>>> ... >>>> <context-param> >>>> <param-name>facelets.BUILD_BEFORE_RESTORE</param-name> >>>> <param-value>true</param-value> >>>> </context-param >>>> </web-app> >>>> >>>> -Dan >>>> >>>> >>>> >>>> >>> >> >> >> > >

Date: Sun, 7 Sep 2008 18:10:17 -0400 From: dan.j.allen(a)gmail.com To: seam-dev(a)lists.jboss.org Subject: [seam-dev] Re: PARAM_BUILD_BEFORE_RESTORE > You simply set the context parameter PARAM_BUILD_BEFORE_RESTORE > to true. Correction. I provided the name of the constant in the Facelets API. The parameter name is facelets.BUILD_BEFORE_RESTORE. The context parameter configuration is shown below: <web-app ...> ... <context-param> <param-name>facelets.BUILD_BEFORE_RESTORE</param-name> <param-value>true</param-value> </context-param </web-app> -Dan -- Dan Allen Software consultant | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction NOTE: While I make a strong effort to keep up with my email on a daily basis, life and work come first and, at times, keep me away from my mail for a while. If you contact me, then don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention. _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

this bug has been biting other webapps for close to a year and now I see it when deploying jsf-demo from portals-bridges project java.lang.IllegalArgumentException: Class org.jboss.seam.jsf.SeamApplicationFactory is no javax.faces.application.ApplicationFactory

During the panel discussion last night as JSF One, I learned about an undocumented feature in Facelets, which may be just the solution you were looking for, Christian, regarding stale views on a login or other public form page. Facelets has the ability to build the view during the restore view phase if on postback the view state couldn't be found. You simply set the context parameter PARAM_BUILD_BEFORE_RESTORE