re-test, please

Still remains in ER6:

mvn exec:java -Dexec.args="confidentiality signencrypt" -Djavax.net.ssl.trustStore=connector.jks

Caused by: java.lang.ClassCastException: org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory cannot be cast to javax.xml.crypto.dsig.XMLSignatureFactory

This problem seems to be an EAP issue as there are two versions of javax.xml.crypto.dsig.XMLSignatureFactory being loaded into the VM, one from xmlsec.jar and a second from the JDK.

[Loaded javax.xml.crypto.dsig.XMLSignatureFactory from jar:file:/Users/kevin/FSW-ER6/jboss-eap-6.1/modules/system/layers/base/org/apache/santuario/xmlsec/main/xmlsec-1.5.3-redhat-1.jar!/]
[Loaded javax.xml.crypto.dsig.XMLSignatureFactory from /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar]
Caused by: java.lang.ClassCastException: org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory cannot be cast to javax.xml.crypto.dsig.XMLSignatureFactory
        at javax.xml.crypto.dsig.XMLSignatureFactory.getInstance(XMLSignatureFactory.java:269) [classes.jar:1.6.0_65]

Investigating further.

The workaround is to edit modules/system/layers/base/javax/api/main/module.xml and *comment out* the following lines

<!--
                <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"/>
-->

Once this is done there will be no attempt to load these packages from the JDK.

An alternative could be to provide a modified version of ./modules/system/layers/base/org/apache/santuario/xmlsec/main/xmlsec-1.5.3-redhat-1.jar that removed the javax.xml.crypto packages.

Removed the link to https://issues.jboss.org/browse/AS7-4248 as it is copying the BZ comments into the JIRA issue.

An even better workaround, rather than removing access to the JDK classes, is to modify the modules/system/layers/base/org/apache/santuario/xmlsec/main/module.xml to exclude the javax classes, it is not necessary to repackage this jar.

The contents would therefore be

<module xmlns="urn:jboss:module:1.1" name="org.apache.santuario.xmlsec">
    <exports>
        <exclude path="javax/**"/>
    </exports>

    <properties>
        <property name="jboss.api" value="private"/>
    </properties>

    <resources>
        <resource-root path="xmlsec-1.5.3-redhat-1.jar"/>
        <!-- Insert resources here -->
    </resources>

    <dependencies>
      <module name="javax.api" />
      <module name="org.apache.commons.logging" />
      <module name="org.apache.xalan" />
    </dependencies>
</module>

This bug is being triggered through dependencies that have been specified in the picketlink module.xml.

The following are the list of modules that include a dependency on xmlsec:

modules/system/layers/base/org/apache/cxf/impl/main/module.xml
modules/system/layers/base/org/apache/ws/security/main/module.xml
modules/system/layers/base/org/jboss/as/webservices/server/integration/main/module.xml
modules/system/layers/base/org/opensaml/main/module.xml
modules/system/layers/base/org/picketlink/main/module.xml

All of the modules, with the exception of picketink, specify a dependency on javax.api *before* the dependency on xmlsec, thereby pulling in the JDK classes, whereas the picketlink module specifies the dependencies in the opposite order and, therefore, pulls in the version from the xmlsec jar.

The approach taken so far seems to have been to address the symptoms of the issue, i.e. fixing the issue in the consumers, rather than tackling the source of the problem which would appear to be the xmlsec module.  For this reason I would advise the use of the exports/exclude mentioned in the previous comment.

This issue is still present in EAP 6.1.1

Still in FSW ER7-2 as expected.

*** Bug 1054745 has been marked as a duplicate of this bug. ***

Please see https://bugzilla.redhat.com/show_bug.cgi?id=960998 , this should be the same issue that has been fixed there for EAP 6.2

Resetting the flags back to the state it was before Oct-24- 2PM. There was an incorrect bulk update that I'm trying to fix.

Tested this against EAP 6.4 and it no longer seems to be an issue.    The xmlsec module.xml in EAP 6.4 excludes the javax classes like Kevin suggested above.

Tested this against EAP 6.4 and it no longer seems to be an issue.    The xmlsec module.xml in EAP 6.4 excludes the javax classes like Kevin suggested above.