classloading issue in servicemix-jsr181 - thread context classloader not set to serviceunit classloader

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.