cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-5875) Problems in WS-Addressing with anonymous replyTo or faultTo Address
Date Mon, 21 Jul 2014 13:42:39 GMT

    [ https://issues.apache.org/jira/browse/CXF-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14068524#comment-14068524
] 

Daniel Kulp commented on CXF-5875:
----------------------------------

I agree with Aki.   With the blocking HTTP (CXF's default is the blocking HTTPUrlConnection),
I'm not sure how it's possible to support these.   We HAVE to send something back over the
connection in order for the client to continue.   For #3, a 202 might be OK, but that's not
really the right thing.   We could possible duplicate the fault on both, but that's not really
correct either.   

Case 4 COULD be a 202, I believe that's what it's doing right now.   But we'd have to delay
the 202 going back to much much later than we do right now.    Definitely some strange use
cases though.  

> Problems in WS-Addressing with anonymous replyTo or faultTo Address
> -------------------------------------------------------------------
>
>                 Key: CXF-5875
>                 URL: https://issues.apache.org/jira/browse/CXF-5875
>             Project: CXF
>          Issue Type: Bug
>          Components: WS-* Components
>    Affects Versions: 3.0.0
>         Environment: Windows 7 64-bits
> JDK 1.7.0_51 64-bits
>            Reporter: Roberto
>            Priority: Minor
>
> In WS-Addressing, setting the fault-to WSA_ANONYMOUS_ADDRESS does not work if reply-to
is set to a different server. 
> Example:
> EndpointReferenceType replyTo = EndpointReferenceUtils.getEndpointReference("http://localhost:9092/callback");
> EndpointReferenceType faultTo = EndpointReferenceUtils.getEndpointReference(Names.WSA_ANONYMOUS_ADDRESS)
> AddressingProperties maps = new AddressingProperties();
> maps.setReplyTo(replyTo);
> maps.setFaultTo(faultTo);
> requestContext.put(CLIENT_ADDRESSING_PROPERTIES, maps);
> In this case, I expect successful replys sent to "http://localhost:9092/callback", and
exceptions sent back to client. Instead of that, both answers are sent to "http://localhost:9092/callback".

> I made some tests for the following cases:
> Case 1 (No problems found):
> replyTo=endpoint 1 -> result: reply sent to endpoint 1 (OK)
> faultTo=endpoint 2 -> result: fault sent to endpoint 2 (OK)
> Case 2 (No problems found):
> replyTo=WSA_ANONYMOUS_ADDRESS -> result: reply sent back to client (OK)
> faultTo=WSA_ANONYMOUS_ADDRESS -> result: fault sent back to client (OK)
> Case 3 (Unexpected message received in client)
> replyTo=WSA_ANONYMOUS_ADDRESS -> result: reply sent back to client (OK)
> faultTo=endpoint 2 -> result: fault sent to endpoint 2 (OK), but client recieves an
extra empty message which raises an exception (WRONG): "org.apache.cxf.binding.soap.SoapFault:
Error reading XMLStreamReader: Unexpected EOF in prolog"
> Case 4 (Exception sent to replyTo instead of faultTo)
> replyTo=endpoint 1 -> result: reply sent to endpoint 1 (OK)
> faultTo=WSA_ANONYMOUS_ADDRESS -> result: reply sent to endpoint 1 (WRONG)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message