Domain interaction when there is scoping

[starksm64]

The last problem I'm seeing with pulling the war deployer class loader creation into the WarClassLoaderDeployer is a failure for a war in a scoped sar to see classes from the sar. The sar has a separate ClassLoaderDomain resulting from a scoped sar LoaderRepositoryConfig being mapped by the HackClassloaderMetaDataDeployer. I'm not seeing any interaction between the sar ClassLoaderDomain and the default ClassLoaderDomain that the war class loader is associated with.

I guess the war class loader needs to be using the same ClassLoaderDomain as the sar. The problem is, its not available in the DeploymentUnit. Only the ClassLoader and ClassloaderMetaData is. Although the domain name is in the ClassloaderMetaData, I don't have access to the ClassLoaderSystem to lookup the domain without setting it. I do happen to have access to this because the WarClassLoaderDeployer needs it for other reasons, but we need to make it easier for subdeployments to build class loader in the correct domain.

[adrian.brock]

but we need to make it easier for subdeployments to build class loader in the correct domain.

That's what I said above. Instead of trying to hack something for the war classloader
use case, let's try to do this generically in the structure metadata
such that any subdeployment can say its classpath isn't to be added to the
root classloader of the deployment, instead a new
subdeployment classloader is built "on top of" the deployment classloader.

This is going to have to be modelled in the "Classloading" anyway since
you can image the case where you have two wars that
explictly import different versions of log4j for example in the same ear.
i.e. the log4j classes don't come from the WEB-INF/lib they are imported from
a repository based on version constraints.

[starksm64]

So is this something you will do? I was not expecting this for beta4.

[starksm64]

For now I have updated the HackClassloaderMetaDataDeployer to create a ClassLoaderMetaData for child deployments with the domain copied from the top-level ClassLoaderMetaData.

[adrian.brock]

So is this something you will do? I was not expecting this for beta4.

No it won't be in beta4. Its needs an OSGi style repository first. :-)

The deployments that are pulled from the repository and use real imports
will need to go into a seperate domain (the domain isn't really used
except to determine the parent classloading context - importAll = false)
otherwise they will be picked up by the importAll processing for other deployments.

e.g. in the example above, you don't want two different versions of log4j
in the DEFAULT_DOMAIN.