I'm going to bite the bullet and attempt to reimplement how the JBoss ClassPools work. I am currently working on pre-OSGi with classloaders organised by domains. Although I doubt I will have time to implement the OSGi part before AS 5.0.0.GA I would at least like to add the correct properties to my classes at this stage. A few questions *I seem to mention you saying that if using OSGi, the classloaders are typically in the same domain with correct import/export rules set? *How can I access all the rules for import/export for a (sub-)deployment from a deployer? That should give me the information I need about the available options. anonymous wrote : | On 7 Oct 2008, at 17:25, Adrian Brock wrote: | | anonymous 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) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181042#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...