Bug 998559 - WS Backward Compatibility failures with EAP 6.1.1
Summary: WS Backward Compatibility failures with EAP 6.1.1
Keywords:
Status: CLOSED DUPLICATE of bug 960998
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web Services
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Alessio Soldano
QA Contact: Rostislav Svoboda
Russell Dickenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-19 14:15 UTC by Rostislav Svoboda
Modified: 2013-09-11 09:48 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-09-11 09:48:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
server.log (88.30 KB, text/x-log)
2013-08-20 10:07 UTC, Rostislav Svoboda
no flags Details

Description Rostislav Svoboda 2013-08-19 14:15:34 UTC
##################
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 14:17:48 UTC
https://source.jboss.org/changelog/JBossWS?cs=17731 for #2

Comment 2 Alessio Soldano 2013-08-19 14:32:35 UTC
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 05:44:30 UTC
#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 06:44:02 UTC
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 07:14:41 UTC
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 07:19:58 UTC
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 10:07:34 UTC
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 10:29:52 UTC
[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 15:35:42 UTC
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 14:51:32 UTC
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 09:48:13 UTC

*** 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.