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