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? 2) What would a "real" CXF 2.4 client do when talking to the new server and vice versa? Would it work? 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 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. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
