Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of jedstrom@savoirtech.com
 designates 209.85.213.45 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1257)
Subject: Re: svn commit: r1336571 -
 /camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/DefaultCxfBinding.java
From: Johan Edstrom <jedstrom@savoirtech.com>
In-Reply-To: <CBD1BC95.F42%babak.vahdat@swissonline.ch>
Date: Thu, 10 May 2012 11:48:42 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <AF44B6D4-02D1-405A-9C2F-B4E564BB9997@gmail.com>
References: <CBD1BC95.F42%babak.vahdat@swissonline.ch>
To: dev@camel.apache.org

We don't make claims from a Camel side.
CXF makes the claims on that, if we can adhere to a range, we certainly=20=

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:

>=20
>=20
> Am 10.05.12 16:41 schrieb "Claus Ibsen" unter <claus.ibsen@gmail.com>:
>=20
>> On Thu, May 10, 2012 at 4:27 PM, Daniel Kulp <dkulp@apache.org> =
wrote:
>>>=20
>>> Not sure about this commit....
>>>=20
>>> 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.
>>>=20
>>=20
>> 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.
>=20
> I don't really agree on this!
>=20
> 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.
>=20
> 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=20
> 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.
>=20
>> There are people who put together their own choices, and dont go with
>> the latest and greatest.
>=20
> 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.
>=20
> That all said, I did already revert that commit and do thank you both =
for
> your
> feedback.
>=20
> Babak
>=20
>=20
>>=20
>> 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.
>>=20
>> Thoughts?
>>=20
>>=20
>>=20
>>> Dan
>>>=20
>>>=20
>>>=20
>>> 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
>>>>=20
>>>> URL: http://svn.apache.org/viewvc?rev=3D1336571&view=3Drev
>>>> Log:
>>>> org.apache.cxf.frontend.MethodDispatcher has been deprecated.
>>>>=20
>>>> Modified:
>>>>=20
>>>>=20
>>>> =
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/componen
>>>> t
>>>> /cxf/DefaultCxfBinding.java
>>>>=20
>>>> Modified:
>>>>=20
>>>> =
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/componen
>>>> t
>>>> /cxf/DefaultCxfBinding.java URL:
>>>>=20
>>>> =
http://svn.apache.org/viewvc/camel/trunk/components/camel-cxf/src/main/j
>>>> a
>>>>=20
>>>> =
va/org/apache/camel/component/cxf/DefaultCxfBinding.java?rev=3D1336571&r1=3D=

>>>> 13
>>>> 36570&r2=3D1336571&view=3Ddiff
>>>>=20
>>>> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>> =3D
>>>> =3D=3D=3D=3D=3D ---
>>>>=20
>>>> =
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/componen
>>>> t
>>>> /cxf/DefaultCxfBinding.java (original) +++
>>>>=20
>>>> =
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
>>>=20
>>=20
>>=20
>>=20
>> --=20
>> 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/
>=20
>=20