Deployer accepts() ordering

[dimitris]

Posting here from the dev list for reference

Bill:

I just implemented being able to deploy ejb3 archives in a .jar. To make this work, I have to guarantee that the EJB3 deployer runs
accepts() before the old EJB2.1 deployer. It seems, whoever
is added to the MainDeployer last, runs first when accepts is called.
So, I added an EJBDeployer dependency to the EJB3Deployer.

SO DON'T CHANGE THIS BEHAVIOR IN BRANCH 4.0 PLEASE!!!!!!!!!!!!!!!!

Scott:

The current behavior only exists because deployers are
inserted into the front of the deployer list, and then
queried in order. This should probably be ordered based on
the suffix ordering available from the SubDeployerExt.
getEnhancedSuffixes such that deployers with conflicting
suffixes are ordered based on the suffix priority. The
EJB3Deployer does not support this interface due to the
attempts to run it in earlier server versions.

There needs to be a testcase to validate that one can added a
deployer and take priority over accepting deployments for
which a deployer already exists.

[dimitris]

I think suffix ordering (suffixes supported by a deployer) and deployer processing order (i.e. accepts(deploymentInfo)) are 2 different things.

This is more evident in the new deployer design proposed by Adrian, where the deployers not only do "accepts()" but they also do "process()" operating in a chain. Then it is even more important to be able to define exactly the processing order, like the interceptors in a stack.

The presence of the enhancedSuffixes attribute makes the relativeOrder attribute redundant, so we could use it to indicate deployer registration/processing order and make it more explicit. At least, this is what I had in mind for the new deployers, but we'll need to use a different numbering scheme to show this is different from suffix ordering (e.g. EJBDeployer 30, BeanShell deployer 40, etc.)

If enhanchedSuffixes is not present (bill's ejb3 deployer case) we would fall back to the current behaviour (add the deployer at the beginning of the list), in which case using a dependency on another deployer we want to "override" will do the trick.

[dimitris]

Testcase task
http://jira.jboss.com/jira/browse/JBAS-2619

[starksm64]

Yes, we are moving to an aspectized deployer model, but we are talking about the 4.0 behavior. The suffix ordering is related to deployer accepts in the sense that the suffix order is the default deployment order. For a given suffix (.jar for example), we have either the added order or the relative ordering of the xar suffix order as expressed by the deployer as mechanisms for determining which deployer should have first chance at accepting the xar deployment. As you say we could use the relativeOrder attribute of the subdeployer for this as well.

The other extreme is to simply introduce a pipeline approach, but this impacts all deployers and would not be backward compatible, so its not really an option for 4.0.

Is the relativeOrder actually being used currently?

[dimitris]

relativeOrder is used when the enhancedSuffixes attribute is missing, which is the case for Bill's deployers that come from HEAD (EJB3Deployer and I think the experimental Spring one). Otherwise it is ignored.