Hi Christian,

the issue is that Gemini has a different packaging and camel spring has a 
dependency which tries to load classes from spring OSGi when activator in 
manifest is triggered. Unfortunately it is not drop in replacement. :-(

I would suggest to update dependency in spring module or remove OSGi code to a 
new camel spring OSGi module and introduce a new camel Gemini blueprint module.

Benjamin



"Christian Müller" <christian.muel...@gmail.com> schrieb:

>If I understood you right, gemini-blueprint is the replacement of
>spring-dm. In this case, there is no need that both live together. I'm
>right?
>In this case, I don't understand what the issue is?
>
>Best,
>Christian
>
>On Wed, Oct 10, 2012 at 12:53 PM, Benjamin Graf
><benjamin.g...@gmx.net>wrote:
>
>> Hi everybody,
>>
>> I tried to implement a new camel component for gemini-blueprint. It
>seems
>> that both components spring-osgi and gemini-blueprint can not live
>both
>> together in camel. Since camel-spring needs spring-osgi if used in an
>osgi
>> environment. A replacement should really be considered.
>>
>> Any suggestions?
>>
>> Benjamin
>>
>> -------- Original-Nachricht --------
>> > Datum: Tue, 09 Oct 2012 11:19:36 +0200
>> > Von: "Benjamin Graf" <benjamin.g...@gmx.net>
>> > An: dev@camel.apache.org
>> > Betreff: Re: Dependencies of camel-spring
>>
>> > I give it a try it's two changed imports and one dependeny change
>in pom
>> > of camel-spring and everything works fine:
>> >
>> > import org.eclipse.gemini.blueprint.context.BundleContextAware;
>> > in
>> >
>>
>apache-camel-2.10.0\components\camel-spring\src\main\java\org\apache\camel\osgi\CamelContextFactoryBean.java
>> >
>>
>apache-camel-2.10.0\components\camel-spring\src\main\java\org\apache\camel\osgi\CamelNamespaceHandler.java
>> >
>> > and
>> >
>> >  <dependency>
>> >             <groupId>org.eclipse.gemini.blueprint</groupId>
>> >             <artifactId>gemini-blueprint-core</artifactId>
>> >             <version>1.0.2.RELEASE</version>
>> >             <optional>true</optional>
>> >             <exclusions>
>> >                 <exclusion>
>> >                     <groupId>org.springframework</groupId>
>> >                    
><artifactId>org.springframework.aop</artifactId>
>> >                 </exclusion>
>> >                 <exclusion>
>> >                     <groupId>org.springframework</groupId>
>> >                    
><artifactId>org.springframework.beans</artifactId>
>> >                 </exclusion>
>> >                 <exclusion>
>> >                     <groupId>org.springframework</groupId>
>> >                    
><artifactId>org.springframework.context</artifactId>
>> >                 </exclusion>
>> >                 <exclusion>
>> >                     <groupId>org.springframework</groupId>
>> >                    
><artifactId>org.springframework.core</artifactId>
>> >                 </exclusion>
>> >             </exclusions>
>> >         </dependency>
>> >
>> > in
>> > apache-camel-2.10.0\components\camel-spring\pom.xml
>> >
>> > In my opinion it worth changing it.
>> >
>> > -------- Original-Nachricht --------
>> > > Datum: Tue, 9 Oct 2012 11:03:50 +0200
>> > > Von: Claus Ibsen <claus.ib...@gmail.com>
>> > > An: dev@camel.apache.org
>> > > Betreff: Re: Dependencies of camel-spring
>> >
>> > > On Tue, Oct 9, 2012 at 10:08 AM, Benjamin Graf
><benjamin.g...@gmx.net>
>> > > wrote:
>> > > > Hi,
>> > > >
>> > > > does anybody knows why camel-spring still depends on
>spring-osgi?
>> This
>> > > bundle is gemini-blueprint since 2009 and won't be developed
>anymore.
>> > This
>> > > fact forces to use an old unsupported bundle if you like camel
>with
>> > spring
>> > > and OSGi. :-( I think it should change whether to create a new
>> > > camel-gemini-bluepint component.
>> > > >
>> > >
>> > > We love contributions, so you are welcome to work on a
>> > > camel-gemini-blueprint component.
>> > >
>> > > It would be a matter of doing something similar as we do in
>> > > camel-blueprint (aries) which builds on top of camel-core-osgi
>and
>> > > camel-core-xml.
>> > > Would need to implement a namespace handler, and the factory
>beans,
>> > > and i guess some other osgi quirks to get it integrated.
>> > >
>> > >
>> > >
>> > > > Regards,
>> > > > Benjamin
>> > >
>> > >
>> > >
>> > > --
>> > > Claus Ibsen
>> > > -----------------
>> > > Red Hat, Inc.
>> > > FuseSource is now part of Red Hat
>> > > Email: cib...@redhat.com
>> > > Web: http://fusesource.com
>> > > Twitter: davsclaus
>> > > Blog: http://davsclaus.com
>> > > Author of Camel in Action: http://www.manning.com/ibsen
>>
>
>
>
>--

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Reply via email to