camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Edstrom <jedst...@savoirtech.com>
Subject Re: svn commit: r1336571 - /camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/DefaultCxfBinding.java
Date Thu, 10 May 2012 17:48:42 GMT
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.ibsen@gmail.com>:
> 
>> On Thu, May 10, 2012 at 4:27 PM, Daniel Kulp <dkulp@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 bvahdat@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
>>> dkulp@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: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus, fusenews
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
> 
> 


Mime
View raw message