[ https://issues.apache.org/activemq/browse/SM-758?page=all ]
Guillaume Nodet resolved SM-758.
--------------------------------
Fix Version/s: 3.1
(was: 3.0.1)
(was: 3.0)
Resolution: Fixed
Assignee: Guillaume Nodet
Note that I have not included the servicemix-components jar, as all its
dependencies are not included.
See http://fisheye.codehaus.org/changelog/servicemix/?cs=1083
> JBoss Deployer 3.0 Snapshot classloading issues
> -----------------------------------------------
>
> Key: SM-758
> URL: https://issues.apache.org/activemq/browse/SM-758
> Project: ServiceMix
> Issue Type: Bug
> Components: tooling
> Affects Versions: 3.0.1, 3.0
> Environment: JBoss 4.02 , any System (tested on Windows XP)
> Reporter: Alexis Kinsella
> Assigned To: Guillaume Nodet
> Fix For: 3.1
>
>
> Message From Forum:
> 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.
> --------------------------------------------------------------------------------------------------
> Bug Fixes:
> 1 - In POM.xml from jboss-deployer, add this to avoid many problems with
> class no found exceptions when deploying "-sm.xml" files in JBoss :
> <!-- Added as dependency, needed by lw components, example: filebindings
> -->
> <dependency>
> <groupId>org.apache.servicemix</groupId>
> <artifactId>servicemix-components</artifactId>
> <version>3.0-incubating</version>
> </dependency>
> 2 - In Jboss-service.xml, add loader-repository like this:
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- The J2EE application client deployer service -->
> <server>
> <loader-repository>
> org.servicemix:loader-repository=JBIContainer
>
> <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
> </loader-repository>
> <mbean code="org.servicemix.jboss.deployment.JBIDeployer"
> name="org.servicemix:service=Deployer">
> <depends
> optional-attribute-name="JBIContainer">org.servicemix:service=JBIService</depends>
> </mbean>
> <mbean code="org.servicemix.jboss.deployment.JBIService"
> name="org.servicemix:service=JBIService">
> <depends>jboss:service=TransactionManager</depends>
> <attribute name="TransactionManager">java:/TransactionManager</attribute>
> </mbean>
>
> </server>
> In trunk there is a fault in actual jboss-service.xml : there is a token
> "-->" that should not be here!
> 3 - In JBIDeployer.java you should correct source like this:
> /**
> * Describe <code>init</code> method here.
> *
> * @param di
> * a <code>DeploymentInfo</code> value
> * @exception DeploymentException
> * if an error occurs
> * @jmx.managed-operation
> */
> public void init(DeploymentInfo di) throws DeploymentException {
> try
> {
> log.info("Init ServiceMix JBI Component: " + di.url);
> log.info("Init Watcher");
> initWatcher(di);
> log.info("Init LoaderRepository");
> initLoaderRepository(di);
> }
> catch (DeploymentException e)
> {
> throw e;
> }
> catch (Exception e)
> {
> log.error(e.getMessage());
> e.printStackTrace();
> throw new DeploymentException("Error in accessing application
> metadata: ", e);
> }
> super.init(di);
> }
> private void initWatcher(DeploymentInfo di) throws
> MalformedURLException {
> // resolve the watch
> if (di.url.getProtocol().equals("file")) {
> File file = new File(di.url.getFile());
>
> // If not directory we watch the package
> if (!file.isDirectory()) {
> di.watch = di.url;
> }
> // If directory we watch the xml files
> else {
> di.watch = new URL(di.url, "META-INF/jbi.xml");
> }
> }
> else {
> // We watch the top only, no directory support
> di.watch = di.url;
> }
> }
> /**
> * Add the jbi scoped repository
> *
> * @param di
> * the deployment info passed to deploy
> * @throws Exception
> */
> protected void initLoaderRepository(DeploymentInfo di) throws Exception
> {
> LoaderRepositoryConfig lrConfig = new
> LoaderRepositoryFactory.LoaderRepositoryConfig();
> lrConfig.repositoryName = new
> ObjectName("org.servicemix:loader-repository=JBIContainer");
> di.setRepositoryInfo(lrConfig);
> }
> I don't know how to affect automaticaly loader-repository from the deployer
> one, maybe, this code is a little crap, because affectation of loader
> repository is hard code, it needs to be the same than in jboss-service.xml.
> One possible thing to do, is to add the laoder-repository in META-INF or in
> another file, and get it on "initLoaderRepository" step.
> 4 - Problem related to Bug SM-584:
> I have not tested if it can resolve it, But I think eventually, if it is not
> the case, a README file should be added to explain how to install correctly
> the jboss-deployer.
> I think, that-s all about classloading issues I met!
--
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
