[seam-issues] [JBoss JIRA] Commented: (JBSEAM-4388) Components at ScopeType.CONVERSATION cause JBoss (4 & 5) to fail loading session state

[David Thompson (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBSEAM-4388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12499118#action_12499118 ] 

David Thompson commented on JBSEAM-4388:
----------------------------------------

Wanted to add here that I just tried to see if this would work with glassfish. Unfortunately, the problem also exists there. If I take the project and get it deployed on glassfish, run the same test I did before in JBoss. Shutdown glassfish (which should save the persistent state) and the restart it, I see the error very similar to that in JBoss shown below:

Exception loading sessions from persistent storage java.lang.ClassNotFoundException: org.safmt.TestProject.action.Test at com.sun.appserv.server.util.ASURLClassLoader.loadClass(ASURLClassLoader.java:129) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:604) at org.apache.catalina.util.CustomObjectInputStream.resolveClass(CustomObjectInputStream.java:116) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at org.apache.catalina.session.StandardSession.readRemainingObject(StandardSession.java:1926) at org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1834) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at org.apache.catalina.session.StandardSession.deserialize(StandardSession.java:1174) at org.apache.catalina.session.StandardManager.readSessions(StandardManager.java:515) at org.apache.catalina.session.StandardManager.doLoadFromFile(StandardManager.java:447) at org.apache.catalina.session.StandardManager.load(StandardManager.java:417) at org.apache.catalina.session.StandardManager.start(StandardManager.java:859) at org.apache.catalina.core.StandardContext.managerStart(StandardContext.java:4994) at org.apache.catalina.core.StandardContext.start(StandardContext.java:5311) at com.sun.enterprise.web.WebModule.start(WebModule.java:345) at com.sun.enterprise.web.LifecycleStarter.doRun(LifecycleStarter.java:58) at com.sun.appserv.management.util.misc.RunnableBase.runSync(RunnableBase.java:304) at com.sun.appserv.management.util.misc.RunnableBase._submit(RunnableBase.java:176) at com.sun.appserv.management.util.misc.RunnableBase.submit(RunnableBase.java:192) at com.sun.enterprise.web.VirtualServer.startChildren(VirtualServer.java:1762) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1244) at org.apache.catalina.core.StandardHost.start(StandardHost.java:971) at com.sun.enterprise.web.LifecycleStarter.doRun(LifecycleStarter.java:58) at com.sun.appserv.management.util.misc.RunnableBase.runSync(RunnableBase.java:304) at com.sun.appserv.management.util.misc.RunnableBase.run(RunnableBase.java:341) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619)

> Components at ScopeType.CONVERSATION cause JBoss (4 & 5) to fail loading session state
> --------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-4388
>                 URL: https://jira.jboss.org/jira/browse/JBSEAM-4388
>             Project: Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.2.0.GA
>         Environment: JBoss 4.2.3 or JBoss 5.1, jboss-seam-2.2.0, JBoss set up to hot deploy.
>            Reporter: David Thompson
>            Assignee: Dan Allen
>            Priority: Minor
>
> We currently write struts apps. One of the things we do is hot deploy these apps by setting up JBoss/Tomcat (jboss-web.deployer) to enable session persistence. This way when an app is deployed with "ant deploy", the session data can be stored out--app is torn down-- then when new app deploys the session data restores.
> If a component that is in ScopeType.CONVERSATION is instantiated and is currently in the Conversation Context when the app is deployed, then JBoss throws an error trying to reload the component and no SESSION data is restored. For example, all logged in users (data stored in Identity or Credentials) do not restore so all users get the boot. This doesn't happen if the scope on a component is EVENT or SESSION. For the way we deploy to our production system, this causes problems for us.
> The ideal solution, would be to have the conversations to come back to life, but we could also live with the conversations not being reestablished--but we really need the other session data (such as login credentials) to live through the deploy.
> AFAIK, I have looked all over the web and read the seam reference as well as Seam In Action and can't find any information about how Conversations can persist over a session (such as a redeploy this way) or over a cluster.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira