Bug 979334 - policy-security-wss-signencrypt demo - ClassCastException
policy-security-wss-signencrypt demo - ClassCastException
Status: MODIFIED
Product: JBoss Fuse Service Works 6
Classification: JBoss
Component: Examples (Show other bugs)
6.0.0
Unspecified Unspecified
unspecified Severity high
: ER6
: ---
Assigned To: tcunning
Jiri Pechanec
: Reopened
: 1054745 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-28 05:07 EDT by Pavel Drozd
Modified: 2018-03-29 17:51 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
If you try to execute the policy-security-wss-signencrypt quickstart, you will encounter ClassCastException. This is due to a bug in Red Hat JBoss Enterprise Application Platform's PicketLink module. This modules causes a conflict between classes provided by the Java Development Kit and others provided through the xmlsec module. To workaround this issue, edit the PicketLink modules/system/layers/base/org/picketlink/main/module.xml file and switch the sequence of xmlsec and javax.api dependencies so that the javax.api comes first. <programlisting><![CDATA[ <module name="javax.api"/> <module name="org.apache.santuario.xmlsec"/> ]]></programlisting>
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ClassCastException (9.79 KB, text/plain)
2013-06-28 05:07 EDT, Pavel Drozd
no flags Details

  None (edit)
Description Pavel Drozd 2013-06-28 05:07:35 EDT
Created attachment 766479 [details]
ClassCastException

Description of problem:

ClassCastException occurs during sending secure request.

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

Steps to Reproduce:

mvn clean install
mvn jboss-as:deploy
mvn exec:java -Dexec.args="confidentiality signencrypt"

Full exception attached.
Comment 1 Anne-Louise Tangring 2013-11-11 13:05:53 EST
re-test, please
Comment 2 Pavel Drozd 2013-11-12 07:29:57 EST
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
Comment 3 kconner 2013-11-12 16:41:06 EST
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.
Comment 4 kconner 2013-11-12 17:23:30 EST
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.
Comment 5 kconner 2013-11-12 17:27:28 EST
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.
Comment 6 kconner 2013-11-12 17:30:19 EST
Removed the link to https://issues.jboss.org/browse/AS7-4248 as it is copying the BZ comments into the JIRA issue.
Comment 7 kconner 2013-11-13 18:36:41 EST
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>
Comment 8 kconner 2013-11-13 18:44:11 EST
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.
Comment 9 kconner 2013-11-13 18:45:20 EST
This issue is still present in EAP 6.1.1
Comment 10 Martin Vecera 2013-12-21 03:58:02 EST
Still in FSW ER7-2 as expected.
Comment 11 Jiri Pechanec 2014-01-17 07:43:39 EST
*** Bug 1054745 has been marked as a duplicate of this bug. ***
Comment 12 Alessio Soldano 2014-02-20 04:13:44 EST
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
Comment 13 Gomathi Anandan 2014-10-24 14:49:49 EDT
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.
Comment 14 tcunning 2015-02-16 14:11:05 EST
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.
Comment 15 tcunning 2015-02-16 14:11:05 EST
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.

Note You need to log in before you can comment on or make changes to this bug.