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?

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.

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

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

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.

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

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

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

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

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.

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?

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

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