[jboss-user] [JBoss Microcontainer] - Re: How to stop my WAR loading JBoss's provided 3rd party classes?

Tue Apr 17 00:23:26 EDT 2012

edward_nickson [https://community.jboss.org/people/edward_nickson] created the discussion

"Re: How to stop my WAR loading JBoss's provided 3rd party classes?"

To view the discussion, visit: https://community.jboss.org/message/730457#730457

--------------------------------------------------------------
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 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/ http://phytodata.wordpress.com/2010/10/21/demystifying-the-jboss5-jboss-classloading-xml-file/
 https://community.jboss.org/docs/DOC-13178 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#607119 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]

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#553449 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:
The driver file previously could be included inside the WAR file. Under new JBoss 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.
--------------------------------------------------------------

Reply to this message by going to Community
[https://community.jboss.org/message/730457#730457]

Start a new discussion in JBoss Microcontainer at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2114]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20120417/bf6bbbbf/attachment.html 