5 Replies Latest reply on Feb 29, 2016 4:53 PM by Kelly Dolan

    Class loading problems with library version different from Wildfly version - help!

    Kelly Dolan Newbie

      I suspect we should be able to do what we want to do but obviously we are missing something. Any and all help to uncover what that may be or point us in a direction to look is greatly appreciated.


      • We want to use Xalan 2.7.2, not the version provided by Wildfly.
      • We put Xalan in our EAR and modified jboss-deployment-structure.xml to exclude the org.apache.xalan and org.apache.xerces modules (even though we shouldn't need to given documented class loading rules)
      • We wrote some code to confirm certain Xalan classes are loaded from our copy of Xalan - all is well, until....
      • We hit code that involves XPath classes (e.g., XPathImpl, XPathFactory) resulting in exceptions. Using the same confirmation technique, we confirmed these classes are loaded from the Wildfly Xalan module and must not be compatible with those loaded from other JARs.
      • If we modify the Wildfly Xalan JAR by removing "javax.xml.xpath.XPathFactory" from META-INF\services, our problems go away. Our code confirms the XPath classes are now loaded from the JRE. Not sure why the JRE. We would expect them to come from Xalan in our EAR.


      What we don't want to do because we suspect it is the wrong thing to do is

      • Modify the Wildfly Xalan JAR as described above.
      • Replace the Wildfly Xalan JAR w/ Apache's version of 2.7.2.


      Any ideas? What are we missing? Are our assumptions correct? We're pretty much at a standstill.


      Many thanks in advance,