Search Results

Search found 2 results on 1 pages for 'jboss6 x'.

Page 1/1 | 1 

  • JBoss 6 unpacks jars from WEB-INF/lib of war

    - by Maxym
    when I start JBoss 6 I see that it unpacks all jar files from WEB-INF/lib in tmp/vfs/automountXXX folder. E.g. jackrabbit-server.war contains library asm-3.1.jar, then in tmp folder I see the following folders with files: asm-3.1.jar-83dc35ead0d41d41/asm-3.1.jar asm-3.1.jar-2a48f1c13ec7f25d/contents/"unpacked asm-3.1.jar" it does not take files from my.ear/lib only WEB-INF/lib... Why is it so? And is here any way to prevent it doing so? It just slows down application server starting (and stopping), what is not that comfortable at development... If it is somehow related to JavaEE 6 specification and ejb-jars, which can be located now in WEB-INF/lib, so I don't have such libraries in my war files... UPDATE: actually when I repack jackrabbit-server.war to jackrabbit-server.ear which contains jackrabbit-server.war and moved all its libraries to jackrabbit-server.ear/lib then I still see two folders in tmp: asm-3.1.jar-215a36131ebb088e/asm-3.1.jar asm-3.1.jar-14695f157664f00/contents/ but in this case last folder is empty. So it still creates two folders, but does not unpack my library. Also I use exploded deployment so the question is only about jar files, not unpacking ear/war.

    Read the article

  • How to separate ear classloader and system classloader in JBoss 6?

    - by dskiles
    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

    Read the article

1