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.