Hi Inigo;
yes you can set context class loader to service class loader and then
Spring to do its job , but its not the right way unless you set the context
class loader back to its original value.
The context of the service should be the deployed .AAR, so code
within the .AAR that loads classes and resources from the classpath will
try to get it first from the .AAR.
yes , it will does so , but in your case some third person try to get
service resources from CCL of the system. And that CCL dose not know any
thing about service class loader.
Thanks,
Deepal
................................................................
~Future is Open~
----- Original Message -----
From: "Inigo Surguy" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, January 19, 2006 3:29 PM
Subject: Re: [Axis2-0.94] Classpath for Axis code running inside an .aar?
Hi Deepal,
But in Spring case as I know you can not give that guy a class loader ,
what it does is it gets the context class loader and try to load resources
from that. Since service has its own class loader you can not get service
resources from context class loader.
Yes, that's right. Isn't the bug then that the contextClassLoader for
a service is the WebappClassLoader rather than the DeploymentClassLoader?
The context of the service should be the deployed .AAR, so code
within the .AAR that loads classes and resources from the classpath will
try to get it first from the .AAR.
In that scenario the best way is put your those resources in WEB-INF/lib
in that case CCL will have access to those.
Yes - that would work - but it would amount to putting almost my entire
service in the WEB-INF/lib directory, which defeats the point of having an
.AAR in the first place.
Another workaround, which is what I'm using at the moment and seems
to work, is to explicitly set the context classloader to be the class
classloader with:
Thread.currentThread().setContextClassLoader(ClasspathTest.class.getClassLoader());
Cheers
Inigo
