You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Akitoshi Yoshida (JIRA)" <ji...@apache.org> on 2014/07/21 11:25:39 UTC

[jira] [Commented] (CXF-5875) Problems in WS-Addressing with anonymous replyTo or faultTo Address

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

Akitoshi Yoshida commented on CXF-5875:
---------------------------------------

I can certainly expect case 3 and case 4 are not working at the moment. But I am not sure if there is actually much need for supporting these two cases. 

Forcing either reply or fault to be returned to the anonymous address and the other to be returned over a separate connection means the original connection to be kept open and the client to wait for the corresponding message over the connection. And there are two questions to ask. First, if the connection can be kept open and the message to be synchronously returned to that connection, either message type (fault or response) can be returned over this connection. So, why only one type needs to be returned over this connection and the other over a new connection? Secondly, this means, for each request, the client must wait for the response over the original connection to receive either the response or fault if any, depending on case 3 or 4. What does the client expect to receive over the original connection for case case 3 when there is an error or case 4 when there is no error? An http 202 empty content message?

Can we clearly answer these questions in favor of supporting these two cases?

regards, aki



> 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)