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

[Kabir Khan]

I've moved this part of the discussion here
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181042#4181042
On 7 Oct 2008, at 17:25, Adrian Brock wrote:

> 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
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development