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]

_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to