It should work. I'll test out ordering the JBossWebAppParsingDeployer relative to the WebAppParsingDeployer. When is the JAXWSDeployerJSE getting deployed?
Also, I think we need a notion of being relative to another deployer/deployer band. Right now we only have a notion of Deployer bands as a starting point, and its more typical that deployer x needs to be +/- another deployer rather than +/- one of the specified bands.
/** The parser order */ public static final int PARSER_DEPLOYER = 2000; /** The class loader order */ public static final int CLASSLOADER_DEPLOYER = 4000; /** The postprocessing class loader order (usage: AOP) */ public static final int POSTPROCESS_CLASSLOADING_DEPLOYER = 5000; /** The component order */ public static final int COMPONENT_DEPLOYER = 7000; /** The real order */ public static final int REAL_DEPLOYER = 10000;
Note that the default relativeOrder value (if your subclassing one of the Abstract* deployers) is not going to be 0. Are you sure you are even hitting this lookup code?
Looking more at your code, no, this is not allowed. You are trying to change the order of another deployer. You can only set your order.
Not exactly dynamic behaviour but you can set the relative order to webDeployer.getRelativeOrder() - 1
In testing out the change where the JBossWebAppParsingDeployer orders itself relative to the WebAppParsingDeployer, I see that the jbossws layer is installer a KernelLocator:
11:04:13,653 INFO [ServiceEndpointManager] WebServices: jbossws-2.0.0.CR1 (date=200610271913) 11:04:13,698 ERROR [BeanMetaDataDeployer] Error during deployment: KernelLocatororg.jboss.deployers.spi.DeploymentException: Error deploying: KernelLocator at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49) at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:71) at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42) at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:53) at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52) at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:145) at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:440) at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:451) at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:381) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:366) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:246) at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89) at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:401) at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:340) at org.jboss.Main.boot(Main.java:210) at org.jboss.Main$1.run(Main.java:508) at java.lang.Thread.run()V(Unknown Source) Caused by: java.lang.IllegalStateException: KernelLocator is already installed. at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:249)
As a general rule we need to be scoping the bean names to the context adding the beans as we should not have beans that are implementation details of a context clashing with the bean names from other contexts.
So it is working as expected, but having the deployer interact with the kernel registry of deployers to figure out a deployer relative order is really a kludge. First, this cannot be tested trivially as there is no requirement by the MainDeployer for the deployers to even be registered with the kernel. It a propagation of usage context details like running in an mc that should not be needed.
I'm going to start a pojo server thread to talk about handling this as the MainDeployer level.