You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Donald Whytock <dw...@gmail.com> on 2011/04/02 00:33:56 UTC

camel-core-osgi

I was able to build an app with OsgiDefaultCamelContext, but I had to
add a ServiceTracker to wait for
org.apache.camel.spi.TypeConverterLoader to be registered.  Before I
did that, my bundles were trying to create SEDA queues before
camel-core had finished loading.

If camel-core-osgi is going to be split into a separate bundle in 2.8,
I'd like to suggest adding a couple things:

- A service that supplies instances of OsgiDefaultCamelContext on
demand.  This gives applications a service to track before attempting
camel operations.

- An activator that does whatever service/bundle tracking is needed
before registering the service.  This isolates applications from
camel-core workings.

Thanks...

Don

Re: camel-core-osgi

Posted by Donald Whytock <dw...@gmail.com>.
Working with different service levels would work, but it would mean
every bundle that's dependent on Camel, or dependent on bundles that
are dependent on Camel, would need to be at the higher service level.
The Felix and OSGi groups seem to recommend against this approach;
they advocate being able to track bundles regardless of service level.

This is especially true since bundles can be swapped out at runtime.
While camel-core itself probably won't be, I could see someone testing
a new component and swapping in new versions of it over and over.  A
bundle dependent on that particular component would need to know when
the component was live.  Service level wouldn't provide that.

But all components go through TypeConverterLoader, right?  So before
I'm doing anything with an OsgiCamelContext I need to know that the
TypeConverterLoader service is live.  And since that's a condition
specific to Osgi, it seems like the responsibility for tracking
TypeConverterLoader should be in camel-core-osgi.  Perhaps tracked by,
yes, an OsgiDefaultCamelContextFactory service.

Though this raises an interesting question: Given TypeConverterLoader
is active, should there be some sort of ComponentTracker, tied to the
CamelContext, so that apps dependent on a component can know whether
or not to run?

On Tue, Apr 5, 2011 at 10:47 PM, Willem Jiang <wi...@gmail.com> wrote:
> On 4/2/11 6:33 AM, Donald Whytock wrote:
>>
>> I was able to build an app with OsgiDefaultCamelContext, but I had to
>> add a ServiceTracker to wait for
>> org.apache.camel.spi.TypeConverterLoader to be registered.  Before I
>> did that, my bundles were trying to create SEDA queues before
>> camel-core had finished loading.
>
> If you are setting your application system level great then the camel-core,
> you may work around that kind of issue.
>
>>
>> If camel-core-osgi is going to be split into a separate bundle in 2.8,
>> I'd like to suggest adding a couple things:
>>
>> - A service that supplies instances of OsgiDefaultCamelContext on
>> demand.  This gives applications a service to track before attempting
>> camel operations.
>
> Do you mean that you want an service which works as a
> OsgiDefaultCamelContext factory ?
>
>>
>> - An activator that does whatever service/bundle tracking is needed
>> before registering the service.  This isolates applications from
>> camel-core workings.
>
> As there are lots of camel-components which will be loaded from different
> bundle, even you can use the service tracker to wait the
> TypeConverterLoader, you can not make sure
>
> A better solution is the application bundle and camel component feature
> bundle started with different system level.
>
> May this blog[1] can give you some inspiration.
>
>>
>> Thanks...
>>
>> Don
>>
>
> [1]http://fernandoribeiro.eti.br/2011/01/10/issues-with-routes-in-progress-fuse-4-2/
>
> Willem
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog:    http://willemjiang.blogspot.com (English)
>         http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
>
> Connect at CamelOne May 24-26
> The Open Source Integration Conference
> http://camelone.com
>

Re: camel-core-osgi

Posted by Willem Jiang <wi...@gmail.com>.
On 4/2/11 6:33 AM, Donald Whytock wrote:
> I was able to build an app with OsgiDefaultCamelContext, but I had to
> add a ServiceTracker to wait for
> org.apache.camel.spi.TypeConverterLoader to be registered.  Before I
> did that, my bundles were trying to create SEDA queues before
> camel-core had finished loading.

If you are setting your application system level great then the 
camel-core, you may work around that kind of issue.

>
> If camel-core-osgi is going to be split into a separate bundle in 2.8,
> I'd like to suggest adding a couple things:
>
> - A service that supplies instances of OsgiDefaultCamelContext on
> demand.  This gives applications a service to track before attempting
> camel operations.

Do you mean that you want an service which works as a 
OsgiDefaultCamelContext factory ?

>
> - An activator that does whatever service/bundle tracking is needed
> before registering the service.  This isolates applications from
> camel-core workings.
As there are lots of camel-components which will be loaded from 
different bundle, even you can use the service tracker to wait the 
TypeConverterLoader, you can not make sure

A better solution is the application bundle and camel component feature 
bundle started with different system level.

May this blog[1] can give you some inspiration.

>
> Thanks...
>
> Don
>

[1]http://fernandoribeiro.eti.br/2011/01/10/issues-with-routes-in-progress-fuse-4-2/

Willem

-- 
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: willemjiang

Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com