4 Replies Latest reply on Jan 2, 2006 12:21 PM by Dimitris Andreadis

    Deployer accepts() ordering

    Dimitris Andreadis Master

      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.


        • 1. Re: Deployer accepts() ordering
          Dimitris Andreadis Master

          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.

          • 3. Re: Deployer accepts() ordering
            Scott Stark Master

            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?

            • 4. Re: Deployer accepts() ordering
              Dimitris Andreadis Master

              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.