[jira] Commented: (SM-396) classloading issue in servicemix-jsr181 - thread context classloader not set to serviceunit classloader

["Philippe Pinheiro (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/activemq/browse/SM-396?page=comments#action_36031 ] 

Philippe Pinheiro commented on SM-396:
--------------------------------------

I'm also working on the classloader behavior and I found something that is probably linked to your issue.

In a JBI component, if you display at the beginning of the init and start  method the current thread Context class loader like this :

                java.net.URLClassLoader loader = (java.net.URLClassLoader)Thread.currentThread().getContextClassLoader();
		
		System.out.print("classLoader:\n"
		        + "hashcode: " + loader.hashCode() + "\n"
		        + "URLs: " + java.util.Arrays.asList(
		        		loader.getURLs() ) + "\n");

you will see that :

 in init method :  the  thread Context class loader is valid (it's the ((XBeanServiceUnit) getServiceUnit()).getConfigurationClassLoader() )
 in start method :  the  thread Context class loader is the Servicemix Classloader

I think that the component start method is not correctly implemented,  it should also set the thread Context class loader as for the init

FYI : You should focus on  : \servicemix-core\src\main\java\org\apache\servicemix\jbi\framework\ComponentMBeanImpl .java





> classloading issue in servicemix-jsr181 - thread context classloader not set to serviceunit classloader
> -------------------------------------------------------------------------------------------------------
>
>          Key: SM-396
>          URL: https://issues.apache.org/activemq/browse/SM-396
>      Project: ServiceMix
>         Type: Bug

>   Components: servicemix-jsr181
>     Versions: incubation
>     Reporter: Renaud Bruyeron
>  Attachments: patch.txt
>
>
> the registerService() method in Jsr181Endpoint is running with the servicemix classloader as the thread context loader, instead of the serviceunit classloader.
> This creates problems when xfire tries to load interface classes referred to by the @WebService(endpointInterface="...") annotation on the implementation class. These classes are loadable via the serviceunit classloader, but not via the main classloader.
> This is what I see during deployment of the soap-binding example:
>                                         <loc-message>Couldn't find endpoint interface soap.AnnotatedSimpleService. Nested exception is java.lang.ClassNotFoundException: soap.AnnotatedSimpleService</loc-message>
>                                         <stack-trace><![CDATA[org.codehaus.xfire.annotations.AnnotationException: Couldn't find endpoint interface soap.AnnotatedSimpleService. Nested exception is java.lang.ClassNotFoundException: soap.AnnotatedSimpleService
> java.lang.ClassNotFoundException: soap.AnnotatedSimpleService
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>         at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
>         at org.codehaus.classworlds.DefaultClassRealm.loadClassDirect(DefaultClassRealm.java:412)
>         at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:376)
>         at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>         at org.codehaus.xfire.util.ClassLoaderUtils.loadClass2(ClassLoaderUtils.java:123)
>         at org.codehaus.xfire.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:104)
>         at org.codehaus.xfire.annotations.AnnotationServiceFactory.loadClass(AnnotationServiceFactory.java:211)
>         at org.codehaus.xfire.annotations.AnnotationServiceFactory.create(AnnotationServiceFactory.java:110)
>         at org.apache.servicemix.jsr181.Jsr181Endpoint.registerService(Jsr181Endpoint.java:254)
>         at org.apache.servicemix.jsr181.Jsr181XBeanDeployer.validate(Jsr181XBeanDeployer.java:39)
>         at org.apache.servicemix.common.xbean.AbstractXBeanDeployer.deploy(AbstractXBeanDeployer.java:102)
>         at org.apache.servicemix.common.BaseServiceUnitManager.doDeploy(BaseServiceUnitManager.java:87)
>         at org.apache.servicemix.common.BaseServiceUnitManager.deploy(BaseServiceUnitManager.java:68)
>         at org.apache.servicemix.jbi.framework.DeploymentService.deployServiceAssembly(DeploymentService.java:526)
>         at org.apache.servicemix.jbi.framework.AutoDeploymentService.updateArchive(AutoDeploymentService.java:236)
>         at org.apache.servicemix.jbi.framework.AutoDeploymentService$2.run(AutoDeploymentService.java:507)
>         at org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:291)
>         at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source)
>         at java.lang.Thread.run(Thread.java:595)
> ]]>
> If I replace the TCL with ((XBeanServiceUnit) getServiceUnit()).getConfigurationClassLoader() right before the call to factory.create(serviceClass, ...) then all is well.
> The patch attached modifies the soap-binding example to deploy a jsr181-annotated service as well. This triggers the bug.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira