We have two needs :
- Our CXF bus contains both SOAP services and REST service. I want to
activate WS-Addressing only on SOAP Services (of course :) )
- On the other hand, the asynchronous feature of WS-Addressing will not be
activated all the time. We have a context (accessible from a
your exception stracktrace seems to indicate that the problem is
happening when the response message is being processed.
Can you check how the request message from the cxf-client and the
response message to the cxt-client look (e.g., using the logging
feature of cxf or capturing the wire
Is this for the CXF request or processing the response? What does the
message look like?
Colm.
On Mon, Nov 24, 2014 at 9:52 AM, tobee lukasz.tob...@gmail.com wrote:
result of run on 1.7 without BC and with JCE installed
Exception in thread main javax.xml.ws.soap.SOAPFaultException: These
You need to tell Santuario how to resolve the SecurityTokenReference
Element. You can do this by a utility method in WSSecurityUtil, e.g.:
WSSecurityUtil.storeElementInContext(domCryptoContext, strElement);
See here for an example:
The request was sent in 1.7 - response:
http://pastebin.com/uttdvtCL
--
View this message in context:
http://cxf.547215.n5.nabble.com/possible-wss4j-bug-tp5750539p5751390.html
Sent from the cxf-user mailing list archive at Nabble.com.
Thanx, Colm. But the storeElementInContext() method is looking for a
domCryptoContext, that is created during computeSignature. I'm guessing I'll
have to override computeSignature to do that?
Stephen W. Chappell
-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
You could put the SecurityTokenReference in the WSDocInfo via the
addProtectionElement(Element) method. These tokens are also stored in the
XML Security crypto context.
Colm.
On Mon, Nov 24, 2014 at 3:06 PM, stephen.ctr.chapp...@faa.gov wrote:
Thanx, Colm. But the storeElementInContext()
Ok thanks. It's hard to tell what the problem is exactly here. However,
I've merged some code to CXF to make the signature protection policy
validation more robust, this might fix the problem. Can you try again with
the latest code?
Colm.
On Mon, Nov 24, 2014 at 2:43 PM, tobee
finally got the response in 1.7 - works well now
in 1.6 still java.lang.IllegalArgumentException: Missing argument :(
1.6 without BC the same error
--
View this message in context:
http://cxf.547215.n5.nabble.com/possible-wss4j-bug-tp5750539p5751397.html
Sent from the cxf-user mailing list
I think there are just some simple issues here surrounding ports (you are
sending to 9443 when the STS itself is set up on 8443), and the fact that
you are locating two STS instances with the same port names on a single
container. If you can replicate the issue with two separate containers then
Hi,
If you just need to deactivate WS-Addressing decoupled endpoint for client
call, you can use this code:
((BindingProvider)proxy).getRequestContext()
.put(org.apache.cxf.ws.addressing.replyto,
AddressingConstants.getAnonymousURI());
And activate it again by setting appropriate endpoint
Ok good. I've fixed two bugs so far in pursuit of this issue :-)
I think that your setup of BouncyCastle is actually causing it not to be
used with JDK 6. All you need to do is add the bcprov jar to the classpath
of your project, and WSS4J should take care of installing it in the correct
place in
And the way to enable WS-Addressing only for SOAP endpoint with something
like a feature ? Is there a kind of interceptor for the initialization
phase of the client and server endpoint ?
Le Mon Nov 24 2014 at 16:31:08, Andrei Shakirin ashaki...@talend.com a
écrit :
Hi,
If you just need to
Colm -
That seems to resolve that issue, thanx! But now I have another issue - the
thing the STR refers to (the SAML assertion) can't be resolved. Here is the
exception that I get:
Caused by: org.apache.ws.security.WSSecurityException: Signature creation failed
at
You'll need to do the exact same thing with the SAML Assertion DOM Element
- register it with the XML Security Crypto Context, via the WSSecurityUtil
or WSDocInfo methods.
Colm.
On Mon, Nov 24, 2014 at 5:00 PM, stephen.ctr.chapp...@faa.gov wrote:
Colm -
That seems to resolve that issue,
roger, i'll get you the output tonight
On Mon, Nov 24, 2014 at 5:02 AM, Aki Yoshida elak...@gmail.com wrote:
your exception stracktrace seems to indicate that the problem is
happening when the response message is being processed.
Can you check how the request message from the cxf-client and
Hi,
I have to write webservice based on provided WSDL and additional
specification.
Sample request, which I need to process looks like:
ns0:findMedDocsOfPatientRequestPar
xmlns:ns0=http://www.domain.com/xsd/smth/reg;
xmlns:ns1=http://www.domain.com/xsd/smth/datatypes;
metadata
CLASSPATH=.;C:\jdk1.6\lib\tools.jar
No progress after doing those:
1 removed all the java.security entries for BC
2 removed all the jars except folder where i unpacked it(one in JRE was in
use)
3 when I copied it to same folder i run it from(where testcxf is located) -
still same issue
2014-11-24
Hi,
I was wondering what the correct way was to integrate CXF with spring-boot
using the Spring annotation configuration.
Is my end point declaration correct in the context of the Spring Framework?
Will the endpoint be managed by Spring?
@Configuration
Colm –
Doing that leads to another exception …
Caused by: javax.xml.stream.XMLStreamException: Trying to write END_DOCUMENT
when document has no root (ie. trying to output empty document).
at
com.ctc.wstx.sw.BaseStreamWriter.throwOutputError(BaseStreamWriter.java:1537)
A few observations. The entire wsdl/xsd is dumped to console on the both
the client and server side with the following stack traces, but i think
it's just an ignorable warning.
The service accepts the client request and processes it. It looks like the
service side response isn't serializing
21 matches
Mail list logo
