You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by wanggang1 <wa...@gmail.com> on 2012/03/09 14:49:04 UTC
Camel and Spring 3.1
Hi,
What is the road map for Camel with regard to Spring 3.1?
Thanks
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5550625.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel and Spring 3.1
Posted by Stefan Eder <st...@ebuconnect.de>.
Sorry, forgot to mention that it runs inside Karaf 2.2.5.
Do I have to expect problems?
Thanks Stefan
On 09.03.2012 23:19, Stefan Eder wrote:
> Spring ORM with Hibernate 4 requires Spring 3.1.
> [org.springframework.orm.hibernate4.*]
> I use Camel 2.9 withSpring 3.1 (and Hibernate 4) and had no problems yet.
> - Stefan
>
> On 09.03.2012 22:54, Christian Müller wrote:
>> Is there a special feature you are looking for?
>>
>> There is an issue [CAMEL-4778|
>> https://issues.apache.org/jira/browse/CAMEL-4778] for this upgrade. The
>> challenge here is, Karaf 2.2.x is using Spring 3.0.x, Karaf 3.0.0 is
>> using
>> Spring 3.1.x. Because the Camel feature file leverage on the Karaf
>> Spring
>> feature, we have to make sure it works with Spring 3.0.x *AND* Spring
>> 3.1.x
>> - if possible. If not, we should postpone this upgrade to Camel 3.0.0.
>>
>> Best,
>> Christian
>>
>>
>> On Fri, Mar 9, 2012 at 2:49 PM, wanggang1<wa...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> What is the road map for Camel with regard to Spring 3.1?
>>>
>>> Thanks
>>>
>>> --
>>> View this message in context:
>>> http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5550625.html
>>>
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>
>
>
Re: Camel and Spring 3.1
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Stefan,
thanks for the update.
As I said in my previous e-mail, we can also provide spring-3.0 and
spring-3.1 in Karaf and Camel could reference one or the other.
Regards
JB
On 03/12/2012 06:22 PM, Stefan Eder wrote:
> Camel refers to Spring bundles only indirectly through Karafs standard
> features and I use an own version of these.
> I can imagine that this is not recommended, but it is a requirement for
> me as I use a replacement for Pax logging.
> To ensure that the unwanted bundles don't get packaged it also requires
> some exclusions in the assembly descriptor.
>
> If, as with Hibernate 4, only some new classes introduced with Spring
> 3.1 are required, another solution could be to pack this classes into an
> additional spring bundle.
> Maven dependency:unpack could be utilized to do that.
>
> Regards, Stefan
>
> On 10.03.2012 19:07, Christian Müller wrote:
>> Maybe Stefan don't use the Camel provided features and install all the
>> needed bundles by its own or build its own feature file which use Spring
>> 3.1.x. That's possible but not recommended, because Camel 2.9.1 is "only"
>> tested with Spring 3.0.x. This means it could work, but you cannot be
>> sure.
>> It's also possible that may camel-jpa works with Spring 3.1.x but another
>> Camel component e.g. camel-jms/camel-activemq will fail with Spring
>> 3.1.x.
>>
>> In the past we already did support two different versions of Spring
>> (2.5.x
>> and 3.0.x). I'm not sure were we was happy with this solution (two
>> different feature files in Camel)...
>>
>> Loud thinking:
>> At the moment I'm not sure if it's really the best idea that Camel reuse
>> the Karaf provided Spring feature (may be this is also the case for other
>> features). The reason is the following:
>> Imagine you run Karaf 2.2.x (plain Karaf or ServiceMix) and you don't
>> want
>> to upgrade your container infrastructure multiple times per year (this is
>> the case for my company). When you upgrade your Camel based
>> application to
>> a Camel version which use Spring 3.1.x, you have to:
>> - upgrade your container infrastructure also (Karaf)
>> - or change the Camel provided feature file and change all the places
>> where
>> Camel requires the Spring feature (from Karaf) and replace it with the
>> Spring 3.1.x bundles.
>>
>> Be leveraging the Karaf Spring features it's easier to have all the
>> dependencies in sync, but it adds an (unnecessary) constraint.
>> And if Karaf 2.2.6 also use Spring 3.1.x, it doesn't fix this
>> constraint...
>>
>> I'm interested in your all opinions.
>>
>> Best,
>> Christian
>>
>> On Sat, Mar 10, 2012 at 5:01 PM, wanggang1<wa...@gmail.com> wrote:
>>
>>> Hi Stefan,
>>>
>>> When I used Camel 2.9.1, I saw Maven pulled down Spring 3.0.7-RELEASE as
>>> dependencies. When you added Spring 3.1 explicitly, did it then cause
>>> any
>>> conflict?
>>>
>>> Thanks
>>>
>>> --
>>> View this message in context:
>>> http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5553179.html
>>>
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Camel and Spring 3.1
Posted by Stefan Eder <st...@ebuconnect.de>.
Camel refers to Spring bundles only indirectly through Karafs standard
features and I use an own version of these.
I can imagine that this is not recommended, but it is a requirement for
me as I use a replacement for Pax logging.
To ensure that the unwanted bundles don't get packaged it also requires
some exclusions in the assembly descriptor.
If, as with Hibernate 4, only some new classes introduced with Spring
3.1 are required, another solution could be to pack this classes into an
additional spring bundle.
Maven dependency:unpack could be utilized to do that.
Regards, Stefan
On 10.03.2012 19:07, Christian Müller wrote:
> Maybe Stefan don't use the Camel provided features and install all the
> needed bundles by its own or build its own feature file which use Spring
> 3.1.x. That's possible but not recommended, because Camel 2.9.1 is "only"
> tested with Spring 3.0.x. This means it could work, but you cannot be sure.
> It's also possible that may camel-jpa works with Spring 3.1.x but another
> Camel component e.g. camel-jms/camel-activemq will fail with Spring 3.1.x.
>
> In the past we already did support two different versions of Spring (2.5.x
> and 3.0.x). I'm not sure were we was happy with this solution (two
> different feature files in Camel)...
>
> Loud thinking:
> At the moment I'm not sure if it's really the best idea that Camel reuse
> the Karaf provided Spring feature (may be this is also the case for other
> features). The reason is the following:
> Imagine you run Karaf 2.2.x (plain Karaf or ServiceMix) and you don't want
> to upgrade your container infrastructure multiple times per year (this is
> the case for my company). When you upgrade your Camel based application to
> a Camel version which use Spring 3.1.x, you have to:
> - upgrade your container infrastructure also (Karaf)
> - or change the Camel provided feature file and change all the places where
> Camel requires the Spring feature (from Karaf) and replace it with the
> Spring 3.1.x bundles.
>
> Be leveraging the Karaf Spring features it's easier to have all the
> dependencies in sync, but it adds an (unnecessary) constraint.
> And if Karaf 2.2.6 also use Spring 3.1.x, it doesn't fix this constraint...
>
> I'm interested in your all opinions.
>
> Best,
> Christian
>
> On Sat, Mar 10, 2012 at 5:01 PM, wanggang1<wa...@gmail.com> wrote:
>
>> Hi Stefan,
>>
>> When I used Camel 2.9.1, I saw Maven pulled down Spring 3.0.7-RELEASE as
>> dependencies. When you added Spring 3.1 explicitly, did it then cause any
>> conflict?
>>
>> Thanks
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5553179.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
Re: Camel and Spring 3.1
Posted by Heiko <he...@ciber.com>.
Hi,
When I see the releasenote here:
http://camel.apache.org/camel-2110-release.html
It seems to be possible now to use profiles in order to separate the
configuration for different environments like this:
Ok,this would probably in my beans.xml
But currently I´m not quite sure where I need to put this code:
Is the setting of the profile also right with camel or how this is intended?
Regards,
Heiko
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5740768.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel and Spring 3.1
Posted by Christian Müller <ch...@gmail.com>.
I like this enhancement in camel-test-spring, but it makes it impossible or
too complicated (from my point of view) to support Spring 3.0 and Spring
3.1. And I guess for our user Spring 3.1 support is more important than an
enhances test kit.
Again, if we/David cannot find a way to get it simply working with both
versions, I'm +1 to postpone it to Camel 3.0.0.
Best,
Christian
Re: Camel and Spring 3.1
Posted by Willem Jiang <wi...@gmail.com>.
We may add a profile in the camel-test-spring module and consider this
feature is only support in Spring 3.1.
We can let the profile pick up the dependency of spring-test and the
CamelSpringTestContextLoader at that time.
If the people want to have a try with the spring test , he need to
rebuild the camel-test-spring with profile Spring 3.1.
Or we just postpone this feature to Camel 3.0.
Any thought?
On Wed Mar 14 06:18:13 2012, Christian Müller wrote:
> David,
>
> could you please have a loot at this whether you see a way to support both
> versions (Spring 3.0 and 3.0). At present we only discovered an issue with
> the CamelSpringTestContextLoader which is a new class added in Camel
> 2.10.0. If it's not possible, I'm +1 to postpone the changes we did for [1]
> to Camel 2.11.0/3.0.0.
>
> [1] https://issues.apache.org/jira/browse/CAMEL-4987
>
> My 0.02$,
> Christian
>
> On Tue, Mar 13, 2012 at 6:59 AM, Claus Ibsen<cl...@gmail.com> wrote:
>
>> On Tue, Mar 13, 2012 at 2:57 AM, Willem Jiang<wi...@gmail.com>
>> wrote:
>>> Yes, there is no easy way to support both version of Spring at the same
>> time
>>> just by using the maven profile.
>>> Even we use the maven profile, we could put the
>> CamelSpringTestContextLoader
>>> for spring 3.1 to other directory to let compiler to pick up. We can only
>>> support one version of spring in the deploy time.
>>>
>>
>> If its the CamelSpringTestContextLoader then its a new class
>> introduced by David with his work on camel-test-spring.
>> It has not been released as part of any previous Camel releases.
>>
>> So we can change it anyway we like, or *remove* it etc.
>> IMHO its better to support both Spring 3.0 and 3.1 out of the box with
>> no tricks.
>>
>>
>>
>>> As we barely use the @CamelSpringJUnit4ClassRunner. Maybe we could
>> consider
>>> to build the kit with Spring 3.1 and run the unit test with spring 3.0.x
>>>
>>
>> There are people who build from source, and they may build with Spring
>> 3.0.x.
>> So its not always so easy.
>>
>> I suggest Camel 2.10 to support both Spring 3.0 and 3.1 (the latter if
>> possible). We will have a lot of end users
>> who are using either version of Spring.
>>
>>
>>
>>> Just my 2 cents.
>>>
>>>
>>> On 3/12/12 5:45 AM, Christian Müller wrote:
>>>>
>>>> Could you please have a look at [1]. I think it's not possible to
>>>> support both versions, but I would be happy if I'm wrong...
>>>>
>>>> [1] https://issues.apache.org/jira/browse/CAMEL-4778
>>>>
>>>> Best,
>>>> Christian
>>>>
>>>>
>>>> On Sun, Mar 11, 2012 at 2:50 PM, Willem Jiang<willem.jiang@gmail.com
>>>> <ma...@gmail.com>> wrote:
>>>>
>>>> +1 to run test with Spring 3.1 profile.
>>>> As Spring always has a good backward compatibility, I don't think we
>>>> will hit the test issue when we upgrade to Spring 3.1.
>>>>
>>>>
>>>> On 3/11/12 3:12 AM, Christian Müller wrote:
>>>>
>>>> I will add a spring-3.1 profile in my local workspace and see
>>>> how it works
>>>> (we could have a Spring 3.0.x and a Spring 3.1.x build). If this
>>>> works I
>>>> will move on and see how we do it for Karaf...
>>>>
>>>> Best,
>>>> Christian
>>>>
>>>> On Sat, Mar 10, 2012 at 7:07 PM, Christian Müller<
>>>> christian.mueller@gmail.com
>>>> <ma...@gmail.com>> wrote:
>>>>
>>>>
>>>> Maybe Stefan don't use the Camel provided features and
>>>> install all the
>>>> needed bundles by its own or build its own feature file
>>>> which use Spring
>>>> 3.1.x. That's possible but not recommended, because Camel
>>>> 2.9.1 is "only"
>>>> tested with Spring 3.0.x. This means it could work, but you
>>>> cannot be sure.
>>>> It's also possible that may camel-jpa works with Spring
>>>> 3.1.x but another
>>>> Camel component e.g. camel-jms/camel-activemq will fail with
>>>> Spring 3.1.x.
>>>>
>>>> In the past we already did support two different versions of
>>>> Spring (2.5.x
>>>> and 3.0.x). I'm not sure were we was happy with this
>>>> solution (two
>>>> different feature files in Camel)...
>>>>
>>>> Loud thinking:
>>>> At the moment I'm not sure if it's really the best idea that
>>>> Camel reuse
>>>> the Karaf provided Spring feature (may be this is also the
>>>> case for other
>>>> features). The reason is the following:
>>>> Imagine you run Karaf 2.2.x (plain Karaf or ServiceMix) and
>>>> you don't want
>>>> to upgrade your container infrastructure multiple times per
>>>> year (this is
>>>> the case for my company). When you upgrade your Camel based
>>>> application to
>>>> a Camel version which use Spring 3.1.x, you have to:
>>>> - upgrade your container infrastructure also (Karaf)
>>>> - or change the Camel provided feature file and change all
>>>> the places
>>>> where Camel requires the Spring feature (from Karaf) and
>>>> replace it with
>>>> the Spring 3.1.x bundles.
>>>>
>>>> Be leveraging the Karaf Spring features it's easier to have
>>>> all the
>>>> dependencies in sync, but it adds an (unnecessary)
>> constraint.
>>>> And if Karaf 2.2.6 also use Spring 3.1.x, it doesn't fix
>>>> this constraint...
>>>>
>>>> I'm interested in your all opinions.
>>>>
>>>> Best,
>>>> Christian
>>>>
>>>>
>>>> On Sat, Mar 10, 2012 at 5:01 PM,
>>>> wanggang1<wa...@gmail.com>>
>>>>
>>>> wrote:
>>>>
>>>> Hi Stefan,
>>>>
>>>> When I used Camel 2.9.1, I saw Maven pulled down Spring
>>>> 3.0.7-RELEASE as
>>>> dependencies. When you added Spring 3.1 explicitly, did
>>>> it then cause any
>>>> conflict?
>>>>
>>>> Thanks
>>>>
>>>> --
>>>> View this message in context:
>>>>
>>>> http://camel.465427.n5.nabble.
>> __com/Camel-and-Spring-3-1-__tp5550625p5553179.html
>>>>
>>>>
>>>> <
>> http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5553179.html
>>>
>>>> Sent from the Camel - Users mailing list archive at
>>>> Nabble.com.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Willem
>>>> ------------------------------__----
>>>> FuseSource
>>>> Web: http://www.fusesource.com
>>>> Blog: http://willemjiang.blogspot.__com
>>>>
>>>> <http://willemjiang.blogspot.com> (English)
>>>> http://jnn.javaeye.com (Chinese)
>>>> Twitter: willemjiang
>>>> Weibo: willemjiang
>>>>
>>>>
>>>
>>>
>>> --
>>> Willem
>>> ----------------------------------
>>> FuseSource
>>> Web: http://www.fusesource.com
>>> Blog: http://willemjiang.blogspot.com (English)
>>> http://jnn.javaeye.com (Chinese)
>>> Twitter: willemjiang
>>> Weibo: willemjiang
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> 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/
>>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: Camel and Spring 3.1
Posted by Christian Müller <ch...@gmail.com>.
David,
could you please have a loot at this whether you see a way to support both
versions (Spring 3.0 and 3.0). At present we only discovered an issue with
the CamelSpringTestContextLoader which is a new class added in Camel
2.10.0. If it's not possible, I'm +1 to postpone the changes we did for [1]
to Camel 2.11.0/3.0.0.
[1] https://issues.apache.org/jira/browse/CAMEL-4987
My 0.02$,
Christian
On Tue, Mar 13, 2012 at 6:59 AM, Claus Ibsen <cl...@gmail.com> wrote:
> On Tue, Mar 13, 2012 at 2:57 AM, Willem Jiang <wi...@gmail.com>
> wrote:
> > Yes, there is no easy way to support both version of Spring at the same
> time
> > just by using the maven profile.
> > Even we use the maven profile, we could put the
> CamelSpringTestContextLoader
> > for spring 3.1 to other directory to let compiler to pick up. We can only
> > support one version of spring in the deploy time.
> >
>
> If its the CamelSpringTestContextLoader then its a new class
> introduced by David with his work on camel-test-spring.
> It has not been released as part of any previous Camel releases.
>
> So we can change it anyway we like, or *remove* it etc.
> IMHO its better to support both Spring 3.0 and 3.1 out of the box with
> no tricks.
>
>
>
> > As we barely use the @CamelSpringJUnit4ClassRunner. Maybe we could
> consider
> > to build the kit with Spring 3.1 and run the unit test with spring 3.0.x
> >
>
> There are people who build from source, and they may build with Spring
> 3.0.x.
> So its not always so easy.
>
> I suggest Camel 2.10 to support both Spring 3.0 and 3.1 (the latter if
> possible). We will have a lot of end users
> who are using either version of Spring.
>
>
>
> > Just my 2 cents.
> >
> >
> > On 3/12/12 5:45 AM, Christian Müller wrote:
> >>
> >> Could you please have a look at [1]. I think it's not possible to
> >> support both versions, but I would be happy if I'm wrong...
> >>
> >> [1] https://issues.apache.org/jira/browse/CAMEL-4778
> >>
> >> Best,
> >> Christian
> >>
> >>
> >> On Sun, Mar 11, 2012 at 2:50 PM, Willem Jiang <willem.jiang@gmail.com
> >> <ma...@gmail.com>> wrote:
> >>
> >> +1 to run test with Spring 3.1 profile.
> >> As Spring always has a good backward compatibility, I don't think we
> >> will hit the test issue when we upgrade to Spring 3.1.
> >>
> >>
> >> On 3/11/12 3:12 AM, Christian Müller wrote:
> >>
> >> I will add a spring-3.1 profile in my local workspace and see
> >> how it works
> >> (we could have a Spring 3.0.x and a Spring 3.1.x build). If this
> >> works I
> >> will move on and see how we do it for Karaf...
> >>
> >> Best,
> >> Christian
> >>
> >> On Sat, Mar 10, 2012 at 7:07 PM, Christian Müller<
> >> christian.mueller@gmail.com
> >> <ma...@gmail.com>> wrote:
> >>
> >>
> >> Maybe Stefan don't use the Camel provided features and
> >> install all the
> >> needed bundles by its own or build its own feature file
> >> which use Spring
> >> 3.1.x. That's possible but not recommended, because Camel
> >> 2.9.1 is "only"
> >> tested with Spring 3.0.x. This means it could work, but you
> >> cannot be sure.
> >> It's also possible that may camel-jpa works with Spring
> >> 3.1.x but another
> >> Camel component e.g. camel-jms/camel-activemq will fail with
> >> Spring 3.1.x.
> >>
> >> In the past we already did support two different versions of
> >> Spring (2.5.x
> >> and 3.0.x). I'm not sure were we was happy with this
> >> solution (two
> >> different feature files in Camel)...
> >>
> >> Loud thinking:
> >> At the moment I'm not sure if it's really the best idea that
> >> Camel reuse
> >> the Karaf provided Spring feature (may be this is also the
> >> case for other
> >> features). The reason is the following:
> >> Imagine you run Karaf 2.2.x (plain Karaf or ServiceMix) and
> >> you don't want
> >> to upgrade your container infrastructure multiple times per
> >> year (this is
> >> the case for my company). When you upgrade your Camel based
> >> application to
> >> a Camel version which use Spring 3.1.x, you have to:
> >> - upgrade your container infrastructure also (Karaf)
> >> - or change the Camel provided feature file and change all
> >> the places
> >> where Camel requires the Spring feature (from Karaf) and
> >> replace it with
> >> the Spring 3.1.x bundles.
> >>
> >> Be leveraging the Karaf Spring features it's easier to have
> >> all the
> >> dependencies in sync, but it adds an (unnecessary)
> constraint.
> >> And if Karaf 2.2.6 also use Spring 3.1.x, it doesn't fix
> >> this constraint...
> >>
> >> I'm interested in your all opinions.
> >>
> >> Best,
> >> Christian
> >>
> >>
> >> On Sat, Mar 10, 2012 at 5:01 PM,
> >> wanggang1<wanggang1@gmail.com <ma...@gmail.com>>
> >>
> >> wrote:
> >>
> >> Hi Stefan,
> >>
> >> When I used Camel 2.9.1, I saw Maven pulled down Spring
> >> 3.0.7-RELEASE as
> >> dependencies. When you added Spring 3.1 explicitly, did
> >> it then cause any
> >> conflict?
> >>
> >> Thanks
> >>
> >> --
> >> View this message in context:
> >>
> >> http://camel.465427.n5.nabble.
> __com/Camel-and-Spring-3-1-__tp5550625p5553179.html
> >>
> >>
> >> <
> http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5553179.html
> >
> >> Sent from the Camel - Users mailing list archive at
> >> Nabble.com.
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Willem
> >> ------------------------------__----
> >> FuseSource
> >> Web: http://www.fusesource.com
> >> Blog: http://willemjiang.blogspot.__com
> >>
> >> <http://willemjiang.blogspot.com> (English)
> >> http://jnn.javaeye.com (Chinese)
> >> Twitter: willemjiang
> >> Weibo: willemjiang
> >>
> >>
> >
> >
> > --
> > Willem
> > ----------------------------------
> > FuseSource
> > Web: http://www.fusesource.com
> > Blog: http://willemjiang.blogspot.com (English)
> > http://jnn.javaeye.com (Chinese)
> > Twitter: willemjiang
> > Weibo: willemjiang
>
>
>
> --
> Claus Ibsen
> -----------------
> 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/
>
Re: Camel and Spring 3.1
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Mar 13, 2012 at 2:57 AM, Willem Jiang <wi...@gmail.com> wrote:
> Yes, there is no easy way to support both version of Spring at the same time
> just by using the maven profile.
> Even we use the maven profile, we could put the CamelSpringTestContextLoader
> for spring 3.1 to other directory to let compiler to pick up. We can only
> support one version of spring in the deploy time.
>
If its the CamelSpringTestContextLoader then its a new class
introduced by David with his work on camel-test-spring.
It has not been released as part of any previous Camel releases.
So we can change it anyway we like, or *remove* it etc.
IMHO its better to support both Spring 3.0 and 3.1 out of the box with
no tricks.
> As we barely use the @CamelSpringJUnit4ClassRunner. Maybe we could consider
> to build the kit with Spring 3.1 and run the unit test with spring 3.0.x
>
There are people who build from source, and they may build with Spring 3.0.x.
So its not always so easy.
I suggest Camel 2.10 to support both Spring 3.0 and 3.1 (the latter if
possible). We will have a lot of end users
who are using either version of Spring.
> Just my 2 cents.
>
>
> On 3/12/12 5:45 AM, Christian Müller wrote:
>>
>> Could you please have a look at [1]. I think it's not possible to
>> support both versions, but I would be happy if I'm wrong...
>>
>> [1] https://issues.apache.org/jira/browse/CAMEL-4778
>>
>> Best,
>> Christian
>>
>>
>> On Sun, Mar 11, 2012 at 2:50 PM, Willem Jiang <willem.jiang@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> +1 to run test with Spring 3.1 profile.
>> As Spring always has a good backward compatibility, I don't think we
>> will hit the test issue when we upgrade to Spring 3.1.
>>
>>
>> On 3/11/12 3:12 AM, Christian Müller wrote:
>>
>> I will add a spring-3.1 profile in my local workspace and see
>> how it works
>> (we could have a Spring 3.0.x and a Spring 3.1.x build). If this
>> works I
>> will move on and see how we do it for Karaf...
>>
>> Best,
>> Christian
>>
>> On Sat, Mar 10, 2012 at 7:07 PM, Christian Müller<
>> christian.mueller@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>>
>> Maybe Stefan don't use the Camel provided features and
>> install all the
>> needed bundles by its own or build its own feature file
>> which use Spring
>> 3.1.x. That's possible but not recommended, because Camel
>> 2.9.1 is "only"
>> tested with Spring 3.0.x. This means it could work, but you
>> cannot be sure.
>> It's also possible that may camel-jpa works with Spring
>> 3.1.x but another
>> Camel component e.g. camel-jms/camel-activemq will fail with
>> Spring 3.1.x.
>>
>> In the past we already did support two different versions of
>> Spring (2.5.x
>> and 3.0.x). I'm not sure were we was happy with this
>> solution (two
>> different feature files in Camel)...
>>
>> Loud thinking:
>> At the moment I'm not sure if it's really the best idea that
>> Camel reuse
>> the Karaf provided Spring feature (may be this is also the
>> case for other
>> features). The reason is the following:
>> Imagine you run Karaf 2.2.x (plain Karaf or ServiceMix) and
>> you don't want
>> to upgrade your container infrastructure multiple times per
>> year (this is
>> the case for my company). When you upgrade your Camel based
>> application to
>> a Camel version which use Spring 3.1.x, you have to:
>> - upgrade your container infrastructure also (Karaf)
>> - or change the Camel provided feature file and change all
>> the places
>> where Camel requires the Spring feature (from Karaf) and
>> replace it with
>> the Spring 3.1.x bundles.
>>
>> Be leveraging the Karaf Spring features it's easier to have
>> all the
>> dependencies in sync, but it adds an (unnecessary) constraint.
>> And if Karaf 2.2.6 also use Spring 3.1.x, it doesn't fix
>> this constraint...
>>
>> I'm interested in your all opinions.
>>
>> Best,
>> Christian
>>
>>
>> On Sat, Mar 10, 2012 at 5:01 PM,
>> wanggang1<wanggang1@gmail.com <ma...@gmail.com>>
>>
>> wrote:
>>
>> Hi Stefan,
>>
>> When I used Camel 2.9.1, I saw Maven pulled down Spring
>> 3.0.7-RELEASE as
>> dependencies. When you added Spring 3.1 explicitly, did
>> it then cause any
>> conflict?
>>
>> Thanks
>>
>> --
>> View this message in context:
>>
>> http://camel.465427.n5.nabble.__com/Camel-and-Spring-3-1-__tp5550625p5553179.html
>>
>>
>> <http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5553179.html>
>> Sent from the Camel - Users mailing list archive at
>> Nabble.com.
>>
>>
>>
>>
>>
>>
>> --
>> Willem
>> ------------------------------__----
>> FuseSource
>> Web: http://www.fusesource.com
>> Blog: http://willemjiang.blogspot.__com
>>
>> <http://willemjiang.blogspot.com> (English)
>> http://jnn.javaeye.com (Chinese)
>> Twitter: willemjiang
>> Weibo: willemjiang
>>
>>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang
--
Claus Ibsen
-----------------
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/
Re: Camel and Spring 3.1
Posted by Willem Jiang <wi...@gmail.com>.
Yes, there is no easy way to support both version of Spring at the same
time just by using the maven profile.
Even we use the maven profile, we could put the
CamelSpringTestContextLoader for spring 3.1 to other directory to let
compiler to pick up. We can only support one version of spring in the
deploy time.
As we barely use the @CamelSpringJUnit4ClassRunner. Maybe we could
consider to build the kit with Spring 3.1 and run the unit test with
spring 3.0.x
Just my 2 cents.
On 3/12/12 5:45 AM, Christian Müller wrote:
> Could you please have a look at [1]. I think it's not possible to
> support both versions, but I would be happy if I'm wrong...
>
> [1] https://issues.apache.org/jira/browse/CAMEL-4778
>
> Best,
> Christian
>
> On Sun, Mar 11, 2012 at 2:50 PM, Willem Jiang <willem.jiang@gmail.com
> <ma...@gmail.com>> wrote:
>
> +1 to run test with Spring 3.1 profile.
> As Spring always has a good backward compatibility, I don't think we
> will hit the test issue when we upgrade to Spring 3.1.
>
>
> On 3/11/12 3:12 AM, Christian Müller wrote:
>
> I will add a spring-3.1 profile in my local workspace and see
> how it works
> (we could have a Spring 3.0.x and a Spring 3.1.x build). If this
> works I
> will move on and see how we do it for Karaf...
>
> Best,
> Christian
>
> On Sat, Mar 10, 2012 at 7:07 PM, Christian Müller<
> christian.mueller@gmail.com
> <ma...@gmail.com>> wrote:
>
> Maybe Stefan don't use the Camel provided features and
> install all the
> needed bundles by its own or build its own feature file
> which use Spring
> 3.1.x. That's possible but not recommended, because Camel
> 2.9.1 is "only"
> tested with Spring 3.0.x. This means it could work, but you
> cannot be sure.
> It's also possible that may camel-jpa works with Spring
> 3.1.x but another
> Camel component e.g. camel-jms/camel-activemq will fail with
> Spring 3.1.x.
>
> In the past we already did support two different versions of
> Spring (2.5.x
> and 3.0.x). I'm not sure were we was happy with this
> solution (two
> different feature files in Camel)...
>
> Loud thinking:
> At the moment I'm not sure if it's really the best idea that
> Camel reuse
> the Karaf provided Spring feature (may be this is also the
> case for other
> features). The reason is the following:
> Imagine you run Karaf 2.2.x (plain Karaf or ServiceMix) and
> you don't want
> to upgrade your container infrastructure multiple times per
> year (this is
> the case for my company). When you upgrade your Camel based
> application to
> a Camel version which use Spring 3.1.x, you have to:
> - upgrade your container infrastructure also (Karaf)
> - or change the Camel provided feature file and change all
> the places
> where Camel requires the Spring feature (from Karaf) and
> replace it with
> the Spring 3.1.x bundles.
>
> Be leveraging the Karaf Spring features it's easier to have
> all the
> dependencies in sync, but it adds an (unnecessary) constraint.
> And if Karaf 2.2.6 also use Spring 3.1.x, it doesn't fix
> this constraint...
>
> I'm interested in your all opinions.
>
> Best,
> Christian
>
>
> On Sat, Mar 10, 2012 at 5:01 PM,
> wanggang1<wanggang1@gmail.com <ma...@gmail.com>>
> wrote:
>
> Hi Stefan,
>
> When I used Camel 2.9.1, I saw Maven pulled down Spring
> 3.0.7-RELEASE as
> dependencies. When you added Spring 3.1 explicitly, did
> it then cause any
> conflict?
>
> Thanks
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.__com/Camel-and-Spring-3-1-__tp5550625p5553179.html
> <http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5553179.html>
> Sent from the Camel - Users mailing list archive at
> Nabble.com.
>
>
>
>
>
>
> --
> Willem
> ------------------------------__----
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.__com
> <http://willemjiang.blogspot.com> (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang
>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: Camel and Spring 3.1
Posted by Willem Jiang <wi...@gmail.com>.
+1 to run test with Spring 3.1 profile.
As Spring always has a good backward compatibility, I don't think we
will hit the test issue when we upgrade to Spring 3.1.
On 3/11/12 3:12 AM, Christian Müller wrote:
> I will add a spring-3.1 profile in my local workspace and see how it works
> (we could have a Spring 3.0.x and a Spring 3.1.x build). If this works I
> will move on and see how we do it for Karaf...
>
> Best,
> Christian
>
> On Sat, Mar 10, 2012 at 7:07 PM, Christian Müller<
> christian.mueller@gmail.com> wrote:
>
>> Maybe Stefan don't use the Camel provided features and install all the
>> needed bundles by its own or build its own feature file which use Spring
>> 3.1.x. That's possible but not recommended, because Camel 2.9.1 is "only"
>> tested with Spring 3.0.x. This means it could work, but you cannot be sure.
>> It's also possible that may camel-jpa works with Spring 3.1.x but another
>> Camel component e.g. camel-jms/camel-activemq will fail with Spring 3.1.x.
>>
>> In the past we already did support two different versions of Spring (2.5.x
>> and 3.0.x). I'm not sure were we was happy with this solution (two
>> different feature files in Camel)...
>>
>> Loud thinking:
>> At the moment I'm not sure if it's really the best idea that Camel reuse
>> the Karaf provided Spring feature (may be this is also the case for other
>> features). The reason is the following:
>> Imagine you run Karaf 2.2.x (plain Karaf or ServiceMix) and you don't want
>> to upgrade your container infrastructure multiple times per year (this is
>> the case for my company). When you upgrade your Camel based application to
>> a Camel version which use Spring 3.1.x, you have to:
>> - upgrade your container infrastructure also (Karaf)
>> - or change the Camel provided feature file and change all the places
>> where Camel requires the Spring feature (from Karaf) and replace it with
>> the Spring 3.1.x bundles.
>>
>> Be leveraging the Karaf Spring features it's easier to have all the
>> dependencies in sync, but it adds an (unnecessary) constraint.
>> And if Karaf 2.2.6 also use Spring 3.1.x, it doesn't fix this constraint...
>>
>> I'm interested in your all opinions.
>>
>> Best,
>> Christian
>>
>>
>> On Sat, Mar 10, 2012 at 5:01 PM, wanggang1<wa...@gmail.com> wrote:
>>
>>> Hi Stefan,
>>>
>>> When I used Camel 2.9.1, I saw Maven pulled down Spring 3.0.7-RELEASE as
>>> dependencies. When you added Spring 3.1 explicitly, did it then cause any
>>> conflict?
>>>
>>> Thanks
>>>
>>> --
>>> View this message in context:
>>> http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5553179.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>
>>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: Camel and Spring 3.1
Posted by Claus Ibsen <cl...@gmail.com>.
Oh and this is only OSGi with Karaf.
There is also a lot of end users that do not use OSGi or Karaf etc.
They should already be able to use Spring 3.1 with Camel as they want,
such as in a Tomcat etc.
On Mon, Mar 12, 2012 at 6:50 PM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> I dont think this is a road we want to go down. In the old days we had
> a spring 2.x and 3.0 features.xml file and it was a pain to maintain.
> We only had to do this because due limitations in features in Karaf
> back then. Now Karaf is improved and IMHO not needed to be released
> and maintained by Camel project. What about CXF and other libraries
> where people use in Karaf and they want to use Spring 3.1.
>
> The camel components is by default compatible with Spring 3.0 and 3.1.
> There is only one API change in the Spring Test Framework which is
> incompatible between spring 3.0 and 3.1, reported by Christian.
>
> But the camel-test-spring is not an OSGi bundle, and neither available
> as a feature. So people should be able to install any
> of the Camel features and use Spring 3.1.
>
> That said, its not a combo we have tested thoroughly and the default
> unit tests / integration tests, is using Spring 3.0.
> But there is so many combinations of frameworks and 3rd party JARs
> that people can use. We cannot test all combos.
>
> So in my mind upgrading Spring in Karaf should be something people can
> do, and the install any features / bundle that can
> use this Spring version range.
>
> All the Camel bundles that uses Spring have (3,4] in the range.
>
>
>
> On Mon, Mar 12, 2012 at 2:55 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Hi Claus,
>>
>> a "possibility" is to provide both Spring features version on Karaf 2.2.x.
>>
>> spring-3.0
>>
>> and
>>
>> spring-3.1
>>
>> It will allow us to "upgrade" Camel to support Spring 3.1 without waiting
>> for Karaf 3.0.0.
>>
>> My 0.02$ ;)
>>
>> Regards
>> JB
>>
>>
>> On 03/11/2012 09:29 AM, Claus Ibsen wrote:
>>>
>>> Hi
>>>
>>> The irony is that an OSGi environment should be very modular and dynamic.
>>> So upgrading Spring to 3.1, ought to be a use-case that should be
>>> straight forward.
>>>
>>> The camel spring bundles have the spring version range [3.0,4.0) I
>>> think, so they ought to be not limited to only 3.0.x.
>>> I just checked the pom.xml in camel-spring has:
>>> org.springframework.*;version="[3,4)",
>>>
>>>
>>> On Sat, Mar 10, 2012 at 8:12 PM, Christian Müller
>>> <ch...@gmail.com> wrote:
>>>>
>>>> I will add a spring-3.1 profile in my local workspace and see how it
>>>> works
>>>> (we could have a Spring 3.0.x and a Spring 3.1.x build). If this works I
>>>> will move on and see how we do it for Karaf...
>>>>
>>>> Best,
>>>> Christian
>>>>
>>>> On Sat, Mar 10, 2012 at 7:07 PM, Christian Müller<
>>>> christian.mueller@gmail.com> wrote:
>>>>
>>>>> Maybe Stefan don't use the Camel provided features and install all the
>>>>> needed bundles by its own or build its own feature file which use Spring
>>>>> 3.1.x. That's possible but not recommended, because Camel 2.9.1 is
>>>>> "only"
>>>>> tested with Spring 3.0.x. This means it could work, but you cannot be
>>>>> sure.
>>>>> It's also possible that may camel-jpa works with Spring 3.1.x but
>>>>> another
>>>>> Camel component e.g. camel-jms/camel-activemq will fail with Spring
>>>>> 3.1.x.
>>>>>
>>>>> In the past we already did support two different versions of Spring
>>>>> (2.5.x
>>>>> and 3.0.x). I'm not sure were we was happy with this solution (two
>>>>> different feature files in Camel)...
>>>>>
>>>>> Loud thinking:
>>>>> At the moment I'm not sure if it's really the best idea that Camel reuse
>>>>> the Karaf provided Spring feature (may be this is also the case for
>>>>> other
>>>>> features). The reason is the following:
>>>>> Imagine you run Karaf 2.2.x (plain Karaf or ServiceMix) and you don't
>>>>> want
>>>>> to upgrade your container infrastructure multiple times per year (this
>>>>> is
>>>>> the case for my company). When you upgrade your Camel based application
>>>>> to
>>>>> a Camel version which use Spring 3.1.x, you have to:
>>>>> - upgrade your container infrastructure also (Karaf)
>>>>> - or change the Camel provided feature file and change all the places
>>>>> where Camel requires the Spring feature (from Karaf) and replace it with
>>>>> the Spring 3.1.x bundles.
>>>>>
>>>>> Be leveraging the Karaf Spring features it's easier to have all the
>>>>> dependencies in sync, but it adds an (unnecessary) constraint.
>>>>> And if Karaf 2.2.6 also use Spring 3.1.x, it doesn't fix this
>>>>> constraint...
>>>>>
>>>>> I'm interested in your all opinions.
>>>>>
>>>>> Best,
>>>>> Christian
>>>>>
>>>>>
>>>>> On Sat, Mar 10, 2012 at 5:01 PM, wanggang1<wa...@gmail.com> wrote:
>>>>>
>>>>>> Hi Stefan,
>>>>>>
>>>>>> When I used Camel 2.9.1, I saw Maven pulled down Spring 3.0.7-RELEASE
>>>>>> as
>>>>>> dependencies. When you added Spring 3.1 explicitly, did it then cause
>>>>>> any
>>>>>> conflict?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>>
>>>>>> http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5553179.html
>>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>
>
>
> --
> Claus Ibsen
> -----------------
> 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/
--
Claus Ibsen
-----------------
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/
Re: Camel and Spring 3.1
Posted by Christian Müller <ch...@gmail.com>.
My understanding is now we move forward with upgrading to Spring 3.1 in
Camel 2.10.0. The required change in "CamelSpringTestContextLoader" is not
a big deal to get it working. Supporting Spring profiles is out of scope of
this issue.
In our feature file we will refer to the Spring 3.1 feature as soon it's
available. Thanks JB for the offer to support Spring 3.1 in the next Karaf
2.2.x version!
You agree?
Best,
Christian
Re: Camel and Spring 3.1
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I'm fully agree. My proposal was more: if we are able to fix the Spring
3.1 issue in Camel (I don't talk about OSGi, but in Camel in general),
and that we release a version of Camel which assume to use Spring 3.1,
for people that use OSGi and Karaf, we can prepare a "dual" Spring
feature in Karaf 2.2.x, depending of the timing.
Regards
JB
On 03/12/2012 06:50 PM, Claus Ibsen wrote:
> Hi
>
> I dont think this is a road we want to go down. In the old days we had
> a spring 2.x and 3.0 features.xml file and it was a pain to maintain.
> We only had to do this because due limitations in features in Karaf
> back then. Now Karaf is improved and IMHO not needed to be released
> and maintained by Camel project. What about CXF and other libraries
> where people use in Karaf and they want to use Spring 3.1.
>
> The camel components is by default compatible with Spring 3.0 and 3.1.
> There is only one API change in the Spring Test Framework which is
> incompatible between spring 3.0 and 3.1, reported by Christian.
>
> But the camel-test-spring is not an OSGi bundle, and neither available
> as a feature. So people should be able to install any
> of the Camel features and use Spring 3.1.
>
> That said, its not a combo we have tested thoroughly and the default
> unit tests / integration tests, is using Spring 3.0.
> But there is so many combinations of frameworks and 3rd party JARs
> that people can use. We cannot test all combos.
>
> So in my mind upgrading Spring in Karaf should be something people can
> do, and the install any features / bundle that can
> use this Spring version range.
>
> All the Camel bundles that uses Spring have (3,4] in the range.
>
>
>
> On Mon, Mar 12, 2012 at 2:55 PM, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
>> Hi Claus,
>>
>> a "possibility" is to provide both Spring features version on Karaf 2.2.x.
>>
>> spring-3.0
>>
>> and
>>
>> spring-3.1
>>
>> It will allow us to "upgrade" Camel to support Spring 3.1 without waiting
>> for Karaf 3.0.0.
>>
>> My 0.02$ ;)
>>
>> Regards
>> JB
>>
>>
>> On 03/11/2012 09:29 AM, Claus Ibsen wrote:
>>>
>>> Hi
>>>
>>> The irony is that an OSGi environment should be very modular and dynamic.
>>> So upgrading Spring to 3.1, ought to be a use-case that should be
>>> straight forward.
>>>
>>> The camel spring bundles have the spring version range [3.0,4.0) I
>>> think, so they ought to be not limited to only 3.0.x.
>>> I just checked the pom.xml in camel-spring has:
>>> org.springframework.*;version="[3,4)",
>>>
>>>
>>> On Sat, Mar 10, 2012 at 8:12 PM, Christian Müller
>>> <ch...@gmail.com> wrote:
>>>>
>>>> I will add a spring-3.1 profile in my local workspace and see how it
>>>> works
>>>> (we could have a Spring 3.0.x and a Spring 3.1.x build). If this works I
>>>> will move on and see how we do it for Karaf...
>>>>
>>>> Best,
>>>> Christian
>>>>
>>>> On Sat, Mar 10, 2012 at 7:07 PM, Christian Müller<
>>>> christian.mueller@gmail.com> wrote:
>>>>
>>>>> Maybe Stefan don't use the Camel provided features and install all the
>>>>> needed bundles by its own or build its own feature file which use Spring
>>>>> 3.1.x. That's possible but not recommended, because Camel 2.9.1 is
>>>>> "only"
>>>>> tested with Spring 3.0.x. This means it could work, but you cannot be
>>>>> sure.
>>>>> It's also possible that may camel-jpa works with Spring 3.1.x but
>>>>> another
>>>>> Camel component e.g. camel-jms/camel-activemq will fail with Spring
>>>>> 3.1.x.
>>>>>
>>>>> In the past we already did support two different versions of Spring
>>>>> (2.5.x
>>>>> and 3.0.x). I'm not sure were we was happy with this solution (two
>>>>> different feature files in Camel)...
>>>>>
>>>>> Loud thinking:
>>>>> At the moment I'm not sure if it's really the best idea that Camel reuse
>>>>> the Karaf provided Spring feature (may be this is also the case for
>>>>> other
>>>>> features). The reason is the following:
>>>>> Imagine you run Karaf 2.2.x (plain Karaf or ServiceMix) and you don't
>>>>> want
>>>>> to upgrade your container infrastructure multiple times per year (this
>>>>> is
>>>>> the case for my company). When you upgrade your Camel based application
>>>>> to
>>>>> a Camel version which use Spring 3.1.x, you have to:
>>>>> - upgrade your container infrastructure also (Karaf)
>>>>> - or change the Camel provided feature file and change all the places
>>>>> where Camel requires the Spring feature (from Karaf) and replace it with
>>>>> the Spring 3.1.x bundles.
>>>>>
>>>>> Be leveraging the Karaf Spring features it's easier to have all the
>>>>> dependencies in sync, but it adds an (unnecessary) constraint.
>>>>> And if Karaf 2.2.6 also use Spring 3.1.x, it doesn't fix this
>>>>> constraint...
>>>>>
>>>>> I'm interested in your all opinions.
>>>>>
>>>>> Best,
>>>>> Christian
>>>>>
>>>>>
>>>>> On Sat, Mar 10, 2012 at 5:01 PM, wanggang1<wa...@gmail.com> wrote:
>>>>>
>>>>>> Hi Stefan,
>>>>>>
>>>>>> When I used Camel 2.9.1, I saw Maven pulled down Spring 3.0.7-RELEASE
>>>>>> as
>>>>>> dependencies. When you added Spring 3.1 explicitly, did it then cause
>>>>>> any
>>>>>> conflict?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>>
>>>>>> http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5553179.html
>>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Camel and Spring 3.1
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I dont think this is a road we want to go down. In the old days we had
a spring 2.x and 3.0 features.xml file and it was a pain to maintain.
We only had to do this because due limitations in features in Karaf
back then. Now Karaf is improved and IMHO not needed to be released
and maintained by Camel project. What about CXF and other libraries
where people use in Karaf and they want to use Spring 3.1.
The camel components is by default compatible with Spring 3.0 and 3.1.
There is only one API change in the Spring Test Framework which is
incompatible between spring 3.0 and 3.1, reported by Christian.
But the camel-test-spring is not an OSGi bundle, and neither available
as a feature. So people should be able to install any
of the Camel features and use Spring 3.1.
That said, its not a combo we have tested thoroughly and the default
unit tests / integration tests, is using Spring 3.0.
But there is so many combinations of frameworks and 3rd party JARs
that people can use. We cannot test all combos.
So in my mind upgrading Spring in Karaf should be something people can
do, and the install any features / bundle that can
use this Spring version range.
All the Camel bundles that uses Spring have (3,4] in the range.
On Mon, Mar 12, 2012 at 2:55 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Claus,
>
> a "possibility" is to provide both Spring features version on Karaf 2.2.x.
>
> spring-3.0
>
> and
>
> spring-3.1
>
> It will allow us to "upgrade" Camel to support Spring 3.1 without waiting
> for Karaf 3.0.0.
>
> My 0.02$ ;)
>
> Regards
> JB
>
>
> On 03/11/2012 09:29 AM, Claus Ibsen wrote:
>>
>> Hi
>>
>> The irony is that an OSGi environment should be very modular and dynamic.
>> So upgrading Spring to 3.1, ought to be a use-case that should be
>> straight forward.
>>
>> The camel spring bundles have the spring version range [3.0,4.0) I
>> think, so they ought to be not limited to only 3.0.x.
>> I just checked the pom.xml in camel-spring has:
>> org.springframework.*;version="[3,4)",
>>
>>
>> On Sat, Mar 10, 2012 at 8:12 PM, Christian Müller
>> <ch...@gmail.com> wrote:
>>>
>>> I will add a spring-3.1 profile in my local workspace and see how it
>>> works
>>> (we could have a Spring 3.0.x and a Spring 3.1.x build). If this works I
>>> will move on and see how we do it for Karaf...
>>>
>>> Best,
>>> Christian
>>>
>>> On Sat, Mar 10, 2012 at 7:07 PM, Christian Müller<
>>> christian.mueller@gmail.com> wrote:
>>>
>>>> Maybe Stefan don't use the Camel provided features and install all the
>>>> needed bundles by its own or build its own feature file which use Spring
>>>> 3.1.x. That's possible but not recommended, because Camel 2.9.1 is
>>>> "only"
>>>> tested with Spring 3.0.x. This means it could work, but you cannot be
>>>> sure.
>>>> It's also possible that may camel-jpa works with Spring 3.1.x but
>>>> another
>>>> Camel component e.g. camel-jms/camel-activemq will fail with Spring
>>>> 3.1.x.
>>>>
>>>> In the past we already did support two different versions of Spring
>>>> (2.5.x
>>>> and 3.0.x). I'm not sure were we was happy with this solution (two
>>>> different feature files in Camel)...
>>>>
>>>> Loud thinking:
>>>> At the moment I'm not sure if it's really the best idea that Camel reuse
>>>> the Karaf provided Spring feature (may be this is also the case for
>>>> other
>>>> features). The reason is the following:
>>>> Imagine you run Karaf 2.2.x (plain Karaf or ServiceMix) and you don't
>>>> want
>>>> to upgrade your container infrastructure multiple times per year (this
>>>> is
>>>> the case for my company). When you upgrade your Camel based application
>>>> to
>>>> a Camel version which use Spring 3.1.x, you have to:
>>>> - upgrade your container infrastructure also (Karaf)
>>>> - or change the Camel provided feature file and change all the places
>>>> where Camel requires the Spring feature (from Karaf) and replace it with
>>>> the Spring 3.1.x bundles.
>>>>
>>>> Be leveraging the Karaf Spring features it's easier to have all the
>>>> dependencies in sync, but it adds an (unnecessary) constraint.
>>>> And if Karaf 2.2.6 also use Spring 3.1.x, it doesn't fix this
>>>> constraint...
>>>>
>>>> I'm interested in your all opinions.
>>>>
>>>> Best,
>>>> Christian
>>>>
>>>>
>>>> On Sat, Mar 10, 2012 at 5:01 PM, wanggang1<wa...@gmail.com> wrote:
>>>>
>>>>> Hi Stefan,
>>>>>
>>>>> When I used Camel 2.9.1, I saw Maven pulled down Spring 3.0.7-RELEASE
>>>>> as
>>>>> dependencies. When you added Spring 3.1 explicitly, did it then cause
>>>>> any
>>>>> conflict?
>>>>>
>>>>> Thanks
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>> http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5553179.html
>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>>
>>>>
>>>>
>>
>>
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
--
Claus Ibsen
-----------------
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/
Re: Camel and Spring 3.1
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Claus,
a "possibility" is to provide both Spring features version on Karaf 2.2.x.
spring-3.0
and
spring-3.1
It will allow us to "upgrade" Camel to support Spring 3.1 without
waiting for Karaf 3.0.0.
My 0.02$ ;)
Regards
JB
On 03/11/2012 09:29 AM, Claus Ibsen wrote:
> Hi
>
> The irony is that an OSGi environment should be very modular and dynamic.
> So upgrading Spring to 3.1, ought to be a use-case that should be
> straight forward.
>
> The camel spring bundles have the spring version range [3.0,4.0) I
> think, so they ought to be not limited to only 3.0.x.
> I just checked the pom.xml in camel-spring has:
> org.springframework.*;version="[3,4)",
>
>
> On Sat, Mar 10, 2012 at 8:12 PM, Christian Müller
> <ch...@gmail.com> wrote:
>> I will add a spring-3.1 profile in my local workspace and see how it works
>> (we could have a Spring 3.0.x and a Spring 3.1.x build). If this works I
>> will move on and see how we do it for Karaf...
>>
>> Best,
>> Christian
>>
>> On Sat, Mar 10, 2012 at 7:07 PM, Christian Müller<
>> christian.mueller@gmail.com> wrote:
>>
>>> Maybe Stefan don't use the Camel provided features and install all the
>>> needed bundles by its own or build its own feature file which use Spring
>>> 3.1.x. That's possible but not recommended, because Camel 2.9.1 is "only"
>>> tested with Spring 3.0.x. This means it could work, but you cannot be sure.
>>> It's also possible that may camel-jpa works with Spring 3.1.x but another
>>> Camel component e.g. camel-jms/camel-activemq will fail with Spring 3.1.x.
>>>
>>> In the past we already did support two different versions of Spring (2.5.x
>>> and 3.0.x). I'm not sure were we was happy with this solution (two
>>> different feature files in Camel)...
>>>
>>> Loud thinking:
>>> At the moment I'm not sure if it's really the best idea that Camel reuse
>>> the Karaf provided Spring feature (may be this is also the case for other
>>> features). The reason is the following:
>>> Imagine you run Karaf 2.2.x (plain Karaf or ServiceMix) and you don't want
>>> to upgrade your container infrastructure multiple times per year (this is
>>> the case for my company). When you upgrade your Camel based application to
>>> a Camel version which use Spring 3.1.x, you have to:
>>> - upgrade your container infrastructure also (Karaf)
>>> - or change the Camel provided feature file and change all the places
>>> where Camel requires the Spring feature (from Karaf) and replace it with
>>> the Spring 3.1.x bundles.
>>>
>>> Be leveraging the Karaf Spring features it's easier to have all the
>>> dependencies in sync, but it adds an (unnecessary) constraint.
>>> And if Karaf 2.2.6 also use Spring 3.1.x, it doesn't fix this constraint...
>>>
>>> I'm interested in your all opinions.
>>>
>>> Best,
>>> Christian
>>>
>>>
>>> On Sat, Mar 10, 2012 at 5:01 PM, wanggang1<wa...@gmail.com> wrote:
>>>
>>>> Hi Stefan,
>>>>
>>>> When I used Camel 2.9.1, I saw Maven pulled down Spring 3.0.7-RELEASE as
>>>> dependencies. When you added Spring 3.1 explicitly, did it then cause any
>>>> conflict?
>>>>
>>>> Thanks
>>>>
>>>> --
>>>> View this message in context:
>>>> http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5553179.html
>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>
>>>
>>>
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Camel and Spring 3.1
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
The irony is that an OSGi environment should be very modular and dynamic.
So upgrading Spring to 3.1, ought to be a use-case that should be
straight forward.
The camel spring bundles have the spring version range [3.0,4.0) I
think, so they ought to be not limited to only 3.0.x.
I just checked the pom.xml in camel-spring has:
org.springframework.*;version="[3,4)",
On Sat, Mar 10, 2012 at 8:12 PM, Christian Müller
<ch...@gmail.com> wrote:
> I will add a spring-3.1 profile in my local workspace and see how it works
> (we could have a Spring 3.0.x and a Spring 3.1.x build). If this works I
> will move on and see how we do it for Karaf...
>
> Best,
> Christian
>
> On Sat, Mar 10, 2012 at 7:07 PM, Christian Müller <
> christian.mueller@gmail.com> wrote:
>
>> Maybe Stefan don't use the Camel provided features and install all the
>> needed bundles by its own or build its own feature file which use Spring
>> 3.1.x. That's possible but not recommended, because Camel 2.9.1 is "only"
>> tested with Spring 3.0.x. This means it could work, but you cannot be sure.
>> It's also possible that may camel-jpa works with Spring 3.1.x but another
>> Camel component e.g. camel-jms/camel-activemq will fail with Spring 3.1.x.
>>
>> In the past we already did support two different versions of Spring (2.5.x
>> and 3.0.x). I'm not sure were we was happy with this solution (two
>> different feature files in Camel)...
>>
>> Loud thinking:
>> At the moment I'm not sure if it's really the best idea that Camel reuse
>> the Karaf provided Spring feature (may be this is also the case for other
>> features). The reason is the following:
>> Imagine you run Karaf 2.2.x (plain Karaf or ServiceMix) and you don't want
>> to upgrade your container infrastructure multiple times per year (this is
>> the case for my company). When you upgrade your Camel based application to
>> a Camel version which use Spring 3.1.x, you have to:
>> - upgrade your container infrastructure also (Karaf)
>> - or change the Camel provided feature file and change all the places
>> where Camel requires the Spring feature (from Karaf) and replace it with
>> the Spring 3.1.x bundles.
>>
>> Be leveraging the Karaf Spring features it's easier to have all the
>> dependencies in sync, but it adds an (unnecessary) constraint.
>> And if Karaf 2.2.6 also use Spring 3.1.x, it doesn't fix this constraint...
>>
>> I'm interested in your all opinions.
>>
>> Best,
>> Christian
>>
>>
>> On Sat, Mar 10, 2012 at 5:01 PM, wanggang1 <wa...@gmail.com> wrote:
>>
>>> Hi Stefan,
>>>
>>> When I used Camel 2.9.1, I saw Maven pulled down Spring 3.0.7-RELEASE as
>>> dependencies. When you added Spring 3.1 explicitly, did it then cause any
>>> conflict?
>>>
>>> Thanks
>>>
>>> --
>>> View this message in context:
>>> http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5553179.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>
>>
--
Claus Ibsen
-----------------
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/
Re: Camel and Spring 3.1
Posted by Christian Müller <ch...@gmail.com>.
I will add a spring-3.1 profile in my local workspace and see how it works
(we could have a Spring 3.0.x and a Spring 3.1.x build). If this works I
will move on and see how we do it for Karaf...
Best,
Christian
On Sat, Mar 10, 2012 at 7:07 PM, Christian Müller <
christian.mueller@gmail.com> wrote:
> Maybe Stefan don't use the Camel provided features and install all the
> needed bundles by its own or build its own feature file which use Spring
> 3.1.x. That's possible but not recommended, because Camel 2.9.1 is "only"
> tested with Spring 3.0.x. This means it could work, but you cannot be sure.
> It's also possible that may camel-jpa works with Spring 3.1.x but another
> Camel component e.g. camel-jms/camel-activemq will fail with Spring 3.1.x.
>
> In the past we already did support two different versions of Spring (2.5.x
> and 3.0.x). I'm not sure were we was happy with this solution (two
> different feature files in Camel)...
>
> Loud thinking:
> At the moment I'm not sure if it's really the best idea that Camel reuse
> the Karaf provided Spring feature (may be this is also the case for other
> features). The reason is the following:
> Imagine you run Karaf 2.2.x (plain Karaf or ServiceMix) and you don't want
> to upgrade your container infrastructure multiple times per year (this is
> the case for my company). When you upgrade your Camel based application to
> a Camel version which use Spring 3.1.x, you have to:
> - upgrade your container infrastructure also (Karaf)
> - or change the Camel provided feature file and change all the places
> where Camel requires the Spring feature (from Karaf) and replace it with
> the Spring 3.1.x bundles.
>
> Be leveraging the Karaf Spring features it's easier to have all the
> dependencies in sync, but it adds an (unnecessary) constraint.
> And if Karaf 2.2.6 also use Spring 3.1.x, it doesn't fix this constraint...
>
> I'm interested in your all opinions.
>
> Best,
> Christian
>
>
> On Sat, Mar 10, 2012 at 5:01 PM, wanggang1 <wa...@gmail.com> wrote:
>
>> Hi Stefan,
>>
>> When I used Camel 2.9.1, I saw Maven pulled down Spring 3.0.7-RELEASE as
>> dependencies. When you added Spring 3.1 explicitly, did it then cause any
>> conflict?
>>
>> Thanks
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5553179.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>
>
Re: Camel and Spring 3.1
Posted by Christian Müller <ch...@gmail.com>.
Maybe Stefan don't use the Camel provided features and install all the
needed bundles by its own or build its own feature file which use Spring
3.1.x. That's possible but not recommended, because Camel 2.9.1 is "only"
tested with Spring 3.0.x. This means it could work, but you cannot be sure.
It's also possible that may camel-jpa works with Spring 3.1.x but another
Camel component e.g. camel-jms/camel-activemq will fail with Spring 3.1.x.
In the past we already did support two different versions of Spring (2.5.x
and 3.0.x). I'm not sure were we was happy with this solution (two
different feature files in Camel)...
Loud thinking:
At the moment I'm not sure if it's really the best idea that Camel reuse
the Karaf provided Spring feature (may be this is also the case for other
features). The reason is the following:
Imagine you run Karaf 2.2.x (plain Karaf or ServiceMix) and you don't want
to upgrade your container infrastructure multiple times per year (this is
the case for my company). When you upgrade your Camel based application to
a Camel version which use Spring 3.1.x, you have to:
- upgrade your container infrastructure also (Karaf)
- or change the Camel provided feature file and change all the places where
Camel requires the Spring feature (from Karaf) and replace it with the
Spring 3.1.x bundles.
Be leveraging the Karaf Spring features it's easier to have all the
dependencies in sync, but it adds an (unnecessary) constraint.
And if Karaf 2.2.6 also use Spring 3.1.x, it doesn't fix this constraint...
I'm interested in your all opinions.
Best,
Christian
On Sat, Mar 10, 2012 at 5:01 PM, wanggang1 <wa...@gmail.com> wrote:
> Hi Stefan,
>
> When I used Camel 2.9.1, I saw Maven pulled down Spring 3.0.7-RELEASE as
> dependencies. When you added Spring 3.1 explicitly, did it then cause any
> conflict?
>
> Thanks
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5553179.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: Camel and Spring 3.1
Posted by wanggang1 <wa...@gmail.com>.
Hi Stefan,
When I used Camel 2.9.1, I saw Maven pulled down Spring 3.0.7-RELEASE as
dependencies. When you added Spring 3.1 explicitly, did it then cause any
conflict?
Thanks
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5553179.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel and Spring 3.1
Posted by Stefan Eder <st...@ebuconnect.de>.
Spring ORM with Hibernate 4 requires Spring 3.1.
[org.springframework.orm.hibernate4.*]
I use Camel 2.9 withSpring 3.1 (and Hibernate 4) and had no problems yet.
- Stefan
On 09.03.2012 22:54, Christian Müller wrote:
> Is there a special feature you are looking for?
>
> There is an issue [CAMEL-4778|
> https://issues.apache.org/jira/browse/CAMEL-4778] for this upgrade. The
> challenge here is, Karaf 2.2.x is using Spring 3.0.x, Karaf 3.0.0 is using
> Spring 3.1.x. Because the Camel feature file leverage on the Karaf Spring
> feature, we have to make sure it works with Spring 3.0.x *AND* Spring 3.1.x
> - if possible. If not, we should postpone this upgrade to Camel 3.0.0.
>
> Best,
> Christian
>
>
> On Fri, Mar 9, 2012 at 2:49 PM, wanggang1<wa...@gmail.com> wrote:
>
>> Hi,
>>
>> What is the road map for Camel with regard to Spring 3.1?
>>
>> Thanks
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5550625.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
Re: Camel and Spring 3.1
Posted by wanggang1 <wa...@gmail.com>.
I'm looking at using @Profile for setting up routes for our different
environments. Thanks.
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5553171.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel and Spring 3.1
Posted by Christian Müller <ch...@gmail.com>.
Is there a special feature you are looking for?
There is an issue [CAMEL-4778|
https://issues.apache.org/jira/browse/CAMEL-4778] for this upgrade. The
challenge here is, Karaf 2.2.x is using Spring 3.0.x, Karaf 3.0.0 is using
Spring 3.1.x. Because the Camel feature file leverage on the Karaf Spring
feature, we have to make sure it works with Spring 3.0.x *AND* Spring 3.1.x
- if possible. If not, we should postpone this upgrade to Camel 3.0.0.
Best,
Christian
On Fri, Mar 9, 2012 at 2:49 PM, wanggang1 <wa...@gmail.com> wrote:
> Hi,
>
> What is the road map for Camel with regard to Spring 3.1?
>
> Thanks
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Camel-and-Spring-3-1-tp5550625p5550625.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>