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. 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. Thanks. Regards, aki
