Reimplementing ClassPools for AS
kabirkhan Oct 8, 2008 11:03 AMI'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:
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)