You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2011/09/01 02:51:16 UTC
Re: Adjusting WS-RM systests for http 202
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
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Adjusting WS-RM systests for http 202
Posted by Aki Yoshida <el...@googlemail.com>.
2011/9/6 Daniel Kulp <dk...@apache.org>:
> On Tuesday, September 06, 2011 3:22:39 PM Aki Yoshida wrote:
>> Hi Dan,
>> I submitted the patch for this CXF-3768 in trunk.
>> As this issue was raised for 2.4.2., I was thinking of integrating
>> this patch into 2.4.x.
>>
>> But after reading your question, I was not sure about how you thought.
>> Would you prefer to keep the old behavior in 2.4? Technically, the
>> behavior can be simply reverted to the old one by replacing one line
>> in AbstractHTTPDestination. So, we could provide a configuration
>> parameter to switch the behavior for 2.4 (I think we can make the
>> default being the old behavior, as this is a bug fix, but we could
>> make the default being the old behavior if this is considered not a
>> bug but a change of behavior).
>>
>> For 2.5, I suppose we are supporting only the new corrected behavior, right?
>
> Right for 2.5.
>
> For 2.4, I think it's a bit more complicated. Its currently a 200 with a
> (empty body) SOAP message. Are you proposing making it a 202 but keeping the
> soap message? That seems strange to me. Or are you thinking of making it
> also not create the soap message?
>
> PERSONALLY, I would prefer to keep this for 2.5. There are a ton of "WS-RM
> goodness" things going on there that this seems to really fit. That said,
> I'm not really strong either way.
>
For 2.4, I was initially thinking of making it also not create the
soap message as in 2.5. But after reading your comment, I thought I
should introduce an option to fall back to the old behavior.
But not doing anything for 2.4 is also fine. In that case, I will
briefly remark this point in the jira ticket and set its status to
resolved for 2.5.
thanks.
regards, aki
>
> Dan
>
>
>
>
>>
>> regards, aki
>>
>> > 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
>> > dkulp@apache.org
>> > http://dankulp.com/blog
>> > Talend - http://www.talend.com
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
Re: Adjusting WS-RM systests for http 202
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday, September 06, 2011 3:22:39 PM Aki Yoshida wrote:
> Hi Dan,
> I submitted the patch for this CXF-3768 in trunk.
> As this issue was raised for 2.4.2., I was thinking of integrating
> this patch into 2.4.x.
>
> But after reading your question, I was not sure about how you thought.
> Would you prefer to keep the old behavior in 2.4? Technically, the
> behavior can be simply reverted to the old one by replacing one line
> in AbstractHTTPDestination. So, we could provide a configuration
> parameter to switch the behavior for 2.4 (I think we can make the
> default being the old behavior, as this is a bug fix, but we could
> make the default being the old behavior if this is considered not a
> bug but a change of behavior).
>
> For 2.5, I suppose we are supporting only the new corrected behavior, right?
Right for 2.5.
For 2.4, I think it's a bit more complicated. Its currently a 200 with a
(empty body) SOAP message. Are you proposing making it a 202 but keeping the
soap message? That seems strange to me. Or are you thinking of making it
also not create the soap message?
PERSONALLY, I would prefer to keep this for 2.5. There are a ton of "WS-RM
goodness" things going on there that this seems to really fit. That said,
I'm not really strong either way.
Dan
>
> regards, aki
>
> > 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
> > dkulp@apache.org
> > http://dankulp.com/blog
> > Talend - http://www.talend.com
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Adjusting WS-RM systests for http 202
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Dan,
I submitted the patch for this CXF-3768 in trunk.
As this issue was raised for 2.4.2., I was thinking of integrating
this patch into 2.4.x.
But after reading your question, I was not sure about how you thought.
Would you prefer to keep the old behavior in 2.4? Technically, the
behavior can be simply reverted to the old one by replacing one line
in AbstractHTTPDestination. So, we could provide a configuration
parameter to switch the behavior for 2.4 (I think we can make the
default being the old behavior, as this is a bug fix, but we could
make the default being the old behavior if this is considered not a
bug but a change of behavior).
For 2.5, I suppose we are supporting only the new corrected behavior, right?
regards, aki
> 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
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
Re: Adjusting WS-RM systests for http 202
Posted by Aki Yoshida <el...@googlemail.com>.
2011/9/1 Dennis Sosnoski <dm...@sosnoski.com>:
> On 09/01/2011 12:51 PM, Daniel Kulp wrote:
>> On Wednesday, August 31, 2011 11:27:20 PM Aki Yoshida wrote:
>>
>>> 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.
>>>
>>> ...
>>
>> 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?
>
> I don't see anything in the RM spec covering decoupled endpoints, but
> WS-MakeConnection
> (http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.1-spec-os.html)
> shows 202 responses when no data is available. In the absence of any
> other guidelines, this is probably best for WS-RM, too.
>
> Aki, I'd suggest eliminating or simplifying existing WS-RM unit tests
> when there is no spec justification for the behavior being tested. Tests
> based solely on the current implementation are not appropriate. I've
> spent a lot of time fighting these in the past, and I'm sure you're
> experiencing the same.
Okay. Sound good. We just need to make sure that the new behavior has
no issue with the other major implementations. Do you have the
transcriptions of messages sent by Metro when a decoupled client
endpoint is used?
I can check what a few others do for that case later today.
thanks.
regards, aki
>
> - Dennis
>
>
Re: Adjusting WS-RM systests for http 202
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
On 09/01/2011 12:51 PM, Daniel Kulp wrote:
> On Wednesday, August 31, 2011 11:27:20 PM Aki Yoshida wrote:
>
>> 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.
>>
>> ...
>
> 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?
I don't see anything in the RM spec covering decoupled endpoints, but
WS-MakeConnection
(http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.1-spec-os.html)
shows 202 responses when no data is available. In the absence of any
other guidelines, this is probably best for WS-RM, too.
Aki, I'd suggest eliminating or simplifying existing WS-RM unit tests
when there is no spec justification for the behavior being tested. Tests
based solely on the current implementation are not appropriate. I've
spent a lot of time fighting these in the past, and I'm sure you're
experiencing the same.
- Dennis
Re: Adjusting WS-RM systests for http 202
Posted by Daniel Kulp <dk...@apache.org>.
On Friday, September 02, 2011 5:50:36 PM Aki Yoshida wrote:
> 2011/9/2 Daniel Kulp <dk...@apache.org>:
> > On Friday, September 02, 2011 10:41:56 AM Aki Yoshida wrote:
> >> Thanks. I looked at some examples of Axis2 and the new behavior can
> >> interoperate with them. But I noticed one thing in the create sequence
> >> behavior for a decoupled endpoint case.
> >
> > Oh... cool... can I assign CXF-372 to you. :-)
> >
> > Seriously, CXF-371, CXF-372, and CXF-373 really seem kind of "bogus" to
> > me and I was thinking of just closing them. If a user encounters an
> > issue that we find to be a bug, we can log the bug.
>
> If it's not in hurry, I can take them and see what we can do.
I'm not in any hurry. They've been there for 5 years. What's a little
longer? :-)
Dan
>
> There used to be some public endpoints some years ago. But there seems
> to be public endpoints nor some standard interop test cases. So, I
> don't know how far we want to go in this interop stuff. Besides, those
> tests based on some public endpoints are very subjective to the
> technical environment and we can't integrate them in our build
> process.
>
> So, what I was thinking about regarding the interop tests is to make
> some mocked conduit for CXF to intercept and compare the CXF's
> outgoing requests against the previously recorded CXF's expected
> requests and extract some properties, then to feed back the recorded
> non-CXF's incoming responses to the CXF's response channel and
> possibly to the decoupled channel if configured.
>
> The recorded messages that are fed back to the CXF endpoints are
> parameterized and enhanced with the runtime per-message properties
> that are extracted during the request processing so that they look
> like the expected response messages.
>
> |f we go this way, we can at least say that we have some automatic
>
> interop tests for Axis2 1.6.0 etc without using the actual systems
> during the tests.
>
>
> regards, aki
>
> > Dan
> >
> >> Axis2 sets replyTo to the anonymous address so that the
> >> CreateSequenceResponse comes back directly in the HTTP response,
> >> whereas all the other responses come back to the decoupled endpoint.
> >> In contrast, CXF sets replyTo to the decoupled endpoint so that the
> >> create sequence response also comes back to the decoupled endpoint.
> >> Although they interoperate each other, I think it would be nice to
> >> provide a configuration option in CXF to also set replyTo to the
> >> anonymous address for the create sequence. How do you think?
> >>
> >> This can be a configuration property somewhere in the manager or
> >> sorcePolicy or a request context property. If it goes to the
> >> configuration, I don't exactly where we should put it. I saw you
> >> started to work on the manager config for the version switching
> >> feature. Maybe, you can tell me where you would put it.
> >>
> >> Thanks.
> >>
> >> regards, aki
> >>
> >> > - Dennis
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
> > Talend - http://www.talend.com
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Adjusting WS-RM systests for http 202
Posted by Aki Yoshida <el...@googlemail.com>.
2011/9/2 Daniel Kulp <dk...@apache.org>:
> On Friday, September 02, 2011 10:41:56 AM Aki Yoshida wrote:
>> Thanks. I looked at some examples of Axis2 and the new behavior can
>> interoperate with them. But I noticed one thing in the create sequence
>> behavior for a decoupled endpoint case.
>
> Oh... cool... can I assign CXF-372 to you. :-)
>
> Seriously, CXF-371, CXF-372, and CXF-373 really seem kind of "bogus" to me and
> I was thinking of just closing them. If a user encounters an issue that we
> find to be a bug, we can log the bug.
If it's not in hurry, I can take them and see what we can do.
There used to be some public endpoints some years ago. But there seems
to be public endpoints nor some standard interop test cases. So, I
don't know how far we want to go in this interop stuff. Besides, those
tests based on some public endpoints are very subjective to the
technical environment and we can't integrate them in our build
process.
So, what I was thinking about regarding the interop tests is to make
some mocked conduit for CXF to intercept and compare the CXF's
outgoing requests against the previously recorded CXF's expected
requests and extract some properties, then to feed back the recorded
non-CXF's incoming responses to the CXF's response channel and
possibly to the decoupled channel if configured.
The recorded messages that are fed back to the CXF endpoints are
parameterized and enhanced with the runtime per-message properties
that are extracted during the request processing so that they look
like the expected response messages.
|f we go this way, we can at least say that we have some automatic
interop tests for Axis2 1.6.0 etc without using the actual systems
during the tests.
regards, aki
>
> Dan
>
>
>
>>
>> Axis2 sets replyTo to the anonymous address so that the
>> CreateSequenceResponse comes back directly in the HTTP response,
>> whereas all the other responses come back to the decoupled endpoint.
>> In contrast, CXF sets replyTo to the decoupled endpoint so that the
>> create sequence response also comes back to the decoupled endpoint.
>> Although they interoperate each other, I think it would be nice to
>> provide a configuration option in CXF to also set replyTo to the
>> anonymous address for the create sequence. How do you think?
>>
>> This can be a configuration property somewhere in the manager or
>> sorcePolicy or a request context property. If it goes to the
>> configuration, I don't exactly where we should put it. I saw you
>> started to work on the manager config for the version switching
>> feature. Maybe, you can tell me where you would put it.
>>
>> Thanks.
>>
>> regards, aki
>>
>> > - Dennis
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
Re: Adjusting WS-RM systests for http 202
Posted by Daniel Kulp <dk...@apache.org>.
On Friday, September 02, 2011 10:41:56 AM Aki Yoshida wrote:
> Thanks. I looked at some examples of Axis2 and the new behavior can
> interoperate with them. But I noticed one thing in the create sequence
> behavior for a decoupled endpoint case.
Oh... cool... can I assign CXF-372 to you. :-)
Seriously, CXF-371, CXF-372, and CXF-373 really seem kind of "bogus" to me and
I was thinking of just closing them. If a user encounters an issue that we
find to be a bug, we can log the bug.
Dan
>
> Axis2 sets replyTo to the anonymous address so that the
> CreateSequenceResponse comes back directly in the HTTP response,
> whereas all the other responses come back to the decoupled endpoint.
> In contrast, CXF sets replyTo to the decoupled endpoint so that the
> create sequence response also comes back to the decoupled endpoint.
> Although they interoperate each other, I think it would be nice to
> provide a configuration option in CXF to also set replyTo to the
> anonymous address for the create sequence. How do you think?
>
> This can be a configuration property somewhere in the manager or
> sorcePolicy or a request context property. If it goes to the
> configuration, I don't exactly where we should put it. I saw you
> started to work on the manager config for the version switching
> feature. Maybe, you can tell me where you would put it.
>
> Thanks.
>
> regards, aki
>
> > - Dennis
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Adjusting WS-RM systests for http 202
Posted by Aki Yoshida <el...@googlemail.com>.
2011/9/2 Dennis Sosnoski <dm...@sosnoski.com>:
> On 09/01/2011 09:15 PM, Aki Yoshida wrote:
>> 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.
>
> Is this actually stated in BP? All I could find was that both 200 and
> 202 responses are allowed for an empty response to a successful request,
> with the comment
> (http://www.ws-i.org/Profiles/BasicProfile-1.1.html#HTTP_Success_Status_Codes):
>
> /Despite the fact that the HTTP 1.1 assigns different meanings to
> response status codes "200" and "202", in the context of the Profile
> they should be considered equivalent by the initiator of the request.
> The Profile accepts both status codes because some SOAP implementations
> have little control over the HTTP protocol implementation and cannot
> control which of these response status codes is sent./
>
> So for BP compliance the client should not care which of these is
> returned by the server.
Hi Dennis,
Okay. You are right. BP technically allows HTTP 200 with no content.
But I think this R1112 rule's allowing 200 for no-content is
controversial, as it puts more burden on the client side to verify
what a valid response is and what is not. If no-content response is
returned always with 202, the client reads the status code and knows
that it's valid to see no content. In contrast, if no-content response
is returned with 200, the client must guess based on the operation
(i.e., oneway or twoway) whether it's valid to see no content or some
data has been lost. This situation becomes even more complicated when
WS-A is involved and a decoupled endpoint is used.
CXF can handle HTTP 200 with no content for oneway calls, but I
remember some other client implementations (e.g. old Axis) expected
some SOAP content when the status is 200.
>
>> 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.
>
> I'll try a decoupled client on Metro and post the results.
Thanks. I looked at some examples of Axis2 and the new behavior can
interoperate with them. But I noticed one thing in the create sequence
behavior for a decoupled endpoint case.
Axis2 sets replyTo to the anonymous address so that the
CreateSequenceResponse comes back directly in the HTTP response,
whereas all the other responses come back to the decoupled endpoint.
In contrast, CXF sets replyTo to the decoupled endpoint so that the
create sequence response also comes back to the decoupled endpoint.
Although they interoperate each other, I think it would be nice to
provide a configuration option in CXF to also set replyTo to the
anonymous address for the create sequence. How do you think?
This can be a configuration property somewhere in the manager or
sorcePolicy or a request context property. If it goes to the
configuration, I don't exactly where we should put it. I saw you
started to work on the manager config for the version switching
feature. Maybe, you can tell me where you would put it.
Thanks.
regards, aki
>
> - Dennis
>
>
Re: Adjusting WS-RM systests for http 202
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
On 09/01/2011 09:15 PM, Aki Yoshida wrote:
> 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.
Is this actually stated in BP? All I could find was that both 200 and
202 responses are allowed for an empty response to a successful request,
with the comment
(http://www.ws-i.org/Profiles/BasicProfile-1.1.html#HTTP_Success_Status_Codes):
/Despite the fact that the HTTP 1.1 assigns different meanings to
response status codes "200" and "202", in the context of the Profile
they should be considered equivalent by the initiator of the request.
The Profile accepts both status codes because some SOAP implementations
have little control over the HTTP protocol implementation and cannot
control which of these response status codes is sent./
So for BP compliance the client should not care which of these is
returned by the server.
> 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.
I'll try a decoupled client on Metro and post the results.
- Dennis
Re: Adjusting WS-RM systests for http 202
Posted by Aki Yoshida <el...@googlemail.com>.
2011/9/1 Daniel Kulp <dk...@apache.org>:
> 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
port.
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
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>