2011/9/6 Daniel Kulp <[email protected]>: > 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 >> > [email protected] >> > http://dankulp.com/blog >> > Talend - http://www.talend.com > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog > Talend - http://www.talend.com >
