[ 
https://issues.apache.org/jira/browse/WSS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh updated WSS-437:
------------------------------------

    Description: 
There is an error when using WSS4J's StaX functionality with CXF with 
WS-Addressing enabled. I've created the following demo for streaming signature 
+ encryption in CXF, based on the DOM demo:

http://svn.apache.org/viewvc/cxf/branches/wss4j2.0-port/distribution/src/main/release/samples/ws_security/stax_sign_enc/

This demo can be run via "mvn -Pserver" and "mvn -Pclient". It works perfectly 
without WS-Addressing. Now edit the following files + uncomment the addressing 
feature:

http://svn.apache.org/viewvc/cxf/branches/wss4j2.0-port/distribution/src/main/release/samples/ws_security/stax_sign_enc/src/main/java/demo/wssec/client/wssec.xml?view=markup
http://svn.apache.org/viewvc/cxf/branches/wss4j2.0-port/distribution/src/main/release/samples/ws_security/stax_sign_enc/src/main/java/demo/wssec/server/wssec.xml?view=markup

The client produces the following SOAP Header fragment:

<soap:Header><Action 
xmlns="http://www.w3.org/2005/08/addressing";>http://cxf.apache.org/hello_world_soap_http/Greeter/greetMeRequest</Action><MessageID>urn:uuid:d7ca1c25-52da-447b-963b-f3d8e498f591</MessageID><To>http://localhost:9000/SoapContext/GreeterPort</To><ReplyTo><Address>http://localhost:9990/decoupled_endpoint</Address></ReplyTo><wsse:Security

As you can see, the "Action" header is in the correct namespace. However, the 
subsequent WS-A headers are not. Dan reckons there is confusion in the 
namespace stack, where perhaps the namespace stack is not being popped on the 
endElement of "Action",

For the record, the server complains with:

org.apache.cxf.binding.soap.SoapFault: A required header representing a Message 
Addressing Property is not present
        at 
org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.mediate(MAPAggregatorImpl.java:490)


  was:

There is an error when using WSS4J's StaX functionality with CXF with 
WS-Addressing enabled. I've created the following demo for streaming signature 
+ encryption in CXF, based on the DOM demo:

http://svn.apache.org/viewvc/cxf/branches/wss4j2.0-port/distribution/src/main/release/samples/ws_security/stax_sign_enc/

This demo can be run via "mvn -Pserver" and "mvn -Pclient". It works perfectly 
without WS-Addressing. Now edit the following files + remove the commented out 
addressing feature:

http://svn.apache.org/viewvc/cxf/branches/wss4j2.0-port/distribution/src/main/release/samples/ws_security/stax_sign_enc/src/main/java/demo/wssec/client/wssec.xml?view=markup
http://svn.apache.org/viewvc/cxf/branches/wss4j2.0-port/distribution/src/main/release/samples/ws_security/stax_sign_enc/src/main/java/demo/wssec/server/wssec.xml?view=markup

The client produces the following SOAP Header fragment:

<soap:Header><Action 
xmlns="http://www.w3.org/2005/08/addressing";>http://cxf.apache.org/hello_world_soap_http/Greeter/greetMeRequest</Action><MessageID>urn:uuid:d7ca1c25-52da-447b-963b-f3d8e498f591</MessageID><To>http://localhost:9000/SoapContext/GreeterPort</To><ReplyTo><Address>http://localhost:9990/decoupled_endpoint</Address></ReplyTo><wsse:Security

As you can see, the "Action" header is in the correct namespace. However, the 
subsequent WS-A headers are not. Dan reckons there is confusion in the 
namespace stack, where perhaps the namespace stack is not being popped on the 
endElement of "Action",

For the record, the server complains with:

org.apache.cxf.binding.soap.SoapFault: A required header representing a Message 
Addressing Property is not present
        at 
org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.mediate(MAPAggregatorImpl.java:490)


    
> Error in using StaX WS-Security + CXF WS-Addressing
> ---------------------------------------------------
>
>                 Key: WSS-437
>                 URL: https://issues.apache.org/jira/browse/WSS-437
>             Project: WSS4J
>          Issue Type: Bug
>            Reporter: Colm O hEigeartaigh
>             Fix For: 2.0
>
>
> There is an error when using WSS4J's StaX functionality with CXF with 
> WS-Addressing enabled. I've created the following demo for streaming 
> signature + encryption in CXF, based on the DOM demo:
> http://svn.apache.org/viewvc/cxf/branches/wss4j2.0-port/distribution/src/main/release/samples/ws_security/stax_sign_enc/
> This demo can be run via "mvn -Pserver" and "mvn -Pclient". It works 
> perfectly without WS-Addressing. Now edit the following files + uncomment the 
> addressing feature:
> http://svn.apache.org/viewvc/cxf/branches/wss4j2.0-port/distribution/src/main/release/samples/ws_security/stax_sign_enc/src/main/java/demo/wssec/client/wssec.xml?view=markup
> http://svn.apache.org/viewvc/cxf/branches/wss4j2.0-port/distribution/src/main/release/samples/ws_security/stax_sign_enc/src/main/java/demo/wssec/server/wssec.xml?view=markup
> The client produces the following SOAP Header fragment:
> <soap:Header><Action 
> xmlns="http://www.w3.org/2005/08/addressing";>http://cxf.apache.org/hello_world_soap_http/Greeter/greetMeRequest</Action><MessageID>urn:uuid:d7ca1c25-52da-447b-963b-f3d8e498f591</MessageID><To>http://localhost:9000/SoapContext/GreeterPort</To><ReplyTo><Address>http://localhost:9990/decoupled_endpoint</Address></ReplyTo><wsse:Security
> As you can see, the "Action" header is in the correct namespace. However, the 
> subsequent WS-A headers are not. Dan reckons there is confusion in the 
> namespace stack, where perhaps the namespace stack is not being popped on the 
> endElement of "Action",
> For the record, the server complains with:
> org.apache.cxf.binding.soap.SoapFault: A required header representing a 
> Message Addressing Property is not present
>       at 
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.mediate(MAPAggregatorImpl.java:490)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to