[
https://issues.jboss.org/browse/AS7-4048?page=com.atlassian.jira.plugin.s...
]
Stan Silvert edited comment on AS7-4048 at 4/30/12 12:05 PM:
-------------------------------------------------------------
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 with 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.
was (Author: ssilvert):
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