JBoss 4.0.1 Linkage Error Nightmare
rhook Jan 10, 2005 8:05 PMWe have a very real need to support the following situation:
- a server will have a JBoss 4.x installation, possibly with certain 3rd party libraries such as iBatis in the {server}/lib directory;
- we will deploy multiple different EAR files for our various internal applications;
- some of those EAR files will contain different versions of the same classes, as the applications will be at different versions;
- we must have each EAR file isolated from all others in terms of loading the classes that are within the EAR file, but "common" 3rd party libraries will be sourced from the {server}/lib directory;
I have spent many (many (many (many))) hours fighting with class loader problems trying to support this situation, with many (many (many (many))) hours spent reading through these forums, the support wiki, google-sphere at large, and the (free) jboss documentation.
As far as I can determine, the blessed and correct way to provide the required "isolation with overloading" I describe is as specified in http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration
Question 1: is that the correct method?
Question 1a: if not, what is the correct method?
With regard to the following I have been testing by shutting down Jboss, removing the deploy ear, completely hosing out {server}/tmp/deploy each time, starting up Jboss, then deploying the EAR.
I have found the following situations, for different jboss-app.xml in the EAR file. Note that the exact class that is complained about varies in our case between javax.sql.Datasource and javax.xml.transformSource, depending which of two particular test EAR I used.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE jboss-app PUBLIC "-//JBoss//DTD J2EE Application 1.4//EN" "http://www.jboss.org/j2ee/dtd/jboss-app_4_0.dtd"> <jboss-app> <loader-repository> au.com.hpa.AuthServer:loader=AuthServerApp.ear <loader-repository-config> java2ParentDelegation=false </loader-repository-config> </loader-repository> </jboss-app>
results in "java.lang.LinkageError: loader constraints violated when linking javax/xml/transformSource class"
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE jboss-app PUBLIC "-//JBoss//DTD J2EE Application 1.4//EN" "http://www.jboss.org/j2ee/dtd/jboss-app_4_0.dtd"> <jboss-app> <loader-repository loaderRepositoryClass="org.jboss.mx.loading.HeirarchicalLoaderRepository3"> au.com.hpa.AuthServer:loader=AuthServerApp.ear <loader-repository-config configParserClass="org.jboss.mx.loading.HeirarchicalLoaderRepository3ConfigParser"> java2ParentDelegation=false </loader-repository-config> </loader-repository> </jboss-app>
results in "java.lang.LinkageError: loader constraints violated when linking javax/xml/transformSource class"
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE jboss-app PUBLIC "-//JBoss//DTD J2EE Application 1.4//EN" "http://www.jboss.org/j2ee/dtd/jboss-app_4_0.dtd"> <jboss-app> <loader-repository> au.com.hpa.AuthServer:loader=AuthServerApp.ear <loader-repository-config> java2ParentDelegation=true </loader-repository-config> </loader-repository> </jboss-app>
results in "java.lang.NoClassDefFoundError: org/apache/digester/ObjectCreationFactory"
Question 2: for our desired approach, should java2ParentDelegation be true or false;
and there is probably a meta-question here:
Question N: where, if anywhere, is the correct and unambiguous documentation?
I will now turn on "bitter complaint" mode: a lot of people seem to have had very similar problems in the past, but almost universally if they have found a resolution, it has not been posted. The documentation is sorely lacking here as well: most of it appears to be hugely out of date, and the 4.x documentation is incomplete. And before anyone points me at the PDF document that describes the linkage error, yes, it contains an indepth discussion of the class loader model, an in-depth explanation of what a linkage error is, a fair amount of test code to show what is going on when a linkage error occurs, and contains no concrete explanation of how to overcome the problem. The closest thing to a work-around that I've seen posted in any number of instances has been to include all requisite JAR in the EAR or the WAR inside the ear, however this is not suitable in this case because:
- it prevents sharing of common 3rd party libraries;
- the "requisite" JAR in this case would be things like rt.jar from the JDK!
This issue has become a major show-stopper for us, and is a source of immense frustration. We have explicitly made the decision to move from another application server to JBoss because it claims to be J2EE compliant, and this was precisely the problem we were unable to resolve in the other application server without running multiple instances of the server.
All sensible (concrete, tested, verified) suggestions and responses eagerly and urgently sought.