We don't make claims from a Camel side. CXF makes the claims on that, if we can adhere to a range, we certainly I think should do so in an integration framework.
Deciding what others could / should do when there is opportunity for choice tends to be the wrong way in my humble opinion. /je On May 10, 2012, at 11:42 AM, Babak Vahdat wrote: > > > Am 10.05.12 16:41 schrieb "Claus Ibsen" unter <claus.ib...@gmail.com>: > >> On Thu, May 10, 2012 at 4:27 PM, Daniel Kulp <dk...@apache.org> wrote: >>> >>> Not sure about this commit.... >>> >>> This commit would make this area of the code NOT work at all with CXF >>> 2.5.x >>> and older. I'm personally OK with that since 2.10 is primarily tested >>> with >>> 2.6, but I'm not sure if that's the ideal situation. If it is, then >>> the >>> OSGi import ranges for CXF need updating as well to reflect that. >>> >> >> Yeah if we can support both CXF 2.5 and 2.6 at the same time in Camel >> 2.10 then that would be great. > > I don't really agree on this! > > How can we *seriously* claim that? Who does on a regular basis do run the > tests against both the CXF versions X & X+1 after each change by this > component > to make sure we're compatible with the both versions. The release notes > says on > which *exact* version of CXF this release (Camel 2.10) is based on. IMHO > in a > non-OSGi (JAR-Hell) World we should be *very* strict about versioning, as > that's > also what Maven is all about: "Transitive Dependency Management" as you > simply > don't have any other way to go other than being absolutley *strict* that > "mvn dependency:tree" does *not* report any conflict, etc., etc. We all > have seen > the other side of the coin if we would not respect the versioning enough: > NoSuchMethodError, NoSuchFieldError, AbstractMethodError, etc. > > In the OSGi world however a bundle can claim to be dependent on a given > range of > some other bundles in the range of [X, X+Y) *no matter* which *exact* > version > in this range has been given at the runtime! Well to me this's an > unbelievable > magic of OSGi I have not understood til today! Sincerly how can a piece of > software > *seriously* claim/guarantee such a behavior. > >> There are people who put together their own choices, and dont go with >> the latest and greatest. > > IMHO these people are doing wrong and do take a big risk for no good > price! If > there's any reason why they can not upgrade part of the dependency chain, > then > to me it *not* the right time to upgrade at all, so that they should > better wait > Until the time is mature enough for a *serious* upgrade of the whole > dependency > chain. > > That all said, I did already revert that commit and do thank you both for > your > feedback. > > Babak > > >> >> We could then decide for Camel 2.11 to drop support for CXF 2.5, if >> that make sense. I guess not as much as long CXF 2.5 is still active, >> and not announced as EOL. >> >> Thoughts? >> >> >> >>> Dan >>> >>> >>> >>> On Thursday, May 10, 2012 09:59:00 AM bvah...@apache.org wrote: >>>> Author: bvahdat >>>> Date: Thu May 10 09:58:59 2012 >>>> New Revision: 1336571 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=1336571&view=rev >>>> Log: >>>> org.apache.cxf.frontend.MethodDispatcher has been deprecated. >>>> >>>> Modified: >>>> >>>> >>>> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/componen >>>> t >>>> /cxf/DefaultCxfBinding.java >>>> >>>> Modified: >>>> >>>> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/componen >>>> t >>>> /cxf/DefaultCxfBinding.java URL: >>>> >>>> http://svn.apache.org/viewvc/camel/trunk/components/camel-cxf/src/main/j >>>> a >>>> >>>> va/org/apache/camel/component/cxf/DefaultCxfBinding.java?rev=1336571&r1= >>>> 13 >>>> 36570&r2=1336571&view=diff >>>> >>>> ======================================================================== >>>> = >>>> ===== --- >>>> >>>> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/componen >>>> t >>>> /cxf/DefaultCxfBinding.java (original) +++ >>>> >>>> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/componen >>>> t >>>> /cxf/DefaultCxfBinding.java Thu May 10 09:58:59 2012 @@ -52,7 +52,6 @@ >>>> import org.apache.cxf.binding.soap.SoapB >>>> import org.apache.cxf.binding.soap.SoapHeader; >>>> import org.apache.cxf.endpoint.Client; >>>> import org.apache.cxf.endpoint.Endpoint; >>>> -import org.apache.cxf.frontend.MethodDispatcher; >>>> import org.apache.cxf.headers.Header; >>>> import org.apache.cxf.helpers.CastUtils; >>>> import org.apache.cxf.helpers.DOMUtils; >>>> @@ -63,10 +62,12 @@ import org.apache.cxf.message.Message; >>>> import org.apache.cxf.message.MessageContentsList; >>>> import org.apache.cxf.security.SecurityContext; >>>> import org.apache.cxf.service.Service; >>>> +import org.apache.cxf.service.invoker.MethodDispatcher; >>>> import org.apache.cxf.service.model.BindingMessageInfo; >>>> import org.apache.cxf.service.model.BindingOperationInfo; >>>> import org.apache.cxf.service.model.MessagePartInfo; >>>> import org.apache.cxf.service.model.OperationInfo; >>>> + >>>> import org.slf4j.Logger; >>>> import org.slf4j.LoggerFactory; >>> -- >>> Daniel Kulp >>> dk...@apache.org - http://dankulp.com/blog >>> Talend Community Coder - http://coders.talend.com >>> >> >> >> >> -- >> Claus Ibsen >> ----------------- >> CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com >> FuseSource >> Email: cib...@fusesource.com >> Web: http://fusesource.com >> Twitter: davsclaus, fusenews >> Blog: http://davsclaus.blogspot.com/ >> Author of Camel in Action: http://www.manning.com/ibsen/ > >
