Hello, I have noticed some problems related to classloading with
jboss-deployer. 
Due to the JBoss classloading mechanism (cf: UCL and loader-repositories),
if you install the sar, you can't anymore deploy any web application with
spring jar even if you use the default isolated Tomcat classloader
mechanisms. To resolve definitively the problem, the best  bugfix is to
create a loader-repository for the servicemix jbi deployer sar and its JBI
components  by affecting this newly defined loader-repository to it. 
The loader-repository has to be defined in the jboss-service.xml from
servicemix-jboss-deployer and set the default java2ClassDelegation to true:


<server>
 <loader-repository>
 org.jboss:loader-repository=servicemix

<loader-repository-config>java2ParentDelegation=true</loader-repository-config>
 </loader-repository>
...

(Jboss wiki:
http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration and
related pages)
 
java2ParentDelegation=true <= to inherit from jboss server classloader et
jboss profile classloader and base service classloaders.


After it you have to modify the JBIDeployer to affect this loader-repository
to loader JBIComponents!
Examples can be found in EARDeployer.java (affect loader to
DeployementInfo).

After thos modifications, servicemix jbi service is now really safely
isolated, and the global service loader-repository, is not pollued by
servicemix jars (like spring).

The reason of that problem is the Tomcat-service and so Webapps classloaders
in jboss inherit from the jboss profile classloader which is related to the
default laoder-repository in jboss. So, there is a problem if servicemix jbi
service or jbi components jar are deployed in the same loader-repository,
because, for example spring jar will be in the scope of the webapp
classloaders, but has not been loader directly by those classloader, the
direct consequency is that spring verify if some classes have been loader by
the same classloader and crash if it is not the case! (cf: example of
namespace handlers, when loading applicationContexts).


Sorry, for my bad explanations in english, if you want better explanations,
I can explain it in french eventually.

The main thing is that it is very impotant to isolate correctly servicemix
related classloaders in jboss, to avoid strange classloader issues in other
J2EE app deployed in JBoss by using correctly Jboss classloading mechanisms.

I have tested a working patch, and all works like a charm. If you prefer to
have a directly a patch(maybe some dirty code, due to some jboss and
servmicemix underknowledges), I can send it.
-- 
View this message in context: 
http://www.nabble.com/JBoss-Deployer-3.0-Snapshot-classloading-issues-tf2694875s12049.html#a7515516
Sent from the ServiceMix - User mailing list archive at Nabble.com.

Reply via email to