0 Replies Latest reply on Apr 16, 2003 5:33 AM by Panu Hällfors

    LocalHomes of different ears get mixed when deployed at the

    Panu Hällfors Newbie


      We're using JBoss 3.0.7 and it seems that there's a problem with keeping different instances of ears separate. The problem mostly occurs when the ears are deployed at the same time (that is, they are copied in the deployment directory at the same time or when JBoss starts up with those files in deployment dir) but I once got the error with different-time deployments, too.

      Our setup:
      An ear with servlets, an ejb-client jar (contains some remote interfaces) and an ejb jar (contains implementations, local interfaces and the rest of remote interfaces). Several instances of this ear is deployed, with loader-repository set in jboss-app.xml different for each deployed ear.
      Servlets use Servlet 2.3 style classloading.

      In servlet code we do:
      Object objref = initial.lookup("local/NameOfTheBean");
      PortableRemoteObject.narrow(objref, BeanHomeType);

      Now, if you start up JBoss and copy one ear in deploy directory, wait for it to get deployed, then copy the next one and so on, everything works.
      But if you copy all the ears in the deployment directory at once (or you start JBoss with all those ears in the deployment dir), only the ear that was last deployed works. For all the others, you get:
      2003-04-16 11:22:49,788 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException:
      at com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:293)
      at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)

      Intuitively, it seems that when deployed in the same deployment cycle, the JNDI records of the local homes get overwritten by other deployments of the same bean from an other ear.

      According to our tests, the situation mostly occurs only when ears are deployed at the same time but I once also managed to get the error when re-deploying a working ear.

      Am I doing something wrong here or is this a bug in the deployer? Any ides of workarounds (besides delaying the deploying with a script, which is not really handy with hundreds of deployments...)