ClassLoaderDomains and hierarchy WAS Re: [jboss-dev] Deployment chains

Adrian Brock abrock at redhat.com
Tue Oct 7 12:25:48 EDT 2008


On Tue, 2008-10-07 at 16:56 +0100, Kabir Khan wrote:
> > Finally, this still hasn't been updated to understand
> > how subdeployment classloaders work. It should be asking
> > whether the (sub-)deployment has an
> > org.jboss.classloading.spi.dependency.Module
> > attachment and hence its own classloader.
> 
> Just to be clear, can there be arbitrary levels of classloaders within  
> a deployment's sub-deployments now?

That's really two different questions/issues.

The old HeirarchicalLoaderRepository only supported one level
of hierarchy, but it could only be used with top level deployments.

The war classloader was a special case, hence all the hacks
you had to do. :-)

Now the ClassLoaderDomains can go to abitrary levels,
and Subdeployment classloaders are no longer restricted
to just wars.
Subdeployment classloaders are created in their own domains.

You can determine the rules from the Module attachments
of the deployment structure.

domain/parent -> result

1) DefaultDomain/Nothing -> this is in the default domain 
with a parent of the jboss bootstrap classloader

2) Domain1/Domain2 -> in domain1 with parent domain2
This applies to both top level and subdeployment classloaders.
i.e. if a subdeployment specifies a parent domain, it is
not a child of the top level deployment classloader

3) Domain1/Nothing -> A subdeployment classloader in domain1
with a parent domain equal to the subdeployment's parent
deployment's classloader (phew! :-).

The last one is harder to explain in English, here's an example
which should make it clearer.

Suppose you have an ear in Domain1, which has
a parent domain of DefaultDomain.
Inside the ear is a war in Domain2.

Domain2 is not directly a child of Domain1 like (2). Instead it goes
through the ear's classloader. That way it can see 
unexported classes in the ear that others in Domain1 might
not be able to see (this is the OSGi stuff again :-).

NOTE: We may in future support (3) for top level deployments.
i.e. you could have multiple root domains for your classloaders.
That case would be similar to (3) except now the parent
is the jboss bootstrap classloader like (1)
-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx




More information about the jboss-development mailing list