[Design of POJO Server] - Re: Domain interaction when there is scoping
by adrian@jboss.org
"scott.stark(a)jboss.org" wrote :
| 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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124037#4124037
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124037
16 years, 11 months
[Design of POJO Server] - Domain interaction when there is scoping
by scott.stark@jboss.org
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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123960#4123960
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123960
16 years, 11 months