Stateful passivation problem

[minouche]

I have a statefull session bean A that contains the remote interface of an other statefull session bean B, and A won't activate after passivation.
To solve the problem, i must say B=null in ejbPassivate() of A and
"rebuild" B in ejbActivate() of A.

Can anyone tells me what's wrong?

[darranl]

Which JBoss version are you using? I think that I remember a bug being reported at sourceforge.net for this one.

[stan2004]

Hi !
After activation of serialized session beans JBoss (I use 2.4.10)
don't delete *ser files (actualy if bean live in package - i.e. - bean serialized
file lay ander directory that named like package name - see jboss sources and
java doc - java.io.File don't delete file if you point to file thru directory)

IMHO, particular decision of this:
put in bin/run.sh:
rm -fr /usr/local/jboss-2.4.10/db/sessions/*

[minouche]

I'm using jboss 3.2.5 whith jdk 1.3.1 and when i see in tmp directory, the .ser file exists.
I tried to serialize and deserialize my EJB manually (using JBOSS function) and java won't deserialize my EJB , do you think it could be a bug in jdk1.3.1?

Thank you

[minouche]

It does the same whit jdk 1.4.

What is strange is that no error occurs during passivation but when the client
wants to access to the ejb again, ejbActivate is never called and the following error occur in jboss :

11:16:04,187 ERROR [LogInterceptor] RuntimeException:
java.lang.NullPointerException
at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:128)
at org.jboss.ejb.plugins.TxInterceptorBMT.invokeHome(TxInterceptorBMT.java:56)
at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invokeHome(StatefulSessionInstanceInterceptor.java:102)
at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:120)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:93)
at org.jboss.ejb.StatefulSessionContainer.internalInvokeHome(StatefulSessionContainer.java:404)
at org.jboss.ejb.Container.invoke(Container.java:743)
at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:360)
at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
at sun.rmi.transport.Transport$1.run(Transport.java:148)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
at java.lang.Thread.run(Thread.java:534)

[darranl]

Just been searching for the bug I referred to earlier

http://sourceforge.net/tracker/index.php?func=detail&aid=988143&group_id=22866&atid=376685

The reported bug is slightly different to your problem but it is similar.

The bug aparently has a fix in JBoss 3.2.6RC1