2 Replies Latest reply on Mar 16, 2011 6:00 AM by alesj

    JBAS-8937; dup component install

    alesj

      Trying to get rid of https://issues.jboss.org/browse/JBAS-8937 turned to be very "interesting".

      Dunno how we avoided this bug for so long.

       

      What happens in that case is the following.

       

      (1) RARDeployer adds ServiceMetaData attachment to jboss-local-jdbc.rar deployment unit.

      (2) Then AppNamingDeployer adds BeanMetaData attachment to same deployment unit.

      (3) From (2) a new component deployment unit is created

      (4) From (1) a new component deployment unit is created

      (5) ServiceDeployer goes over all component deployment units

      * for (4) it finds the right component ServiceMetaData attachment

      * for (3) it finds the ServiceMetaData in its parent ( == (1)), which is of course the same as (4)

      ==> duplicate service registry

       

      Atm I actually don't see how this ever worked,

      must have been some really lucky deployers order.

       

      I guess same could happen if the order of deployers that handle SMD and BMD would be turned.

      e.g. instead of duplicate SMD, we would get duplicate BMD

       

      Any idea how to properly fix this?

        • 1. JBAS-8937; dup component install
          alesj

          I would expect this to fail as well:

           

          acme.jar

          * META-INF

          ** foo-jboss-beans.xml

          ** foo-service.xml

           

          Where we would pick top deployment's SMD or BMD attachment in

          which ever component deployer would be the one to see 2 component deployment units.

          It would pick up the parent's attachement which would be also processed as part of component attachment.

          • 2. Re: JBAS-8937; dup component install
            alesj
            I would expect this to fail as well:

             

            acme.jar

            * META-INF

            ** foo-jboss-beans.xml

            ** foo-service.xml

            This actually works due to the fact that parent deployment unit actually holds "grouped" metadata.

            e.g. KernelDeployment for BMDs and ServiceDeployment for SMDs

            Hence no BMD or SMD attachment is found in parent dpeloyment unit.

             

            Where we would pick top deployment's SMD or BMD attachment in

            which ever component deployer would be the one to see 2 component deployment units.

            It would pick up the parent's attachement which would be also processed as part of component attachment.

            What will make it fail is if we directly put BMD and SMD into deployment unit, which is then the parent of component deployment unit.

            Which is what RARDeployer and AppNamingDeployer do.