1 Reply Latest reply on Mar 2, 2010 10:58 AM by Ales Justin

    JBDEPLOY-243 or change deployment's relative order

    Ales Justin Master

      They want a -properties.xml to be deployed as a -service.xml
      but for the -properties to go first in the REAL stage
      so it can set the system properties before the mbeans
      are created.

      Currently we don't order components -- with this new feature we will have to,

      otherwise we cannot order deployments with multiple matchings.

      e.g. both -properties.xml and -service.xml in the same sub-deployment

      NOTE: The setting of the relative order should be always
      done, like the init() call. e.g. if the metadata
      comes from manangement console rather than from the file.

      Based on what would an init() pick-up metadata and set the relative order?

        • 1. Re: JBDEPLOY-243 or change deployment's relative order
          Ales Justin Master

          They want a -properties.xml to be deployed as a -service.xml
          but for the -properties to go first in the REAL stage
          so it can set the system properties before the mbeans
          are created.

          Currently we don't order components -- with this new feature we will have to,

          otherwise we cannot order deployments with multiple matchings.

          e.g. both -properties.xml and -service.xml in the same sub-deployment

          This is now done.

           

          There is a helper method on AbstractDeployer

             /**
              * Change relative order on unit.
              *
              * @param unit the deploymenty unit
              * @param relativeOrder the relative order
              */
             protected static void changeRelativeOrder(DeploymentUnit unit, int relativeOrder)
             {
                if (unit instanceof DeploymentUnitExt)
                {
                   DeploymentUnitExt ext = (DeploymentUnitExt) unit;
                   ext.changeRelativeOrder(relativeOrder);
                }
             }
          
          

           

          which changes the relative order of given DeploymentUnit, while also notifying its parent of the change.

          So, the next time you invoke any of the getters on the parent -- getChildren or getComponents -- those are re-ordered.

           

          If one wants to keep the order consistent through out the deployment lifecycle, it must also reset the value to previous at undeploy.

          e.g. we change the order 1st time, using it in some X deployer, then we change it the 2nd time, for Y, expecting both to hold also on undeploy

           

          If there were multiple such changes, my guess is it would probably be hard to keep things under control.

          But I doubt there will be more than 1-2 changes in the whole lifecycle.