This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 998559 - WS Backward Compatibility failures with EAP 6.1.1
WS Backward Compatibility failures with EAP 6.1.1
Status: CLOSED DUPLICATE of bug 960998
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web Services (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Alessio Soldano
Rostislav Svoboda
Russell Dickenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-19 10:15 EDT by Rostislav Svoboda
Modified: 2013-09-11 05:48 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-11 05:48:13 EDT
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)
server.log (88.30 KB, text/x-log)
2013-08-20 06:07 EDT, Rostislav Svoboda
no flags Details

  None (edit)
Description Rostislav Svoboda 2013-08-19 10:15:34 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/
Comment 1 Rostislav Svoboda 2013-08-19 10:17:48 EDT
https://source.jboss.org/changelog/JBossWS?cs=17731 for #2
Comment 2 Alessio Soldano 2013-08-19 10:32:35 EDT
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?
Comment 3 Rostislav Svoboda 2013-08-20 01:44:30 EDT
#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.
Comment 4 Rostislav Svoboda 2013-08-20 02:44:02 EDT
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"
Comment 5 Alessio Soldano 2013-08-20 03:14:41 EDT
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).
Comment 6 Alessio Soldano 2013-08-20 03:19:58 EDT
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!
Comment 7 Rostislav Svoboda 2013-08-20 06:07:34 EDT
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
Comment 8 Rostislav Svoboda 2013-08-20 06:29:52 EDT
[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.
Comment 9 Rostislav Svoboda 2013-08-21 11:35:42 EDT
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 ;-)
Comment 10 Alessio Soldano 2013-08-29 10:51:32 EDT
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
Comment 11 Alessio Soldano 2013-09-11 05:48:13 EDT

*** This bug has been marked as a duplicate of bug 960998 ***

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