Re: ViewExpiredException - No saved view state could be found for the view identifier
On 8/31/2010 4:53 PM, Micah Klitgaard wrote: javax.faces.application.ViewExpiredException: /pages/login.xhtmlNo saved view state could be found for the view identifier: /pages/login.xhtml ViewExpiredException is one of the most common exceptions you'll encounter in JSF. I'd suggest you start by reading some background material on the JSF life cycle (just Google those three terms.) Try setting your session-timeout to 30 and state_saving_method to server. -- Guy Rouillier
Re: ViewExpiredException - No saved view state could be found for the view identifier
I have been reading about Lifecylces and this is my fourth JSF project. As far as I know 30 minutes is default timeout on Tomcat and server state saving is also default - according to log output. The code is very simple, so if it isn't a bug it should be easy to fix if I'm doing something wrong. Thanks On 8/31/2010 4:53 PM, Micah Klitgaard wrote: javax.faces.application.ViewExpiredException: /pages/login.xhtmlNo saved view state could be found for the view identifier: /pages/login.xhtml ViewExpiredException is one of the most common exceptions you'll encounter in JSF. I'd suggest you start by reading some background material on the JSF life cycle (just Google those three terms.) Try setting your session-timeout to 30 and state_saving_method to server. -- Guy Rouillier
Re: ViewExpiredException: MyFaces PrimeFaces
Hi this is really interesting, from what I noticed in my testing is that you can run into this situation if you ajax a call down without sending a proper view identifier without intercepting it before restoreView. RestoreView obviously must fail then. I have to check what primefaces is sending down but my assumption goes into that direction. What I also noticed is that Mojarra is somewhat more tolerant regarding those situations, because I had a testing case up and running which rightfully ran out of views in its state history on MyFaces and did not in mojarra, the main reason there was that mojarra was restoring the last view on and on in that situation no matter if the viewstate was sent down or not because none of the inputs sent down had changed and the source did not change as well. You ran into the issue in mojarra if you sent down constantly changing values on your inputs as well. It might be a similar issue here, but to really tell that I have to check the protocol. But I am pretty sure this is the cause of the situation you run into here. Werner Am 31.08.10 21:46, schrieb Leonardo Uribe: Hi Could you check your server log?. A more detailed exception could be found there, to identify easily what's going on. regards, Leonardo Uribe 2010/8/31 Rafael Santiniraf...@santini.eti.br Hi Ali, I have posted this question on PrimeFaces Forum. With Mojarra 1.2_15-b01, works perfectly! The problem is that I need to continue with MyFaces for a while. Thanks, Rafael Santini 2010/8/31 Ali Okal...@aliok.com.tr Hi Rafael, Primefaces forum[1] might be a better place to discuss this, but at first sight at your code, you should put the autoCompleteBean in view scope (available with JSF2). [1]http://primefaces.prime.com.tr/forum/ Cheers, Ali On Tue, Aug 31, 2010 at 6:12 PM, SANTINI, Rafaelraf...@santini.eti.br wrote: Hi, I'm trying to get PrimeFaces AutoComplete component to work with MyFaces. I have tried with MyFaces 1.2.9 PrimeFaces 1.1, MyFaces 2.0.1 PrimeFaces 2.1 and MyFaces 2.0.1 PrimeFaces 2.2.M1. In the all cases, the fowlloing exception is raised: 31/08/2010 11:51:32 org.apache.myfaces.renderkit.ErrorPageWriter handleThrowable SEVERE: An exception occurred javax.faces.application.ViewExpiredException: /autocomplete.xhtmlNo saved view state could be found for the view identifier: /autocomplete.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 javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) 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:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) 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:298) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555) at java.lang.Thread.run(Thread.java:619) I have created a simple test case (.war): http://www.4shared.com/get/Jm6REAgI/autocomplete.html Any suggestion? Thanks, Rafael Santini -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: ViewExpiredException - No saved view state could be found for the view identifier
see the other thread on this (ViewExpiredException) topic -M On Wed, Sep 1, 2010 at 9:57 AM, m...@micah-co.com wrote: I have been reading about Lifecylces and this is my fourth JSF project. As far as I know 30 minutes is default timeout on Tomcat and server state saving is also default - according to log output. The code is very simple, so if it isn't a bug it should be easy to fix if I'm doing something wrong. Thanks On 8/31/2010 4:53 PM, Micah Klitgaard wrote: javax.faces.application.ViewExpiredException: /pages/login.xhtmlNo saved view state could be found for the view identifier: /pages/login.xhtml ViewExpiredException is one of the most common exceptions you'll encounter in JSF. I'd suggest you start by reading some background material on the JSF life cycle (just Google those three terms.) Try setting your session-timeout to 30 and state_saving_method to server. -- Guy Rouillier -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: PortletBridge starting portlet problem
The factories are actually set per the context classloader, not per thread, so it is a synchronization issue. Jakub On 1 September 2010 00:49, Scott O'Bryan darkar...@gmail.com wrote: Never mind. My pneumonia is effecting my brain.. :) sorry. Let me take a look at this tomorrow when I'm hopefully not running a fever. Sent from my iPhone On Aug 31, 2010, at 4:41 PM, Scott O'Bryan darkar...@gmail.com wrote: I doubt it's a synchronization issue since the Factory is complaining that it already exists for a particular thread. That to me seems to imply it's single threaded. Sent from my iPhone On Aug 31, 2010, at 3:52 PM, Michael Freedman michael.freed...@oracle.com wrote: Did you see the latest e-mail/comment on the thread with the subject line: Re: [Trinidad] java.lang.IllegalStateException: Factory already available for this class loader? Sounds plausible that the lack of synchronization is causing this problem. You can either wait to hear from the Trinidad guys/and hopefully get a patch/fix or try patching the Trinidad code yourself and rebuilding. Let me know me know what you think. By the way it seems a little strange the portal is sending two (simulanteous) requests. Yes portlet 2.0 can have a 2 request render (one to get the headers) and one to get the body -- so maybe its that. But you are using portlet 1.0 (bridge)/portlet 1.0 container. I wonder if uPortal has a bug where the portal itself knows about portlet 2.0 but isn't smart enough to detect the container is 1.0 so sends the double render request (one to get the headers and the other to get the body) as they only differ from a request perspective by a flag in the request? Anyway if this is the problem and you were running in a portlet 2.0 container you could check for this flag in a subclass of the GenericFacesPortlet and when set to Header merely return without delegating to the bridge. But since you are running in a 1.0 container I have no clue. -Mike- On 8/30/2010 8:39 AM, Yves Deschamps wrote: It means Factory already available for this class loader Thanks... Scott O'Bryan a �crit : Yay.. Exception translation at work. Yves, can you tell us what that message states in English? Sorry, half the characters didn't come through. Sent from my iPhone On Aug 30, 2010, at 6:50 AM, Yves Deschamps yves.descha...@univ-lille1.fr wrote: Hi Michael, I just come back from holidays. I try my app with this environment: trinidad 1.2.15-SNAPSHOT (30/08/2010) portlet-bridge 1.0.0 (distribution) myfaces 1.2.9 (distribution) portlet-api-1.0 pluto... 1.1.7 uPortal-3.2.1 The result is : Caused by: java.lang.IllegalStateException: Factory d�j� disponible pour ce chargeur de classe. at org.apache.myfaces.trinidad.context.RequestContextFactory.setFactory(RequestContextFactory.java:54) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.init(GlobalConfiguratorImpl.java:391) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:334) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.lt;initgt;(FacesContextFactoryImpl.java:86) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:64) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.getFacesContext(BridgeImpl.java:943) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:513) And when the portlet is refreshed, all is ok ! I see this recent message in the list: [Trinidad] java.lang.IllegalStateException: Factory already available for this class loader, I think that the portal make a double request to the portlet ? May be can you test my app in your environment with this zip file : https://bigfile.univ-lille1.fr/get?k=QxI6pCDOMWM12k0bTdJ Thank you in advance. Michael Freedman a �crit : This feels more environmental than anything else. Is this still just the situation when accessing from an iPhone user-agent? The regular user-agent still works fine? Can you send me a complete description of your environment? I.e. Specific Trinidad version, Faces make (Mojarra or Myfaces?) and version, appserver version which includes portlet container make (pluto ???) and version? What has me stumped here is that the line you indicate is throwing the null pointer exception: switch ((Bridge.PortletPhase) mPortletRequest.getAttribute(Bridge.PORTLET_LIFECYCLE_PHASE)) The instance is constructed with the requestObject which is passed by the bridge's externalContext which gets it in its constructor -- so unless a release() occurred I don't see how its null. Likewise the bridge's doFacesRender (further down
Re: ViewExpiredException - No saved view state could be found for the view identifier
Thanks M. I have nearly read all posts on those 20 pages with this topic. Nothing new came to my mind. Further more I explicitly added context params for session timeout, state saving method and numbers of views in session. Please take a look at the code. see the other thread on this (ViewExpiredException) topic -M
Re: ViewExpiredException: MyFaces PrimeFaces
Hi Leonardo, Follow the complete log. I couldn't find any wrong. 01/09/2010 10:27:43 org.apache.catalina.core.AprLifecycleListener init INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:\Arquivos de programas\Java\jdk1.6.0_18\bin;.;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\ARQUIV~1\Borland\Delphi5\Projects\Bpl;C:\ARQUIV~1\Borland\Delphi5\Bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Arquivos de programas\MySQL\MySQL Server 5.0\bin;C:\ferramentas\putty;C:\ferramentas\bzip2;C:\Arquivos de programas\Firebird\Firebird_2_0\bin;C:\Arquivos de programas\Java\jdk1.6.0_18\bin;C:\Arquivos de programas\MySQL\MySQL Server 5.1\bin;C:\ARQUIV~1\Borland\Delphi6\Bin;C:\ARQUIV~1\Borland\Delphi6\Projects\Bpl;C:\Arquivos de programas\Microsoft SQL Server\80\Tools\BINN;C:\software\isis\cisis\bin;C:\Arquivos de programas\Arquivos comuns\Ahead\Lib\ 01/09/2010 10:27:43 org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 01/09/2010 10:27:43 org.apache.catalina.startup.Catalina load INFO: Initialization processed in 234 ms 01/09/2010 10:27:43 org.apache.catalina.core.StandardService start INFO: Starting service Catalina 01/09/2010 10:27:43 org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.29 01/09/2010 10:27:43 org.apache.catalina.startup.HostConfig deployDescriptor INFO: Deploying configuration descriptor autocomplete.xml 01/09/2010 10:27:44 org.apache.catalina.core.StandardContext addApplicationListener INFO: The listener org.apache.myfaces.webapp.StartupServletContextListener is already configured for this context. The duplicate definition has been ignored. 01/09/2010 10:27:44 org.apache.myfaces.webapp.StartupServletContextListener dispatchInitializationEvent INFO: Checking for plugins:org.apache.myfaces.FACES_INIT_PLUGINS 01/09/2010 10:27:44 org.apache.myfaces.shared_impl.config.MyfacesConfig getBooleanInitParameter INFO: No context init parameter 'org.apache.myfaces.RENDER_CLEAR_JAVASCRIPT_FOR_BUTTON' found, using default value false 01/09/2010 10:27:44 org.apache.myfaces.shared_impl.config.MyfacesConfig getBooleanInitParameter INFO: No context init parameter 'org.apache.myfaces.RENDER_HIDDEN_FIELDS_FOR_LINK_PARAMS' found, using default value false 01/09/2010 10:27:44 org.apache.myfaces.shared_impl.config.MyfacesConfig getBooleanInitParameter INFO: No context init parameter 'org.apache.myfaces.SAVE_FORM_SUBMIT_LINK_IE' found, using default value false 01/09/2010 10:27:44 org.apache.myfaces.shared_impl.config.MyfacesConfig getBooleanInitParameter INFO: No context init parameter 'org.apache.myfaces.VIEWSTATE_JAVASCRIPT' found, using default value false 01/09/2010 10:27:44 org.apache.myfaces.shared_impl.config.MyfacesConfig createAndInitializeMyFacesConfig INFO: Tomahawk jar not available. Autoscrolling, DetectJavascript, AddResourceClass and CheckExtensionsFilter are disabled now. 01/09/2010 10:27:44 org.apache.myfaces.shared_impl.config.MyfacesConfig createAndInitializeMyFacesConfig INFO: Starting up Tomahawk on the MyFaces-JSF-Implementation 01/09/2010 10:27:44 org.apache.myfaces.config.FacesConfigurator feedStandardConfig INFO: Reading standard config META-INF/standard-faces-config.xml 01/09/2010 10:27:44 org.apache.myfaces.config.FacesConfigurator feedClassloaderConfigurations INFO: Reading config : jar:file:/C:/apache-tomcat-6.0.29/webapps/autocomplete/WEB-INF/lib/primefaces-1.1.jar!/META-INF/faces-config.xml 01/09/2010 10:27:44 org.apache.myfaces.config.FacesConfigurator feedWebAppConfig INFO: Reading config /WEB-INF/faces-config.xml 01/09/2010 10:27:44 org.apache.myfaces.config.FacesConfigurator startLib INFO: Starting up MyFaces-package : myfaces-api in version : 1.2.9 from path : file:/C:/apache-tomcat-6.0.29/webapps/autocomplete/WEB-INF/lib/myfaces-api-1.2.9.jar 01/09/2010 10:27:44 org.apache.myfaces.config.FacesConfigurator startLib INFO: Starting up MyFaces-package : myfaces-impl in version : 1.2.9 from path : file:/C:/apache-tomcat-6.0.29/webapps/autocomplete/WEB-INF/lib/myfaces-impl-1.2.9.jar 01/09/2010 10:27:44 org.apache.myfaces.config.FacesConfigurator startLib INFO: MyFaces-package : tomahawk not found. 01/09/2010 10:27:44 org.apache.myfaces.config.FacesConfigurator startLib INFO: MyFaces-package : tomahawk12 not found. 01/09/2010 10:27:44 org.apache.myfaces.config.FacesConfigurator startLib INFO: MyFaces-package : tomahawk-sandbox not found. 01/09/2010 10:27:44 org.apache.myfaces.config.FacesConfigurator startLib INFO: MyFaces-package : tomahawk-sandbox12 not found. 01/09/2010 10:27:44 org.apache.myfaces.config.FacesConfigurator startLib INFO: MyFaces-package : tomahawk-sandbox15 not found. 01/09/2010 10:27:44 org.apache.myfaces.config.FacesConfigurator startLib INFO: MyFaces-package : myfaces-orchestra-core not found. 01/09/2010 10:27:44
Re: double click problem in JSF
FWIW, a server-side solution like the Shale token will be in JSF 2.1: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=559. --- Kito D. Mann | twitter: kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral +1 203-404-4848 x3 Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17 On Sun, Aug 29, 2010 at 11:45 PM, yogeen honnavar yog...@yahoo.com wrote: Dear users, We are using myfaces-1.1.5 with tomcat. We have a problem, when a user double clicks on a h:commandlink 2 submissions are sent to the server and hence the application reports an error. Can anybody suggest a solution to the double click problem. regards -yogeen
