Class Loading: overriding xerces library in modules

[drakemj]

In JBoss AS 7, is it possible to override the version of libraries in the modules folder with earlier versions?  I am specifically interested in using an earlier version of ...\jboss-as-7.1.1\modules\org\apache\xerces\main\xercesImpl-2.9.1-jbossas-1.jar with v2.6.2.  Is this possible?  If so, how?

I tried adding the earlier version of xerces to MyEar.ear\lib and MyEar.ear\MyWar.war\WEB-INF\lib, but this didn't work.  My code still picks up v2.9.1 from modules. 

Ultimately, this will determine whether we can proceed with an upgrade from JBoss 4.0.1 to JBoss 7.  I'm trying to quickly find an answer so that I know whether we can proceed with this effort.

(Why do I want to use an older version of Xerces?: I have many customers with a lot of XSL.  I know that at least some of the XSL is imcompatible with v2.9.1.  The resulting issues may result in a huge headache for my customers.)

Thanks!

Melanie

[ctomc]

Hi,

define exclusion for global xerses module in jboss-deployment-structure.xml

for more info on how to do that take a look at https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7

--

tomaz

[drakemj]

Thanks for your response!

The documentation that you referenced states that automatic dependencies can be excluded using jboss-deployment-structure.xml.  I noticed that xerces is not considered an automatic dependency (https://docs.jboss.org/author/display/AS7/Implicit+module+dependencies+for+deployments).

Should I still be able to exclude xerces, even though it is not considered an "automatic dependency"?

I tried defining an exclusion in my ear's jboss-deployment-structure.xml file at both the deployment level and the sub-deployment level.  Despite these exclusions, the newer version of xerces (from the Modules structure) is being picked up by my code.  Here's just the deployment level exclusion:

<deployment>
    <exclusions>
        <module name="org.apache.xerces" />
    </exclusions>
</deployment>

I also tried adding a new module (jboss-as-7.1.1\modules\deployment\myxerces) with the appropriate module.xml file and older xerces jar.  In jboss-deployment-structure.xml, I added a dependency to the new module. 

<sub-deployment name="MyWar.war">
    <exclusions>
        <module name="org.apache.xerces" />
    </exclusions>
    <dependencies>
      <module name="deployment.myxerces" />
    </dependencies>
</sub-deployment>

<module name="deployment.myxerces" >
    <resources>
        <resource-root path="xercesImpl-4.0.1sp1.jar" >
        </resource-root>
    </resources>
</module>

So far, these attempts have failed.  My code still picks up the newer version of the xerces library from modules.

Please let me know what I am doing incorrectly. 

[drakemj]

UPDATE: I noticed that if I create a very small ear (see attached Test.ear) that contains just the old xerces library and a war (VersionCheck.war), the old xerces library is picked up by the code.  The old xerces library is in Test.ear\lib.  Test.ear's jboss-deployment-structure.xml excludes the org.apache.xerces module at the deployment level. 

If you recall, the same exclusion did not work for our larger (real life, production) ear.

This leads me to believe that our larger ear (which contains many third party libraries) must contain one or more library that has a dependency on the org.apache.xerces module; this may in turn prevent the 'override' of the xerces module with the older library in Test.ear\lib.  Is this a correct assumption?  I thought that with JBoss 7 class loading, this would not be an issue.

Can you think of any other reason that my larger ear might be unable to exclude the org.apache.xerces module?

Any response is helpful, as we are trying to quickly determine whether our upgrade project can proceed.  Thanks again!

[ctomc]

Hi,

can you post the output

jar tf <name-of-your-ear>

or maybe try to also exclude xerses also for subdeployment (your war)

as transitive dependancies don't apply for jboss-modules so no other module would not bring that in (i think)

--

tomaz

[drakemj]

Ultimately, we found two issues preventing the override of the xerces module (v2.9.1) in the larger ear.

1. One of the components in the ear declared a dependency on org.apache.xerces.  This was declared in MANIFEST.MF.  Removing this dependency allowed our code to utilize xerces v2.8.1 (closer, but still not the desired v2.6.2)
2. Our application utilizes Apache Jackrabbit 1.6.1, which has an indirect dependency on xerces v2.8.1.  (Prior to Jackrabbit 2.0, Jackrabbit uses the Jackrabbit text extractors which use xerces: http://grepcode.com/static/data/html/repo1.maven.org$maven2/org.apache.jackrabbit$jackrabbit-text-extractors/1.6.2/visualization.svg  The Apache Tika parser replaces the Jackrabbit text extractors in 2.0+, so xerces is no longer used by Jackrabbit 2.0+.  Previous to v2.0, the xerces library is included in the jackrabbit rar.)  We presume that upgrading to Jackrabbit 2.0+ will eliminate this dependency on xerces, allowing our code to access the desired version of xerces (v2.6.2)

Question: Should I still be able to exclude xerces, even though it is not considered an "automatic dependency"?

Answer: Yes.  Modules can be excluded using jboss-deployment-structure.xml at the <deployment> or <sub-deployment> level.  In our case, excluding it at the <deployment> level was sufficient (when the other xerces dependencies were removed from the equation).

Adding a dependency as a module (e.g., jboss-as-7.1.1\modules\deployment\myxerces) should work, but it should be sufficient (and more straightforward) to just include it in the ear’s lib folder.

Hint: If you are facing a similar problem, search all of the MANIFEST.MF files below …\deployments\ to see if there are any dependencies on the module in question.  At the module level (…\modules\), search the module.xml files to see if there are indirect dependencies declared on the module.  My current understanding is that if there are any dependencies on the module in question, exclusions declared in jboss-deployment-structure.xml will be ignored.