Red Hat Bugzilla – Bug 998559
WS Backward Compatibility failures with EAP 6.1.1
Last modified: 2013-09-11 05:48:13 EDT
################## org.jboss.test.ws.jaxws.cxf.clientConfig.CXFClientConfigurationTestCase REPRODUCIBLE FIXABLE == get removeTestCaseClientConfiguration in TestUtils in sync with https://source.jboss.org/changelog/JBossWS?cs=17733 ################## org.jboss.test.ws.jaxws.clientConfig.ClientConfigurationTestCase REPRODUCIBLE, shared TS FIXABLE == get removeTestCaseClientConfiguration in TestUtils in sync with https://source.jboss.org/changelog/JBossWS?cs=17733 CXFClientConfigurationTestCase and ClientConfigurationTestCase failures have the same reason, upstream work was tracked under https://issues.jboss.org/browse/JBWS-3647 but there is no description. What changed in EAP so that old and wrong implementation of removeTestCaseClientConfiguration is not working with EAP 6.1.1 ? ################## org.jboss.test.ws.jaxws.samples.wsse.policy.trust.WSTrustPicketLinkTestCase RANDOM FAILURES Caused by: org.apache.cxf.ws.policy.PolicyException: Cannot encrypt data But it's not failing when running just this test case. Possible issue with test order and test interference. https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-WS/job/eap-6x-jbossws-backward-compatibility/18/testReport/org.jboss.test.ws.jaxws.samples.wsse.policy.trust/WSTrustPicketLinkTestCase/test/ https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-WS/job/eap-6x-jbossws-backward-compatibility/17/testReport/org.jboss.test.ws.jaxws.samples.wsse.policy.trust/WSTrustPicketLinkTestCase/test/
https://source.jboss.org/changelog/JBossWS?cs=17731 for #2
Regarding #1 and #2 (the TestUtils things), what changed is that for fixing thread safety issues, the server/client config lists are now CopyOnWriteArrayList which do not support Iterator::remove(). Regarding the WSTrustPicketLinkTestCase, I can see other tests failed for the same reason in the same run. Is it possible there's something not properly configured in the environment?
#3 - WSTrustPicketLinkTestCase Other failures are caused by missing BC and unlimited crypto in Jenkins default java installation. I was checking these failures locally with BC and unlimited crypto installed. So for WSTrustPicketLinkTestCase I linked Jenkins jobs incorrectly. I will rerun tests locally with BC and provide info for this test case. As I wrote earlier - failures are random and it's not failing when running just this test case.
I cloned backward-compatibility job and configured it to use JDK with BC - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-WS/job/eap-6x-jbossws-backward-compatibility-bc/ and I don't see WSTrustPicketLinkTestCase failures ... But, I was "lucky" with local run: Full details in http://pastebin.test.redhat.com/159319 for client side ++ http://pastebin.test.redhat.com/159320 for server side The main issue is: org.apache.cxf.binding.soap.SoapFault: loader constraint violation: loader (instance of org/jboss/modules/ModuleClassLoader) previously initiated loading for a different type with name "javax/xml/crypto/dsig/XMLSignContext" 08:36:50,677 WARN [org.jboss.modules] (http-/127.0.0.1:8080-25) Failed to define class javax.xml.crypto.dsig.XMLSignContext in Module "org.apache.santuario.xmlsec:main" from local module loader @edb4fa2 (finder: local module finder @60491c4c (roots: /home/rsvoboda/TESTING/611ER6/jboss-eap-6.1/modules,/home/rsvoboda/TESTING/611ER6/jboss-eap-6.1/modules/system/layers/base)): java.lang.LinkageError: loader constraint violation: loader (instance of org/jboss/modules/ModuleClassLoader) previously initiated loading for a different type with name "javax/xml/crypto/dsig/XMLSignContext"
Ah, interesting... I think I might have an idea of the reason for that exception. Will investigate and might need to assign this issue to someone else (if it's what I think, the fix would be in jboss-modules).
Btw, if you could save the full (since boot) server log from a run in which the WSTrust issue is reproduced, that would be usefull. Thanks!
Created attachment 788403 [details] server.log Adding server.log Fresh EAP 6.1.1 ER6 bits + jbossws-cxf-4.1.3.Final TS (for EAP 6.1.0 GA) mvn -s /home/rsvoboda/TESTING/backward/stack-cxf/modules/testsuite/settings-ws-backward-compatibility.xml -Ptestsuite,hudson,jboss720 -Dmaven.repo.local=/home/rsvoboda/TESTING/backward/stack-cxf/modules/testsuite/local-repo -Djboss720.home=/home/rsvoboda/TESTING/611ER6/jboss-eap-6.1 -Dnoprepare integration-test -Dtest=org.jboss.test.ws.jaxws.samples.wsse.policy.trust.WSTrustPicketLinkTestCase But usually after full TS execution + no stop of EAP I don't see loader constraint violation exception
[rsvoboda@steve testsuite]$ java -version java version "1.6.0_38" Java(TM) SE Runtime Environment (build 1.6.0_38-b05) Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode) ++ BC ++ Unlimited Crypto Will try latest JDK too.
I tried 1.6.0_45 with BC and Unlimited Crypto still able to reproduce. Probably related to proper initialization, adding snapshot of IRC chat. <asoldano> rsvoboda, regarding BZ 998559 you can save time and avoid testing with other JDK versions... I think the reason for the failures is in something initializing the javax.xml.crypto.dsig from wrong location before the ws subsystem uses it <rsvoboda> asoldano, ok <asoldano> rsvoboda, that was a problem I saw once or twice many months ago <asoldano> rsvoboda, discussed a bit in theory with Jason <asoldano> rsvoboda, but we never really addressed it imho <rsvoboda> asoldano, weird thing is that after full ts execution and then just WSTrustPicketLinkTestCase execution it pass -- with no EAP restart <asoldano> rsvoboda, if it's what I think, basically the first time the dsig classes are loaded is what matters. If they're loaded "properly", no issue will be seen <asoldano> rsvoboda, but really, I should refresh my memories here before commenting ;-)
The WSTrustPicketLinkTestCase issue is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=960998 . The corresponding WFLY jira is https://issues.jboss.org/browse/WFLY-1969
*** This bug has been marked as a duplicate of bug 960998 ***