[jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Reimplementing ClassPools for AS

[kabir.khan@jboss.com]

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.

>From dev list:
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#4181042

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181042