Ear deployment ordering broken in trunk

[brian.stansberry]

Looks like EAR deployment ordering stuff done last summer for 4.0.5 is missing in trunk. This is resulting in the same types of test failures I had last year in http://jira.jboss.com/jira/browse/JBAS-3503.

Seems like there are two problems:

1) The http://jira.jboss.com/jira/browse/JBAS-2904 fix needs to be ported. In particular J2eeApplicationMetaData in trunk doesn not support the module-order config element.

2) By default, the old implicit ordering is no longer occuring (e.g. deploy a -ds.xml before an ejb jar). There was some discussion last year in http://www.jboss.com/index.html?module=bb&op=viewtopic&t=78376 of not having the implicit behavior be default in 5.0, so this might not be necessary.

If this isn't something where there's a plan to completely redo how this works, I'll open a JIRA for the above.

[dimitris]

I think explicit ordering should be the default for EARs in JB5, but we most probably need a flag to fall back to the legacy behavior.

But it depends if the new deployment framework can support the legacy behavior?

[adrian.brock]

There shouldn't be any need to define the ordering.

If the services (including ejb and web modules) have the correct dependencies
it does not matter.

However, deployment (rather than service) dependencies are on the road map
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036378#4036378
these will include "implicit" rules like:

Russian doll ordering
Explicit ordering
All or nothing deployment (either all the subdeployments are deployed or none are)
etc.

In fact, we'll likely support "random order" so people can check
that they have all dependencies defined (i.e. they are not being implicit)
but this is more useful for testing our dependencies are properly specified.

[wolfc]

I still don't get it for an EAR.

In this case there is: ear = client jar + ejb jar (no metadata / javaee 5)

Since it's going depth first, I don't get a chance to register dependencies, because they are unresolvable without the ejb jar being deployed (/ parsed).

So here we see it dive into the client jar:

2007-07-10 10:37:58,824 INFO [org.jboss.ejb3.deployers.AppClientScanningDeployer] mainClass = class com.sun.ts.tests.ejb30.bb.session.stateless.annotation.appexception.annotated.Client
2007-07-10 10:37:58,876 DEBUG [org.jboss.ejb3.deployers.Ejb3ClientDeployer] deploy vfsfile:/home/carlo/work/jboss-head/build/output/jboss-5.0.0.Beta3/server/cts/tmp/jsr88/ejb3_stateless_appexception_annotated.ear/ejb3_stateless_appexception_annotated_client.jar
2007-07-10 10:37:58,877 DEBUG [org.jboss.ejb3.deployers.Ejb3ClientDeployer] Creating client ENC binding under: ejb3_stateless_appexception_annotated_client
2007-07-10 10:37:58,898 WARN [org.jboss.injection.EJBHandler] IGNORING DEPENDENCY: unable to find @EJB from interface only com.sun.ts.tests.ejb30.common.appexception.AppExceptionIF in application-client.xml of ejb3_stateless_appexception_annotated_clientnot used by any EJBs
2007-07-10 10:37:58,913 WARN [org.jboss.injection.EJBHandler] IGNORING DEPENDENCY: unable to find @EJB from interface only com.sun.ts.tests.ejb30.common.appexception.RollbackIF in application-client.xml of ejb3_stateless_appexception_annotated_clientnot used by any EJBs

[adrian.brock]

The depenendencies work at the STAGE level, not the flow level.

They are primarily being introduced for classloading dependencies,
so one deployment that depends upon another module won't create its classloader
until a dependent classloader is constructed (and vice-versa at undeployment).

Similary, there is a new "INSTALL" stage, which is where the real REAL deployers :-)
should be. i.e. the ones that create (it should be register) the runtime objects.

So you can do things like "All or Nothing" by requiring that all deployments in a group,
(e.g. an EAR) have passed their "REAL" stage successfully before they are all moved to the
"INSTALL" stage.

In that context, "REAL" is not such a good name anymore. :-)

[wolfc]

It's not about stages. Both ejb deployers and client deployers should have the same stage configuration.

It's about the client container (/ component) being dependent on stuff from a sister deployment unit. But the client container doesn't know which sister, or even if there is one. The only thing I can state for certain is that it wants to be last in line (sort of). It's the EAR deployment rules that are not being followed.
Note that there is no EAR metadata, so we have to come up with the EAR deployment order.

[wolfc]

If I modify EARStructure to sort the j2ee modules it all falls back into place.
Is that a way to go?

[vickyk]

"wolfc" wrote:
In this case there is: ear = client jar + ejb jar (no metadata / javaee 5)

Can you specify the order of the deployment modules in the application.xml file and see if this works ?
Also you would have to use the module-order as strict in the jboss-app.xml .

[adrian.brock]

"wolfc" wrote:
If I modify EARStructure to sort the j2ee modules it all falls back into place.
Is that a way to go?

NO. Implicit rules are broken as soon as somebody introduces other dependencies
that break the implicit rule.

[adrian.brock]

"wolfc" wrote:
It's not about stages. Both ejb deployers and client deployers should have the same stage configuration.

Of course its about stages (proper dependencies across deployments).
You shouldn't even be binding the appclient into jndi until the EJB is ready to use

What if the EJB deployment fails do you still bind the appclient into jndi?
I don't think so, but its what happens in jboss-4.x

What if the EJB is waiting for some other dependency in a totally different
deployment (that maybe will be added later - because the user forgot)?
Do you bind the appclient, again NO.

It is just a trivial case of a more generic problem that I have explained many times
but I haven't seen any movement on fixing it.

Once I've done classloading dependencies we (or more probably I ;-)
can use it as an example on how to do proper jndi (and other registry)
dependencies - inside the MC dependency mechanism.

[wolfc]

Ah yes, silly me.

I need to register a dependency on the EJB interface I'm want to resolve later on. It's not a JNDI dependency, because I don't the JNDI name (yet). I'll have a hack at it, but I still don't see a resolution for the scenario where the interface is already deployed in another jar and also being deployed later on this ear.

Note that the appclient won't come up if it can't resolve the interfaces.

[brian.stansberry]

For the original issue of testsuite failures due to the missing dependency of EJB(2) deployments on the datasources they use, I've filed http://jira.jboss.com/jira/browse/JBAS-4548.

[wolfc]

I got a basic supply demain chain working. This one is without any fancy resolution. For that I need to write a new type of demand and supply meta data.

Another thing is that when demands are not satisfied, deployment stalls. How and where can I notify the user that I've unresolved dependencies?

[adrian.brock]

The checkComplete() on the MainDeployer lists all dependencies that are not satisfied.

[wolfc]

Doh, I was afraid you would say that. I must have introduced a bug, because it doesn't do that for EJB 3 deployments.