cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <elak...@googlemail.com>
Subject Adjusting WS-RM systests for http 202
Date Wed, 31 Aug 2011 21:27:20 GMT
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

Mime
View raw message