I keep getting these "Could not find file .../target/artifacts/addressing-1.6.3-SNAPSHOT.mar to copy" type errors on the 1.6.x branch. How do I work around this?
Colm. On Tue, Jul 8, 2014 at 4:21 PM, <[email protected]> wrote: > Hi Colm, > What I did so far is to checkout Rampart (I have tried both trunk and > 1.6 branches), increase the wss4j dependency to 1.6.5 and run "mvn clean > package -Dtest=RampartTest". This fails on the "Testing WS-Sec: custom > scenario 7" with the error I described. Switching the dependency back to > 1.6.4 fixes this issue, but still there is one additional scenario (28) > which is failing, however I presume it is not related with wss4j but > probably with Axiom. > > I have checked out wss4j 1.6.x branch and build it locally, then switched > Rampart to this version and re-executed the tests. The tests succeeded up > until the point I switched to wss4j revision 1294114. With previous 1294094 > revision, this scenario is working fine. > > I was thinking it might be related with changes of other dependencies, but > I doubt this is the case, since this revision does not introduce dependency > changes. > > I will continue with the investigation and let you know once I have more > information. > > Thanks, > Detelin > > > On Tue, Jul 8, 2014 at 4:51 PM, Colm O hEigeartaigh <[email protected]> > wrote: > >> >> Are you sure that the commit you referenced above is causing the problem? >> Rampart trunk fails on that test for me with WSS4J 1.6.4. Rampart 1.6.x >> branch fails on something else... >> >> If you have time to look into it, you could try checking out that >> SNAPSHOT version of WSS4J (Before the commit) + check that it works + then >> apply each change and see what change causes the failure. Ultimately, it >> looks like Rampart might be at fault, as the response message is not >> composed properly >> >> Colm. >> >> >> On Tue, Jul 8, 2014 at 12:55 PM, <[email protected]> wrote: >> >>> Hi everyone, >>> Our team worked on new functionality that is to be released with >>> upcoming wss4j 1.6.16 (WSS-500 >>> <https://issues.apache.org/jira/browse/WSS-500> & WSS-501 >>> <https://issues.apache.org/jira/browse/WSS-501>). We have managed to >>> integrate this functionality within Apache Rampart 1.6.2 and are willing to >>> contribute the necessary pieces there as well. However, so far we have been >>> using wss4j 1.6.4 + the corresponding patches and they seem to work fine >>> with Rampart 1.6.2. >>> Once I saw the vote for releasing wss4j 1.6.16, I decided to try to >>> build Rampart 1.6.2 against it, just to make sure it can adopt this new >>> version in near future. >>> However, I stumbled upon a test failure in Rampart integration module, >>> which I managed to track down to a specific commit in wss4j. The commit is >>> quite old, it is released in wss4j 1.6.5 (latest Rampart uses 1.6.4). The >>> change that causes trouble is the following: >>> >>> http://svn.apache.org/viewvc?view=revision&revision=1294114 >>> >>> Log message says "Only decrypt a Data Reference in the >>> ReferenceListProcessor, if it hasn't already been decrypted by the >>> EncryptedDataProcessor". >>> >>> The specific Rampart test that fails is >>> "org.apache.rampart.RampartTest#testWithPolicy()" using the following >>> security policy: >>> >>> >>> http://svn.apache.org/repos/asf/axis/axis2/java/rampart/trunk/modules/rampart-integration/src/test/resources/rampart/policy/7.xml >>> >>> I'm attaching the SOAP request and response (request.xml and >>> response.xml), the actual error message is on the client side, when >>> processing the response from the service: >>> java.lang.StringIndexOutOfBoundsException: String index out of range: 0 >>> at java.lang.String.charAt(String.java:658) >>> at org.apache.ws.security.WSDocInfo.getResult(WSDocInfo.java:225) >>> at >>> org.apache.ws.security.str.DerivedKeyTokenSTRParser.parseSecurityTokenReference(DerivedKeyTokenSTRParser.java:90) >>> at >>> org.apache.ws.security.processor.DerivedKeyTokenProcessor.handleToken(DerivedKeyTokenProcessor.java:53) >>> at >>> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:398) >>> at >>> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:304) >>> at >>> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:249) >>> at org.apache.rampart.RampartEngine.process(RampartEngine.java:147) >>> >>> The stack trace is generated using wss4j revision 1294114. >>> >>> It can be seen that the response contains invalid references (URI not >>> correctly set): >>> >>> <wsse:SecurityTokenReference ... >>> wsu:Id="STR-AA4ACE8415228CCC8E140481886870110"> >>> <wsse:Reference URI="#" ValueType=" >>> http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#EncryptedKey"; >>> /> >>> </wsse:SecurityTokenReference> >>> >>> I'm now trying to figure out what is the root cause of this and whether >>> the problem is on the wss4j side or on Rampart's side, but I would be glad >>> if anyone more experienced takes a look into this and provides some >>> feedback. >>> >>> Thanks! >>> >>> Detelin >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> >> -- >> Colm O hEigeartaigh >> >> Talend Community Coder >> http://coders.talend.com >> > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
