8 Replies Latest reply on May 18, 2013 9:34 AM by Scott Marlow

    JBoss 7 module hell!

    dmen Newbie

      We have a web application that uses, among others, hibernate and dom4j. The respective jars are bundled in WEB-INF/lib.


      I have been struggling to deploy on JBoss 7.1 due to module classloading problems. This is interesting because the marketing sales pitch is "No more jar hell!". No matter what I do, JBoss tries to load its own builtin jars and I end up with either ClassNotFoundException or class cast exceptions. Here is the current WEB-INF/jboss-deployment-structure.xml:



      <?xml version="1.0" encoding="UTF-8" ?>





                  <module name="org.jboss.logging" />

                  <module name="org.apache.commons.logging" />

                  <module name="org.apache.log4j" />

                  <module name="org.slf4j" />


                  <module name="org.hibernate" />

                  <module name="org.hibernate.envers" />

                  <module name="org.hibernate.validator" />


                  <module name="asm.asm" />

                  <module name="javax.api" />

                  <module name="javax.persistence.api" />

                  <module name="javax.transaction.api" />

                  <module name="javax.validation.api" />

                  <module name="org.antlr" />

                  <module name="org.apache.commons.collections" />

                  <module name="org.dom4j" />

                  <module name="org.infinispan" />

                  <module name="org.javassist" />

                  <module name="org.jboss.as.jpa" />

                  <module name="org.jboss.as.jpa.hibernate" />







      Note, I have started by excluding only org.hibernate and org.dom4j and ended, as you can see, tried excluding almost everything. No luck however. Here is the exception with this config:



      11:48:06,738 INFO  [org.hibernate.ejb.Ejb3Configuration] (MSC service thread 1-6) HHH000204: Processing PersistenceUnitInfo [

          name: xyz


      11:48:06,786 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jboss.persistenceunit."xyz-view.war#xyz": org.jboss.msc.service.StartException in service jboss.persistenceunit."xyz-view.war#xyz": Failed to start service

          at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

          at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.7.0_21]

          at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_21]

          at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_21]

      Caused by: org.hibernate.InvalidMappingException: Unable to read XML

          at org.hibernate.internal.util.xml.MappingReader.readMappingDocument(MappingReader.java:106)

          at org.hibernate.ejb.Ejb3Configuration.addXMLEntities(Ejb3Configuration.java:734)

          at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:603)

          at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:72)

          at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:162)

          at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.start(PersistenceUnitServiceImpl.java:85)

          at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

          at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

          ... 3 more

      Caused by: org.dom4j.DocumentException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory Nested exception: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory

          at org.dom4j.io.SAXReader.read(SAXReader.java:484)

          at org.hibernate.internal.util.xml.MappingReader.readMappingDocument(MappingReader.java:76)

          ... 10 more



      Keep in mind that we are trying to build a portable war bundle. That means it should be deployable without making changes to the app server, i.e.  don't want to deal with creating or modifying JBoss specific modules and such.

        • 2. Re: JBoss 7 module hell!
          dmen Newbie

          I have already tried this. We are using hibernate 4 not 3. In any case putting <property name="jboss.as.jpa.providerModule" value="hibernate3-bundled" /> in persistence.xml gives:



          Caused by: java.lang.ClassNotFoundException: org.jboss.as.jpa.hibernate3.infinispan.SharedInfinispanRegionFactory from [Module "deployment.xyz-view.war:main" from Service Module Loader]

              at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)

              at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)

              at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)

              at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)

              at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)

              ... 14 more



          -- edit 1 --



          After carefull re-reading of that document, it seems that it is impossible to use hibernate 4 bundled in war package. Specifically:


          Replacing the current Hibernate 4.0.x jars with a newer version only gives instructions about how to replace the server module.


          Later in that document Native Hibernate use sais:


          Applications that utilize JPA will automatically have the JBoss AS Hibernate injected onto the application deployment classpath.

          Meaning that JPA applications, should expect to use the Hibernate jars included in JBoss AS.



          -- edit 2 --



          This resource explains the JBoss 7 classloader priority list:


          • The maximum priority is given to modules, automatically, by the container, including the Java EE APIs. Libraries that are contained in the modules folder are included in this category.
          • Then libraries that are indicated by the user within the MANIFEST.MF of the packaged archive as Dependencies(or in the jboss-deployment-structure.xml file).
          • Next, libraries that are packed within the application itself, such as classes contained in WEB-INF/lib or WEB-INF/classes.
          • Finally, libraries that are packed within the same EAR archive (in the EAR's lib folder).


          This ofcource is against the servlet specification:


          Web Application Class Loader

          It is recommended that the application class loader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs.

          • 3. Re: JBoss 7 module hell!
            Stephen Coy Master

            What happens exactly with no jboss-deployment-structure.xml at all?


            I'm pretty sure that I've had this working in the past.

            • 4. Re: JBoss 7 module hell!
              Scott Marlow Master

              This works fine for bundling Hibernate 3 jars but not yet for Hibernate 4 jars.  I got pretty close to having the same work for Hibernate 4 jars, but hit some blocking issues in projects that were already released.  I plan on fixing this for WF8.


              If your okay with using the Hibernate 4.x jars that are already in AS7, that is the easiest (after removing the Hibernate 4.x jars from your app).  The other known fix, is to update the Hibernate jars that are in AS7, with the Hibernate 4.x version that you want to use (also remove the Hibernate 4.x jars from your app).


              Some instructions for updating the Hibernate 4.x jars are here.



              1 of 1 people found this helpful
              • 5. Re: JBoss 7 module hell!
                dmen Newbie

                I have settled with removing our hibernate 4 jars and using the server module.



                • 6. Re: JBoss 7 module hell!
                  James Perkins Master

                  If you're trying to make it portable why are you adding a implementation JAR's (Hibernate)? All Java EE servers need to have a JPA implementation so why not just use the EE standard?



                  James R. Perkins

                  • 7. Re: JBoss 7 module hell!
                    dmen Newbie

                    1) We want to use specific features of certain libraries and make sure they will be available at runtime.


                    2) Make sure that we retain exact behavior across any deployment enviroment. For example JPA provides API compatibility, however the behavior can be drastically different between implementations or even versions of the same implementation.

                    • 8. Re: JBoss 7 module hell!
                      Scott Marlow Master

                      You can track the related jira https://issues.jboss.org/browse/WFLY-1151 (add yourself to the "watching" list if you like).  You can also vote for the issue to be fixed as well.


                      In WF8, we will soon switch to combining the Hibernate persistence provider (org.hibernate module) and the persistence provider adaptor (org.jboss.as.jpa.hibernate:4 module), into the same classloader.  In AS7, the dependencies between these two modules aren't the only reason why Hibernate 4 jars could be included in the deployment. 


                      Once the WFLY-1151 issue is fixed, you will be able to help verify (using a nightly build of WF8) that your case is covered.