EAR Dependency

[vickyk]

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
http://jira.jboss.com/jira/browse/JBAS-3654

[adrian.brock]

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);
 try
 {
 // Commit the top level policy configuration
 PolicyConfiguration pc = (PolicyConfiguration)
 di.context.get("javax.security.jacc.PolicyConfiguration");
 pc.commit();
 Policy.getPolicy().refresh();
 serviceController.start(di.deployedObject);
 }
 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.

[mlange]

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?

Thanks,
Marek

[adrian.brock]

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
another.

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).