3 Replies Latest reply on Jun 16, 2008 10:11 AM by Adrian Brock

    EAR Dependency

    Vicky Kak Master

      Can we have a dependency feature between the EAR's ?
      Right now we can have the dependency defined in the jee modules but does not yet exist at the EAR level .
      I have seen many of the users asking for such feature , can you initiate the discussion about it ?
      Here is the related JIRA

        • 1. Re: EAR Dependency
          Adrian Brock Master

          I assume for this discussion that this is JBoss-4.x

          The issue with making the EAR something that can be depdended on
          is quite complicated. There are three basic competing issues that make it difficult.

          * The EAR represents a total view of all its component's state

          This is not true now. The EAR MBean has no relationship with the other mbeans
          that are part of the deployment.
          This would require that the EARDeployment.start() lifecycle is not invoked
          until all the other mbeans that are in the EAR (ejb modules, ejb containers,
          web containers, datasources, -service.xml, etc.) are in the started state.

          This could only be achieved by collecting all the mbean names in the create() lifecycle
          stage and adding dependencies to the ear mbean.

          With that done, then the EAR mbean would become what this feature request requires.
          i.e. you add a depends tag somewhere else and guarantee that everything in the
          ear is in the started state.

          * The EAR Deployment for management operations

          Almost the exact opposite of this feature request is that you could consider
          that invoking EAR.stop() on the JMX console would stop all its components.
          This would require that rather than the EAR dependening on its components,
          the components would have to depend on the EAR MBean.

          * The EAR Deployment as a place for two stage initialisation of per deployment state

          The current usage of the EAR isn't as a service, but as something tied to the
          SubDeployer lifecycle.
          Again this is create/start/stop/destroy but it is not the service lifecycle.
          There is no dependency. The subdeployment lifecycle is just invoked
          on all the (sub)-deployments with the order determined by the prefix ordering
          and "russian doll" semantics.

          For the EAR it is this:

           public void start(DeploymentInfo di)
           throws DeploymentException
           super.start (di);
           // Commit the top level policy configuration
           PolicyConfiguration pc = (PolicyConfiguration)
           catch (Exception e)
           DeploymentException.rethrowAsDeploymentException("Error during start of EARDeployment: " + di.url, e);
           log.info ("Started J2EE application: " + di.url);

          In this case, the EAR's start transition is used to initialise the shared Jacc policy
          that has been collected from the subdeployments.

          If this is not done in the correct order because of dependencies then the
          components that use the policy are likely to fail due to the policy being
          in an invalid state.

          I think that is happening in JBAS-3664?
          But somebody with more knowledge of Jacc would need to investiage that.

          • 2. Re: EAR Dependency
            Marek Neumann Novice

            Adrian, we need a dependency mechanism urgently since we can't freely influence the namings of the .ear deployments. Do you think it would be possible to implement this and push this feature requests forward?


            • 3. Re: EAR Dependency
              Adrian Brock Master

              It's certainly possible, but that doesn't mean it is a priority.

              Since you can already declare your dependencies at the more granular
              (and arguably more correct) level, e.g. my war depends upon that ejb in a different
              deployment, I wouldn't describe it as a high priority.

              For me its just an "ease of use" feature such that in simple cases
              means you only have to declare one piece of configuration.

              In more complex cases, it wouldn't even work because the broad brush
              configuration is likely to lead to circular dependency problems
              (with dependencies going both ways between the ears).

              And such a configuration (where you don't declare the true dependency)
              is suspectible to breakage during refactoring, e.g. an ejb moves from one ear to

              The other reason it's not a high priority is because you can
              already decide what order applications should be started in using
              something like the prefix deployment sorter (modulo no other dependencies
              causing indivdual components to wait).