2 Replies Latest reply on May 7, 2003 6:56 AM by Juha Lindfors

    Redeployment leads to ClassCastException (NOT jndi.propertie

    Randahl Fink Isaksen Novice

      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)

        • 1. Re: Redeployment leads to ClassCastException (NOT jndi.prope
          Randahl Fink Isaksen Novice

          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?

          • 2. Re: Redeployment leads to ClassCastException (NOT jndi.prope
            Juha Lindfors Master

            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.