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

On Tue, 2008-10-07 at 16:56 +0100, Kabir Khan wrote: 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