4

I'm trying to upgrade from JBoss 4.2.1 to JBoss 6. In JBoss 4.2.1, we are manually deploying our application as an exploded war and everything works beautifully.

I'm running into problems because the application that I am trying to deploy uses versions of 3rd party libraries that are older than the ones that JBoss 6 now includes by default. The result of this is that I'm getting classloader conflicts all over the place and the application won't even start.

At present, I have tried using the JBoss Classloading Documentation as well as the scanty bits of documentation for jboss-classloading.xml and haven't had any success.

Has anyone out there managed to do this successfully? If you have, how did you do it?

I've included a stack trace below in case it offers any useful information.

Caused by: java.lang.Error: Error visiting "/C:/jboss6/server/default/deploy/app.war/WEB-INF/lib/jaxb-xjc-2.1.12.jar/1.0/com/sun/codemodel/JConditional.class"
    at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:268) [jboss-classloading-vfs.jar:2.2.0.Alpha9]
    at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:407) [jboss-vfs.jar:3.0.0.CR5]
    at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
    at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
    at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
    at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
    at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:395) [jboss-vfs.jar:3.0.0.CR5]
    at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:102) [jboss-classloading-vfs.jar:2.2.0.Alpha9]
    at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.visit(VFSDeploymentClassLoaderPolicyModule.java:181) [:2.2.0.Alpha8]
    at org.jboss.scanning.plugins.DeploymentUnitScanner.scan(DeploymentUnitScanner.java:111) [:1.0.0.Alpha7]
    at org.jboss.scanning.spi.helpers.UrlScanner.scan(UrlScanner.java:96) [:1.0.0.Alpha7]
    at org.jboss.scanning.deployers.ScanningDeployer.deploy(ScanningDeployer.java:90) [:1.0.0.Alpha7]
    at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.Alpha8]
    ... 41 more
dskiles
  • 851
  • 1
  • 13
  • 24
  • In the last resort you can use jarjar or proguard to repackage old libs with changed namespace. – Vadzim Jan 10 '12 at 16:59

2 Answers2

0

We use the following in ear-deployer-jboss-beans.xml

<bean name="EARClassLoaderDeployer" class="org.jboss.deployment.EarClassLoaderDeployer">    
  <property name="isolated">true</property>
</bean>
Philippe Marschall
  • 4,452
  • 1
  • 34
  • 52
  • For information this the default setting of the _standard_ JBoss 5 configuration, at the opposite of the _default_ configuration. We faced the same problem. – Guillaume Husta Oct 24 '12 at 06:58
0

Have you tried "java2ParentDelegation=false"? Also you might find the below two useful

  1. jboss classloading usecases
  2. jee-j2ee-classloading-standard

Some links on fixing JAXB and JBOSS issues

Community
  • 1
  • 1
Aravind Yarram
  • 78,777
  • 46
  • 231
  • 327
  • I have tried java2ParentDelegation=false and it did not work. I think that part of the problem is that the jaxb-xjc jars are in JBoss's bootstrap classloader, and it seems like that ignores most classloading directives. – dskiles Dec 22 '10 at 15:01
  • No luck there. I ended up just going with JBoss 5.1. – dskiles Feb 11 '11 at 05:20