cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject Re: Adjusting WS-RM systests for http 202
Date Thu, 01 Sep 2011 09:15:55 GMT
2011/9/1 Daniel Kulp <>:
> On Wednesday, August 31, 2011 11:27:20 PM Aki Yoshida wrote:
>> Hi,
>> I would like to hear your opinion on the following issue which I
>> encountered while fixing CXF-3768. The original problem reported in
>> CX-3768 is not related to WS-RM.
>> However, fixing this issue has some relevance to the CXF’s WS-RM behavior.
>> Basically, this patch will make the CXF server endpoint to return HTTP
>> 202 with no content if there is nothing (i.e., no response or no
>> non-empty partial response) to return. Currently, the CXF server
>> endpoint returns HTTP 200 response with an empty SOAP body in such
>> cases.
>> I have now changed the code so that the CXF server endpoint returns
>> HTTP 202 with no content in such cases.
> Good.   The W3C test suite for WS-Addressing requires this behavior so this is
> definitely the correct thing to do.
>> For example, when a WS-RM client with a decoupled endpoint sends an
>> application message, the WS-RM server returns  simply an HTTP 202
>> response with no content, as the real response is returned to the
>> decoupled endpoint.
>> Now the problem is that some of the WS-RM systests are counting the
>> number of response messages and those tests are failing when this
>> change is applied.
>> For example,  RMPolicyTest invokes the following 4 calls.
>> oneway greetMeOneWay
>> twoway greetMe
>> twoway pingMe
>> twoway pingMe
>> And its test assertion counts the number of inbound messages and it
>> expects 9 inbound messages: 5 at the http response port and 4 at the
>> decoupled port:
>> http200wESB (with Empty SOAP Body) upon the create sequence at the http port
>> CreateSequnceResponse at the decoupled port
>> http200wESB upon the greetMeOnWay on the http port
>> http200wESB upon the greetMe at the http port
>> greetMeResponse including seqAck range 1-2 at the decoupled port
>> http200wESB upon the pingMe at the http port
>> pingMeResponse including seqAck range  1-3 at the decoupled port
>> http200wESB upon the pingMe at the http port
>> pingMeResponse including seqAck range 1-4 at the decoupled port
>> Now with the change applied, there are only 4 inbound messages that
>> are all returned to the decoupled port:
>> CreateSequnceResponse on the decoupled port
>> greetMeResponse including seqAck range 1-2 at the decoupled port
>> pingMeResponse including seqAck range 1-3 at the decoupled port
>> pingMeResponse including seqAck raage 1-4 at the decoupled port
>> After I accommodated the test class for this new behavior, the test
>> ran successfully.
>> I am not sure if I could proceed and adjust all the test cases for
>> this new behavior or if we need a configuration option to make the
>> server fall back to the old behavior. In the latter case, we should
>> probably restructure all those WS-RM test cases to work with either
>> behavior. That might become complicated. Alternatively, we use those
>> test cases for testing with the new behavior and add only a few
>> specific test cases to check the http200wESB responses. But in anyway,
>> I find that providing this fall back option is somehow ugly, though.
>> Let me know what you think.
> I guess I would need answers to a few questions....
> 1)  What does the RM spec say?   I assume the new behavior is the correct
> behavior?

As Dennis says in his reply, the RM spec doesn't talk about this
transportation binding specific part. The reason, I suppose, is that
this is implicitly covered by the normal WS BP profile that recommends
the use of HTTP 202 if there is nothing to return.

If I remember it correctly, Axis2/Sandesha uses HTTP 202 with no
content for all those responses (e.g., getting the http 202 response
at the http port when using a decoupled client port for the real
responses/acks). I can check this again. But maybe Dennis could also
verify how Axis2 and in particular Metro behave in this case.

> 2) What would a "real"  CXF 2.4 client  do when talking to the new server and
> vice versa?   Would it work?

There is in fact an interop problem which needs to be fixed in the old
CXF versions. For normal WS-RM application messages, those old clients
do not have any problem in handling HTTP 202. However, for the create
sequence call, they do have a problem as they do not handle HTTP 202
and instead expects HTTP 200 with content (but actually, not the
sequence response content but just an empty soap body response).  This
behavior comes from the fact that its http client, HTTPConduit, is not
aware of the decoupled response port and expects some response content
for this twoway call. But this response message is just an empty soap
message, as its real createSequenceResponse is sent to the decoupled

To change this behavior, I needed to modify HTTPConduit to also accept
HTTP 202 for this case. This fix can be easily ported down to the
older CXF versions separately (this relates to your question 3 below)
so that they can work for both behaviors.

> 3) While all this improved work is for 2.5, how hard would it be to create a
> smaller patch for 2.4/2.3 that would allow it to accept either behavior?
> Basically, generate the old behavior on those, but if they update to the
> latest patches, they could still work with the new server.

I think the new behavior can also be ported to 2.4 without much
difficulty but this can be postponed if people think against it.

> I guess I would definitely update the tests for the correct/new behavior.  At
> worst, I would just leave a single test or suite to test the "compatible"
> behavior if we need to implement that.   For the most part, I'm in the "spec
> compliance  and interopability trumps backwords compatibility" camp.  It's
> something that can be release noted.

That sounds good. I'll check the behaviors of other implementation to
make sure we are not breaking something.

regards, aki

> --
> Daniel Kulp
> Talend -

View raw message