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

Reply via email to