About JBoss5 classloader

[jnesta]

Hi,

I am a new bie for JBoss5.

In my project, modules are deployed in $JBOSS_HOME/server/xxx/deployers and $JBOSS_HOME/server/xxx/deploy.

Classes loaded in deployers dir are visible for modules in deploy dir.

Is this a common usage?

I read some articles:

http://community.jboss.org/wiki/JBossClassLoadingUseCases

http://java.dzone.com/articles/jboss-microcontainer-classloading

I do a test and deployed structure is as follows:

- deployers

     - a.beans/a.jar (A.class)

-deploy

     - b.beans/b.jar (B.class)

A.java snippet:

public class A {

     public void start() {

          System.out.println(this.getClass()..getClassLoader());

          // and print parent and ancestor classloader

     }

}

jboss-beans.xml

<bean name="a" class="A.class"></bean>

The result is that A and B are loaded by different BaseClassLoader instance whose parent is null.

And classloader informations print:

[null, BaseClassLoader@3bfb66{vfsfile:/C:/dev/server/jboss-5.1.0.GA/server/minimal/deployers/a.beans/}]

[null, BaseClassLoader@fcfd10{vfsfile:/C:/dev/server/jboss-5.1.0.GA/server/minimal/deploy/b.beans/}]

Question:

1. During jboss starts, class A is visible to B, but B is not visible to A. Does this mean that they doesn't belong to the same domain (DefaultDomain)?

2. Does UCL(UnifiedClassLoader3) in http://community.jboss.org/wiki/JBossClassLoadingUseCases match BaseClassLoader?

I think that it doesn't because they have different parent classloader.(UCL's parent is NoAnnotationURLClassLoader or HierachicalLoaderRepository3$NoParentClassLoader, but BaseClassLoader's parent is null).

Regards,

Nesta

[alesj]

1. During jboss starts, class A is visible to B, but B is not visible to A. Does this mean that they doesn't belong to the same domain (DefaultDomain)?

Yup, both should be in the same domain - DefaultDomain.

How can you tell B is not visible to A?

2. Does UCL(UnifiedClassLoader3) in http://community.jboss.org/wiki/JBossClassLoadingUseCases match BaseClassLoader?

The semantics should be pretty much the same, at least that's what we wanted to support. :-)

[jnesta]

Hi Ales,

Thank you very much.

Yes, both are in DefaultDomain. I see this in jmx-console.

Yup, both should be in the same domain - DefaultDomain.

How can you tell B is not visible to A?

A.java snippet
public class A {
     public void start() {
          System.out.println(this.getClass()..getClassLoader());
          // and print parent and ancestor classloader
          System.out.println(new B());
     }
}

When JBoss starts, NoClassDefFoundError is thrown out.

According to my understanding, two BaseClassLoader instances for a.beans and b.beans share a same class repository (DefaultDomain). If B is visible to A, then BaseClassLoader for a.beans can load class B.
The scenario contains servel steps:
1. BaseClassLoaders are registered to class repository (DefaultDomain)
2. BaseClassLoader for a.beans trys to load class B, and it trys from class repository, but it can't find.
3. Because BaseClassLoader for b.beans declares that it can load class B
4. Class repository delegates BaseClassLoader for b.beans to load class B

But this doesn't explain why NoClassDefFoundError happens.

Another question:
When is contextClassLoader of current thread set in JBoss5?

Regards,
Nesta

[alesj]

But this doesn't explain why NoClassDefFoundError happens.

OK, I see your problem.

The reason why B is not found in A is b/c of the way we deploy deployers/ vs. deploy.

ProfileService in AS deploys different parts of AS libs in different phases.

(1) bootstrap phase -- conf/bootstrap/ dir

(2) deployers/

(3) deploy/

So, at the time your A class in deployers/a.jar is deployed, B class in deploy/b.jar is not yet deployed,

hence no matching classloader.

If you would lazy load A, only checking B when you know it's gonna be available, it would be OK.

When is contextClassLoader of current thread set in JBoss5?

Different sub-systems set if differently.

If you're asking about deployes/VDF, then the answer is DeployerWrapper class.