3 Replies Latest reply on Jul 21, 2004 11:43 AM by jamesstrachan

    Multiple EJB deployments with same name

    philroffe

      I am having problems deploying two EJBs with the same name. The EJBs are in different jar files, but the jar files are packaged up into a single ear file.

      The problem that is that I am trying to look up the EJB from one jar, but it is giving me back the EJB from the other jar - causing a ClassCastException.

      Has anyone encountered this problem before? How do you differentiate the two EJBs to ensure you always get the one you want?

      Thanks,
      Phil

        • 1. Re: Multiple EJB deployments with same name
          jamesstrachan

          Phil,

          It would seem that both EJB's have the same JNDI name. Deployment of the second EJB overwrites the first JNDI name so that only the second is referenced.

          Presumably, as the deployer, you haver control of the Deployment Descriptors.

          You can do one of two things. Either change the ejb-ref-name of one of the two EJB's - if they have different roles,shouldn't they have different names ?

          JBoss will normally use the ejb-ref-name of the EJB as the JNDI name.

          Or you can change the JNDI name of one EJB by adding the following code to the Deployment Descriptor jboss.xml as follows :-

          <session>
           <ejb-name>DuplicateBean></ejb-name>
           <jndi-name>NoDuplicateBean</jndi-name>
          </session>
          


          preferably using namers relevant to your application !
          James

          • 2. Re: Multiple EJB deployments with same name
            philroffe

            Thanks for your reply.

            The JNDI names are different, as you can see in the following sections of jboss.xml.

            In the jboss.xml file of one jar:

             <entity>
             <ejb-name>Customer</ejb-name>
             <jndi-name>com.jctal.productsalemgmt.sale.ejbimpl/Customer/Home</jndi-name>
             <local-jndi-name>com.jctal.productsalemgmt.sale.ejbimpl/Customer/LocalHome</local-jndi-name>
             </entity>
            


            ...and in the jboss.xml file of the other jar:
             <entity>
             <ejb-name>Customer</ejb-name>
             <jndi-name>com.jctal.pvision.prempos.ejb.customermgmt/Customer/Home</jndi-name>
             <local-jndi-name>com.jctal.pvision.prempos.ejb.customermgmt/Customer/LocalHome</local-jndi-name>
             </entity>
            


            As you pointed out, I think the problem might be related to the EJB name, although have had no success in renaming it. We use xdoclet, and if we use a different ejb-name xdoclet does not create the correct interface classes. This can be fixed by using a / in the ejb-name (e.g. com/jctal/Customer), but the ear file fails to deploy with a server excption of "The ejb-name for a CMP2.x Entity must be a valid Java Identifier".

            The following is from ejb-jar.xml and shows the <ejb-link>, where I suspect the problem might be. I suspect the Customer is ambiguous and I cannot find a way to specify it.
             <ejb-local-ref >
             <ejb-ref-name>ejb/CustomerBeanRef</ejb-ref-name>
             <ejb-ref-type>Entity</ejb-ref-type>
             <local-home>com.jctal.pvision.prempos.ejb.customermgmt.CustomerLocalHome</local-home>
             <local>com.jctal.pvision.prempos.ejb.customermgmt.CustomerLocal</local>
             <ejb-link>Customer</ejb-link>
             </ejb-local-ref>
            


            To illustrate the problem, the jndi view from the jmx-console shows the following. Notice the package name from the Customer bean is from the incorrent Entity.
            java:comp namespace of the OrderManagement bean:
            
             +- env (class: org.jnp.interfaces.NamingContext)
             | +- ejb (class: org.jnp.interfaces.NamingContext)
             | | +- SupplierOrderBeanRef[link -> com.jctal.pvision.prempos.ejb.epos/SupplierOrder/LocalHome] (class: javax.naming.LinkRef)
             | | +- CustomerBeanRef[link -> com.jctal.productsalemgmt.sale.ejbimpl/Customer/LocalHome] (class: javax.naming.LinkRef)
             | | +- OrderMessageBeanRef[link -> com.jctal.pvision.prempos.ejb.epos/OrderMessage/LocalHome] (class: javax.naming.LinkRef)
             | | +- DispensingBeanRef[link -> com.jctal.pvision.prempos.ejb.customermgmt/Dispensing/LocalHome] (class: javax.naming.LinkRef)
            



            Any thoughts would be appreciated.
            Thanks,
            Phil

            • 3. Re: Multiple EJB deployments with same name
              jamesstrachan

              Phil,

              What I think is happening is this :-

              Your reference in the ejb link shows that you are expecting to look up an EJB with a JNDI name of Customer.

              You can confirm in the JNDI view, or in the MBean view, that you are actually deploying one entity bean with the JNDI name Customer.

              Assuming that this is true, the likely cause is :-

              From inspection of the source code, JBoss makes two passes through the list of EJB's during deployment.

              In the first pass, it reads through ejb-jar.xml, assigns the ejb name, and sets the JNDI name equal to the ejb name in case there is no further reference to the JNDI name.

              In the second pass, it reads through jboss.xml, and resets the JNDI name if it finds a reference in jboss.xml. It's obviously failing to set the JNDI name at this point, for some unknown reason (doesn't like the dots ? or possibly the length ?).

              After these two passes, JBoss registers the JNDI names. But, since both EJB's have the same JNDI name of "Customer", the second registration overwrites the first.

              The immediate solution is probably to take manual control of the Deployment Descriptor so that you can use shorter JNDI names of the form :-

              ejb/productsales/Customer
              


              If your system is of any size, it's a good idea to keep a Naming Register listing all JNDI names - so that you can keep control of them.

              James