[jboss-jira] [JBoss JIRA] (AS7-4048) JSF deployment failing on (clustered) domain mode with ViewExpiredException but works in standalone
Stan Silvert (JIRA)
jira-events at lists.jboss.org
Mon Apr 30 12:04:18 EDT 2012
[ https://issues.jboss.org/browse/AS7-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688879#comment-12688879 ]
Stan Silvert commented on AS7-4048:
-----------------------------------
That's a good question. It all comes down to the fact that both http://localhost:8330/infinispan-jboss-as7/home.jsf and http://localhost:8430/infinispan-jboss-as7/home.jsf are sharing the same HttpSession. Maybe that wasn't happening in the 7.0 days.
With server-side state saving, the JSF view is held in the HttpSession. On postback, the client sends the view ID and JSF retrieves the view from the session. So if the client sends an old ID, you will get the ViewExpiredException.
This can never happen with client-side state saving because the entire view state is serialized and cached in a hidden field on the client. That's why the context param fixes the problem.
So back to your app running with server-side state saving. We have two clients hitting the same cache of data. Not a problem. But if they are also sharing the same view state then that does cause a problem. I'll give an example of how we get here:
Client A does a request with no ViewId: server responds with ViewId = 0
Client A sends ViewId=0: server responds with ViewId=1
Client B sends a request no ViewId: server responds with ViewId = 2
Client A sends ViewId=1: server responds with ViewExpiredException
The problem here is the request from Client B. It should generate its own HttpSession and the server should respond with ViewId=0. But Client A and Client B are sharing the same replicated HttpSession. So the ViewId cached on the client gets out of sync.
The reason both clients share the same HttpSession is because the session ID is retrieved from a cookie on the client. The cookie only depends on HTTP domain and path. It doesn't depend on the port number, which is the only difference in the two requests.
I will make one disclaimer. I haven't verified the above scenario, but I'm pretty sure that's what is happening. No matter what, client-side state saving will fix the problem because you can never get a ViewExpiredException.
> JSF deployment failing on (clustered) domain mode with ViewExpiredException but works in standalone
> ---------------------------------------------------------------------------------------------------
>
> Key: AS7-4048
> URL: https://issues.jboss.org/browse/AS7-4048
> Project: Application Server 7
> Issue Type: Bug
> Components: JSF
> Affects Versions: 7.1.0.Final
> Reporter: Galder Zamarreño
> Assignee: Stan Silvert
> Fix For: 7.1.2.Final-redhat1
>
> Attachments: infinispan-as7.cli, infinispan-jboss-as7.war, server-four.log, server-three.log, web.xml
>
>
> I'm trying to run https://github.com/galderz/infinispan-quickstart/tree/t_710final/jboss-as7 in AS 7.1.0.Final domain mode but it fails.
> It does work fine in standalone mode. And it works fine domain too if you only hit one of the nodes, but not after both have been hit.
> So, in domain mode (regardless of browser, tried with Chrome and Firefox), once two servers are up and running and the app has been deployed to both nodes, when I try to enter a new cache entry in one of the nodes, I get:
> {code}Caused by: javax.faces.application.ViewExpiredException: viewId:/home.jsf - View /home.jsf could not be restored.
> at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:205) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]{code}
> This is pretty cryptic. After adding some logging, I see an exception being thrown earlier in the code:
> {code}11:58:57,844 FINE [javax.enterprise.resource.webcontainer.jsf.application] (MSC service thread 1-3) java.lang.NoSuchMethodException: org.jboss.as.web.deployment.jsf.JandexAnnotationProvider.<init>(javax.servlet.ServletContext, com.sun.faces.spi.AnnotationProvider): java.lang.NoSuchMethodException: org.jboss.as.web.deployment.jsf.JandexAnnotationProvider.<init>(javax.servlet.ServletContext, com.sun.faces.spi.AnnotationProvider)
> at java.lang.Class.getConstructor0(Class.java:2706) [classes.jar:1.6.0_29]
> at java.lang.Class.getDeclaredConstructor(Class.java:1985) [classes.jar:1.6.0_29]
> at com.sun.faces.spi.ServiceFactoryUtils.getProviderFromEntry(ServiceFactory.java:83) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
> at com.sun.faces.spi.AnnotationProviderFactory.createAnnotationProvider(AnnotationProviderFactory.java:70) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
> at com.sun.faces.config.ConfigManager$AnnotationScanTask.<init>(ConfigManager.java:808) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:349) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:225) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
> at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3392) [jbossweb-7.0.10.Final.jar:]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3850) [jbossweb-7.0.10.Final.jar:]
> at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90) [jboss-as-web-7.1.0.Final.jar:7.1.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_29]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_29]
> at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_29]{code}
>
> I don't know whether this is relevant at all.
> Please find attached a war and server.log files with TRACE on:
> org.jboss.weld
> org.jboss.solder
> javax.enterprise.resource.webcontainer.jsf (a very "intuitive" package for com.sun.faces, grrr)
> javax.faces
> org.infinispan
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list