deployment dependencies working differently in jboss4.0.0

[berkgypsy]

I am converting from jboss3.2.0 to jboss4.0.0.

I have a war which references classes within an ear file. I have it set up so the ear deploys before the war. This works with jboss-3.2.0.

When I try doing the same thing in jboss4.0.0, I see the ear deploying, and then the war, which is correct. However, the war fails to deploy because it is not seeing the classes within the ear. Is this what is supposed to happen?

Thank you for your help

[digdon]

I believe that I'm having the same problem - when the WAR tries to deploy, I get ClassNotFoundException. I think my deployment is slightly different, though, in that the WAR is included in the EAR.

I've tried playing around with the <class-loader> and <loader-repository> tags, but I've been unsuccessful thus far.

[koreth]

I'm having a very similar problem, probably the same root cause: I have an MBean that talks to a session bean that lives in an exploded ear. It worked fine in 3.x but in 4.0.0 when it tries to do the JNDI lookup on the local home interface, I get

javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: (my EJB home class)]

I've defined a dependency on the MBean so it loads after the EJB is deployed, but that doesn't help. Something clearly changed in this area between 3.2 and 4.0.0.

[starksm64]

Read the release notes. The default configuration in jboss-4.0.0 uses scoped deployments of ears by default so deployments outside of the ear cannot see its classes. Use the standard configuration or rename the standard configuration default. The standard configuration is equivalent to the semantics found in the default configuration in 3.2.x-

[roberto72]

How can the problem be solved via "<loader-repository>" tag?

TIA
Roberto Colmegna

Read the release notes. The default configuration in jboss-4.0.0 uses scoped deployments of ears by default so deployments outside of the ear cannot see its classes. Use the standard configuration or rename the standard configuration default. The standard configuration is equivalent to the semantics found in the default configuration in 3.2.x-

[meatus]

The default configuration in jboss-4.0.0 uses scoped deployments of ears by default so deployments outside of the ear cannot see its classes

In 3.2.x any archives that we put in the deploy 'lib' folder could be found by any deployed archives. In 4.0.0, the deploy 'lib' doesn't seem to be part of the classpath for our deployed archives. We're trying to create a pluggable framework within JBoss so that later developers can use our tools to very easily create plugins that subscribe to our framework architecture. For this, we need a place where jars of common classes can exist and be accessible to any deployed archives. Isn't this what the deploy 'lib' is for? Should our manifest classpaths point to the lib explicitly?
FWIW, I tried using the standard server deployment and it worked the same as 3.2.x did. Though, if future JBoss releases are going to use a different classpath/loader scheme, we'd sure like to jump on board.