exclude XMLSEC and XALAN

[andrew.sc.syd]

AS 7.1.1.

I'm experiencing a version incompatibility between the XMLSEC (Santuario) and XALAN libraries used by Jboss. The error comes at the point where XMLSEC attempts to instatiate an XpathContext object. The XpathContext, in urn, has a private DTMManager which is being created by newInstance(). The newInstance returns an instance of org.apache.xml.dtm.ref.DTMManagerDefault which canot be cast to org.apache.xml.dtm.DTMManager. The XMLSecurityRuntimeException forgets to mention the original cause of ClassCastException.

So, I'd rather use my own versions of XMLSEC and XALAN. I saw how JBoss uses it's own version of XMLSEC. It even replaces the version incorporated into the JDK. Here is the snippet from definition of javaee.api

	<module name="org.apache.santuario.xmlsec" export="true">
	<exports>
	<include-set>
	<path name="javax/xml/crypto"/>
	<path name="javax/xml/crypto/dom"/>
	<path name="javax/xml/crypto/dsig"/>
	<path name="javax/xml/crypto/dsig/dom"/>
	<path name="javax/xml/crypto/dsig/keyinfo"/>
	<path name="javax/xml/crypto/dsig/spec"/>
	</include-set>
	</exports>
	</module>

I read the advice given at https://community.jboss.org/message/637818

So, I tried my hand. In jboss-deployment-structure.xml I excluded the XmlSec used by Jboss

<jboss-deployment-structure>

    <deployment>

        <exclusions>               

            <module name="org.apache.xalan" />           

            <module name="org.apache.santuario.xmlsec"/>

        </exclusions>

        <dependencies>

            <module name="javaee.api" >

                <imports>

                    <exclude-set>

                             <path name="org.apache.santuario.xmlsec"/>

                    </exclude-set>

                </imports>

            </module>                       

        </dependencies>

    </deployment>

</jboss-deployment-structure>

For some reason, it did not work. I can still see in the stack trace xmlsec.1.5.1 which is the JBoss version

Regards,

Andrew

[nickarls]

Is this a WAR (or can the dependency be pulled in from some other deployment part)? Where did you place the xml file (i.e. is it picked up, if you put a typo in it, will deployment fail)?

[andrew.sc.syd]

Nicklas,

thanks for your answer.  It's a single WAR deployment,  The "jboss-deployment-structure.xml" is placed inside the WAR, in the WEB-INF directory.  And I can definitely confirm that if I put incorrect syntax into this XML file, then the deployment fails -:)

The issue is not urgent, because I solved it by completely avoiding XPATH on my app. More exaclty, I only had to avoid the call chain where XMLSEC calls XPATH.  In my case, this was possible, because I could apply an enveloped signature by manipulating the DOM, without Xpath. But of course, in other cases, this won't be so simple. At any rate, we need to learn about JBoss 7, and it's not a pleasant feeling to be restricted in our use of standard JDK libraries.

Earlier, I also had a solution with Xpath. This required me to use an altered version of the Xalan library. Jobss itself has an altered version of Xalan 2.7.1 so I took that as a stating point, and I handcrafted another version, which differed by a single statement in a single class. It worked with my app, but started to cause errors for another application of ours. Perhaps I went too far in adjusting the definitions in the "modules" area, so the other application got affected.

This raises a more general question. Having customisable modulesseems like a good idea. But I would like to be able to isolate one application from the other (similar to the way that Jboss isolates itself through it's own use of modules). Is is possible to specify a module hierachy on a per-applicaiton basis ?  The "jboss-deployment-structure.xml" seems to point into this direction, but its expressive power is much less than the flexibility afforded by a "modules" hierarchy. It is as if JBoss gives more flexibility to itself, than it gives to individual applications.

We are a multi-platform vendor, so we naturally aim at applications which run on most major applicaiton servers. There is an ongoing dsiscussion within our team about the extent to which the "modules" hierachy can be customised. By some opinion, "modules" are an invariable part of the JBoss deployment. Asking our clients to modify the "modules" may affect other unrelated applications they might be running.

Regards,

Andrew

[aldo.dv]

We had a similar issue, related to xmlsec and also tried the options described in https://community.jboss.org/message/637818.

Did not work at first.

The class that was causing the issue is loaded using "Thread.currentThread().getContextClassLoader()". It turns out that during startup of the JBoss server, the "Thread.currentThread().getContextClassLoader()" does not contain the application classloader but rather a classloader from another JBoss module. So the "jboss-deployment-structure.xml" did not help here, as it only influences the application classloader (AFAIK).

At redeploy it does work as expected, the "Thread.currentThread().getContextClassLoader()" contains the application classloader. So redeploying our application after startup also solved the issue.

To fix it, I replaced the contextClassLoader in a bootstrap class:

ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();

try {

     Thread.currentThread().setContextClassLoader(XXXBootstrap.class.getClassLoader());

     initializeXMLSecurity();

     initializeXMLTooling(_xmlToolingConfigs);

     ...

} finally {

     Thread.currentThread().setContextClassLoader(contextClassLoader);

}