Redeployment leads to ClassCastException (NOT jndi.propertie

[randahl]

I have a helper class which helps me look up home interfaces of EJBs. It works fine but after redeployment a ClassCastException is thrown. Before redeployment it looks up an EJB home and casts it to an interface which all my EJB homes implement:

dk.rockit.puls.entity.LocalEntityHome, hash code=12433070

After redeployment of my EAR, when the helper looks up the same EJB home, it again tries to cast the home to the interface above, but this leads to a ClassCastException. It turns out that the interface which my EJB home now implements is:

dk.rockit.puls.entity.LocalEntityHome, hash code=5182640

Reading the docs I found out that this is related to something about the class being loaded by different class loaders.

Now, I would really appreciate some help with this so here is some more information about what is happening:

When the ClassCastException occurs the stack trace is similar to this (full stack trace at the bottom):

My client invokes one of my session beans through RMI. This session bean invokes the helper class which looks up the home and tries to cast it.

My application is deployed as an EAR with an EJB.jar and a WAR inside. I also have a SAR which contains an MBean which helps initializing my server side.

===== Stack trace =====
at dk.rockit.puls.value.configuration.ValueBinding.lookupLocalHome(Value
Binding.java:82)
at dk.rockit.puls.value.configuration.ValueBinding.getLocalEntityHome(Va
lueBinding.java:119)
at dk.rockit.puls.service.value.ValueServiceBean.findValueByMethod(Value
ServiceBean.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(S
tatelessSessionContainer.java:629)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invo
ke(CachedConnectionInterceptor.java:186)
at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(Stat
elessSessionInstanceInterceptor.java:72)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInte
rceptor.java:84)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxIntercep
torCMT.java:243)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:1
04)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.
java:117)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFacto
ryFinderInterceptor.java:122)
at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessi
onContainer.java:322)
at org.jboss.ejb.Container.invoke(Container.java:674)
at sun.reflect.GeneratedMethodAccessor64.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:
359)
at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.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:4
60)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport
.java:701)
at java.lang.Thread.run(Thread.java:536)

[randahl]

I just discovered something interesting. I was suspicious about having an independent SAR and EAR thinking they might then get different class loaders which might result in the ClassCastException, so I tried deploying the SAR as a root element of my EAR. This did not work because the SAR was never discovered by JBoss, but I found out that when the SAR is not deployed the class cast problem goes away. This indicates that my assumption about the two different class loaders coming into play because of the two independent archives might be right. The question now is: How can I deploy my SAR as part of the EAR so they both share the same class loader?

[juhalindfors]

Either create one deployment unit (with "russian dolls" or whatever) and redeploy everything at once (resulting in everyone sharing the same classloader) or put all your EJB interface classes within the helper package that does the lookups and remove from everywhere else thus ensuring only one classloader owns the interfaces.