1 2 3 4 5 Previous Next 68 Replies Latest reply: Apr 17, 2012 8:54 AM by Ales Justin Go to original post RSS
  • 60. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Ales Justin Master
    In fact all issues come from the fact JBoss load the persistence.xml too early. I've tested to update the <provider> tag with a little patch by using "org.hibernate.ejb.HibernatePersistenceMyImpl" (this class has to start with "org.hibernate.ejb.HibernatePersistence" to be considered by Hibernate configuration, but hibernate dos not use the CL of this provided class, but the one of "PersistenceUnitInfo"  (see Ejb3Configuration#configure(PersistenceUnitInfo, Map). One solution could consist to wrap the "PersistenceUnitInfo" with a custom proxy class to force the CL....

    How would it actually got this class' CL if first needs to load the class itself?

    Which CL comes from PUInfo? I would expect app's ...

     

    Anyway, to be fully compliant with JBoss (and some other JEE servers) I've switch to this solution : http://fabdouglas.blogspot.com/2011/01/how-to-run-spring-3-jpa-application-to.html

    You can actually force JBossAS to ignore persistence.xml with jboss-ignore.txt,

    so not really neccessary to rename the file.

     

    This way of course you delegate the work to ext lib, which then loads local classes first.

     

    But in my test, I later on had issues with EJB, which uses Hibernate for its timers handling.

    Afaik, Jaikiran is looking into the issue, as EJBs + timers handling should not overlap with deployment's JPA usage.

     

    btw: nice and useful blog post :-)

  • 61. How to stop my WAR loading JBoss's provided 3rd party classes?
    Fabrice Daugan Newbie

    Ales Justin wrote:

    You can actually force JBossAS to ignore persistence.xml with jboss-ignore.txt,

    so not really neccessary to rename the file.

     

    In fact renaming this file make the EAR/WAR runnable on all JEE servers, not only JBoss. All JEE servers are not as configurable as JBoss is.

  • 62. How to stop my WAR loading JBoss's provided 3rd party classes?
    Tom Muldoon Newbie

    I’m afraid that I haven’t been able to get past the issue in which JBoss’s version of Hibernate (3.6) is used instead of my version of Hibernate (3.2.6) which is deployed in WEB-INF/lib as evidenced by the stack trace…

     

    Caused by: java.lang.AbstractMethodError: org.springframework.orm.jpa.persistenceunit.SpringPersistenceUnitInfo.getSharedCacheMode()

    Ljavax/persistence/SharedCacheMode;

            at org.hibernate.ejb.util.LogHelper.logPersistenceUnitInfo(LogHelper.java:39) [:3.6.0.Final]

            at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:516) [:3.6.0.Final]

            at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:73) [:3.6.0.Final]

            at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:224) [:2.5.5]

            at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:291) [:2.5.5]

            at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1368) [:2.5.5]

            at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1334) [:2.5.5]

            ... 165 more

     

    Here's the log entry proving that my WEB-INF/jboss-classloading-domain.xml file is being referenced (as expected)...

     

    08:28:55,575 DEBUG [org.jboss.classloader.spi.ClassLoaderSystem] DefaultClassLoaderSystem@39452f registered domain=ClassLoaderDomain@182e645{name=FirstBest-UMS.war parentPolicy=(before=EXCLUDE [org.hibernate] after=<NOTHING>) parent=java.net.URLClassLoader@1112783}

     

     

    My WEB-INF/jboss-classloading-domain.xml…

     

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

    <classloading-domain xmlns="urn:jboss:classloading-domain:1.0" name="FirstBest-UMS.war">

    <parent-policy>

      <before-filter>

       <javabean xmlns="urn:jboss:javabean:2.0" class="org.jboss.classloader.plugins.filter.NegatingClassFilter">

        <constructor>

         <parameter>

          <javabean xmlns="urn:jboss:javabean:2.0" class="org.jboss.classloader.spi.filter.RecursivePackageClassFilter">

           <constructor>

            <parameter>org.hibernate</parameter>

           </constructor>

          </javabean>

         </parameter>

        </constructor>

       </javabean>

      </before-filter>

    </parent-policy>

    </classloading-domain>

     

    This issue is unfortunately blocking our migration from JBoss 4.2.3 to JBoss 6.0.0.Final.

  • 63. How to stop my WAR loading JBoss's provided 3rd party classes?
    Ales Justin Master
    This issue is unfortunately blocking our migration from JBoss 4.2.3 to JBoss 6.0.0.Final.

    As you can see from my github example / attempt, this is not as easy to do as we would all like to think.

    Either you take over complete control over how JPA is handled in your code,

    or better, try changing you app to be compatible with AS' Hibernate version.

     

    What's preventing you from using AS' bundled Hibernate?

    Hibernate's main interfaces shouldn't change at all? Or JPA1 vs. JPA2?

  • 64. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Tom Muldoon Newbie

    What's preventing you from using AS' bundled Hibernate?

     

    The simplest of answers is time.

     

    Hibernate 3.6 would require an update of Spring (based upon the AbstractMethodError in my earlier post) which would require an update of Acegi Security (to Spring Security) and so on. While those upgrades are inevitable (and time consuming), we had hoped that we would be able to upgrade JBoss AS without having to upgrade our application at this time (or the 3rd party libraries that it depends upon).

  • 65. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Ales Justin Master

    I guess downgrading AS' Hibernate is not an option?

    e.g. you exclude all AS services that might depend on the latest Hibernate,

    only leaving those who actually work on your Hibernate's version

  • 66. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Gary L Newbie

    I'm having a similar problem with Daniel, I am coming with a war that works in jboss5 and trying to deploy it to jboss6 and am receiving the error

     

    I beleive its because the war has packaged with it a 2.1 version of jaxb-xjc.jar:

     

    Caused by: java.lang.Error: Error visiting "/C:/***.war/WEB-INF/lib/jaxb-xjc.jar/1.0/com/sun/codemodel/JConditional.class"

     

    I am not limited by anything I can do on the server or the app.

     

    I have tried to replace the jaxb-xjc.jar (v2.1) in my app to the jBoss default of (2.2) - but when deploying gives me the same error

     

    I have tried to delete the .jar from both the war and the jboss/lib folder but it gives me the exact same error.

     

    Any guidance on how to quickly and easily fix this would be much appreciated

     

    Also is this issue related to this thread at all? The error messages I'm getting are very similar: http://community.jboss.org/thread/160881

  • 67. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    edward_nickson Newbie

    I have recently gone through the painful process of deploying an application on JBOSS 5.1.0.GA that was deploying fine on JBOSS 4.2.1.GA. It took me quite a while with much searching of the internet for help. I thought I should post what I did in case it helps others solve their own migration issues. This thread seemed like the best place to post it. Please note that not all of these problems will be encountered by all users and it is possible that some of the assumptions/statements that I found on the net and used were wrong. But overall the discussions I leveraged helped me immensely.

     

    The application contained the following major 3rd party software:

    -hibernate 3.6.0.Final + JTA 2.0

    -Camel 2.6.0

    -Spring 3.0.5.RELEASE

    -Atomikos 3.7.0

     

    The packaging was a WAR file.

     

    Here were the final steps required to deploy it:

     

    1) Set classloading:

    Added jboss-classloading.xml and edited jboss-web.xml to load the WAR in its own domain and its own META-INF/lib jars before Jboss'.

     

    AppBuild.war/WEB-INF/jboss-classloading.xml:

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

    <!-- See http://phytodata.wordpress.com/2010/10/21/demystifying-the-jboss5-jboss-classloading-xml-file -->

    <classloading xmlns="urn:jboss:classloading:1.0"

         parent-first="false"

         domain="AppBuild"

         top-level-classloader="true"

         export-all="NON_EMPTY"

         import-all="false">

    </classloading>

     

    AppBuild.war/WEB-INF/jboss-web.xml:

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

    <jboss-web>

        <context-root>/CONTEXT_ROOT_NAME</context-root>

      <class-loading java2ClassLoadingCompliance="false">

      <loader-repository>com.whatever:loader=AppBuild

      <loader-repository-config>java2ParentDelegation=false</loader-repository-config>

      </loader-repository>

      </class-loading>

    </jboss-web>

     

    Helpful URLS:

    http://phytodata.wordpress.com/2010/10/21/demystifying-the-jboss5-jboss-classloading-xml-file/

    https://community.jboss.org/wiki/JBoss5CustomMetadataFiles

     

    2) Prevent JBoss' older hibernate version attempting to deploy PUs:

    JBoss should be using the newer hibernate 3.6.0.Final to deploy, but it will attempt to load them anyway using the older version. I thus renamed all persistence.xml's in the application so that JBoss will not detect them and pointing Spring to the new names:

     

    Added: <property name="persistenceXmlLocation" value="classpath:META-INF/persistence-newname.xml"/>

    To the Entity Manager Factory Bean: org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean

     

    Exception:

    java.lang.ClassCastException: org.hibernate.ejb.HibernatePersistence cannot be cast to javax.persistence.spi.PersistenceProvider

     

    NOTES:

    JBoss is supposed to be able to filter out classes/packages from the domain. This is supposed to be done with : jboss-classloading-domain.xml. Unfortunately this classloading file causes unexpected changes that override the "parent-first=false" config specified in the classloading file. It should therefore not be used (as specified earlier in this thread)

     

    It should also be possible to have JBOSS ignore the persistence.xmls instead of having to rename them. Exqually unfortunate that: jboss-ignore.txt does not appear to work.

    SOURCE=https://community.jboss.org/message/607119#607119

     

    3) Remove any xml library conflicts:

    Several jars within the application caused a conflict (cannot cast exceptions) even though classloading is supposed to be isolated. All of these are regarding xml parsing. I had to removed the following jars from the WAR:

    -xerces

    -xml-apis

    -xmlParserAPIS

    -stax-api

     

    Exception Example:

    Caused by: java.lang.ClassCastException: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl cannot be cast to javax.xml.parsers.DocumentBuilderFactory

     

    4) Remove any servlet.http jars:

    A couple of jars contained implementations of the javax.servlet.http. These were overriden under JBoss 4.2.1.GA but were now being loaded first. The effect was that the Spring context did not start, and a servlet context exception was thrown. I had to remove the following jars:

    -geronimo-servlet_2.4_spec-1.1.1

    -servlet-api-2.5.jar

     

    Exception:

    java.lang.ClassCastException: com.xxx.xxx.xxx.Servlet cannot be cast to javax.servlet.Servlet

     

    5) Correct Camel type converter loading:

    A new file system was introduced in JBOSS 5 called VFS. This causes a problem with camel's type converters. The camel team are aware of this issue but there is no straightforward fix included in Camel. There is a recommended class available to fix the issue outside of Camel, but there is not even a readily available maven artifact for it (that I could find). The source code that I found was also tied directly to JBOSS 6. (JBOSS VFS classes were refactored between JBOSS 5 and 6.) I therefore modified the class myself for JBoss 5 and created the artifact. Lastly, I created a Spring bean to instantiate the class. This rectified the Camel exception. It is very unfortunate that the Camel team do not address this issue clearly on the Camel website with an easily to use maven artifact. They do indicate it is solved in newer versions of Camel but I have not had much success getting it to work without this bean for those versions thus far. 

     

    Exception:

    Caused by: org.apache.camel.RuntimeCamelException: org.apache.camel.TypeConverterLoaderException: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter, org.apache.activemq.camel.converter, org.apache.camel.component.http]

     

    Helpful URL:

    http://camel.465427.n5.nabble.com/Issue-with-loading-TypeConverter-in-Camel-2-8-2-on-JBOSS-7-2-td5155618.html

     

    6) Update Camel to accommodate type converter fix:

    The camel type converters were able to load, however a follow up error appeared:

    Caused by: java.lang.NoSuchFieldError: log

    at org.apachextras.camel.jboss.JBossPackageScanClassResolver.find(JBossPackageScanClassResolver.java:24)

     

    The camel team indicated that this error is due to a change in logging and usage of SLF4J. It requires camel 2.7.0+. I therefore upgraded to the latest 2.9.1.

     

    7) Disable hibernate validation or remove JBOSS' old validator.jar:

    JBoss' built in legacy hibernate validator was throwing the following exception in attempting validation:

    Caused by: java.lang.NoSuchMethodException: org.hibernate.validator.ClassValidator.<init>(java.lang.Class, java.util.ResourceBundle, org.hibernate.validator.MessageInterpolator, java.util.Map, org.hibernate.annotations.common.reflection.ReflectionManager)

     

    The sourcecode for JBoss does not permit this problem from being solved with classloading. It must either be solved by:

    a-removing JBOSS_ROOT/common/lib/hibernate-validator.jar

    OR

    b-disabling validation

    SOURCE URL: https://community.jboss.org/message/553449#553449#553449

     

    I chose to disable validation by adding the following to the jpaPropertyMap of the Entity Manager Factory Bean: org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean:

    <entry key="hibernate.validator.apply_to_ddl" value="false"/>

    <entry key="hibernate.validator.autoregister_listeners" value="false"/>

     

    8) DB Driver:

    I forgot to place the SQL Server JTDS driver in the /lib directory as it was under JBOSS 4.2.1.GA. This was causing an exception:

    Caused by: org.jboss.resource.JBossResourceException: Apparently wrong driver class specified for URL: class: net.sourceforge.jtds.jdbc.Driver, url: ...

     

    I therefore placed the jtds-1.2.4.jar in JBOSS_ROOT/server/default/deploy/lib

     

    9) The application now deploys.

     

    Message was edited by: edward_nickson Added a URL source for the camel type converter issue.

  • 68. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Ales Justin Master

    Nice, thanks for sharing such kind of info.

1 2 3 4 5 Previous Next