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/
