cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <elak...@googlemail.com>
Subject Re: Adjusting WS-RM systests for http 202
Date Wed, 07 Sep 2011 07:24:32 GMT
2011/9/6 Daniel Kulp <dkulp@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
>

Mime
View raw message