ClassLoader for a subdeployment
adrian.brock Feb 22, 2008 5:57 AMOne of the things left to do is the managed classloader for a subdeployment.
This is so we can use the new classloader framework for the war classloader
which would include having OSGi style imports for the isolated wars.
The way I'm planning to do it, is that if a subdeployment has a ClassLoadingMetaData
then it will trigger this processing.
The subdeployment will become a classloading "Module" in its right,
capable of importing dependencies that are different to the main classloader
of the deployment.
Also, its ClassPath will NOT be included in the main classloader classpath.
For the war classloader I expect this to be triggered by a specific deployer
that decides that wars should get their own classloader
and what the default policy should be, e.g. excluded classes, parent first, etc.
The are some gotchas:
OLD LOADER REPOSITORY CONFIG
Previously we only checked for subdeployment classloader config
for a war (and then only if the useJBossClassloade was configured).
e.g. a loader repository config in a jboss.xml of a nested ejb jar
would be ignored.
With this new feature, it wouldn't be ignored anymore and
the nested ejb would get its own subclassloader.
We can probably fix this in the "hack" that ignores it for non-wars
or at least add a warning?
PARENTS
There are two ways to implement it, both have issues.
1) Just create a classloader with the main deployment classloader as the parent.
This may run into the circularity issue in the Sun Classloader,
although, I haven't seen it myself with the Tomcat classloader doing this?
2) With the new classloader we can create an hierarchical domain
with the main deployment classloader as parent. This would allow us
to "schedule" the classloading like we do for other hierarchical domains.
But this means creating a domain for the subdeployment classloader (not a big issue),
it's more ugly that the "parentDomain" in the metadata would be ignored since the parent
is already defined to be the main deployment classloader.
PROPOSAL
I'm going to try to implement it as (2), since having a domain
would also allow multiple copies of a dependency.
e.g. two wars with servlet style classloading could OSGi style
import apache clogging and we could let them have their own
singletons/versions of the classes.
i.e. for isolated classloading, the import would be a peer clasloader in the
sub-deployment's constructed domain not visible to others.
JOKE:
WAR developers like to have their own singletons and other junk.
Admins don't trust them and so like to give them their own sandbox. ;-)