You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by metatech <me...@gmail.com> on 2012/01/19 15:39:33 UTC
Re: Camel under OSGi without Spring et al.
Hi,
My previous conclusion was not correct.
The Camel initialization happens indeed in the "addingBundle" method, but is
called from a SynchronousBundleListener, in the same thread that activates
the bundle, and there is only one thread ("FelixStartlevel") that activates
all feature bundles, so it should it should fully initialized.
However, when the problem happens, the following error is logged :
2012-01-19 09:35:41,655 | INFO | ExtenderThread-5 | |
CamelNamespaceHandler | OSGi environment not detected.
This can happen if the OSGi activator of the bundle "camel-spring" was not
executed before the Camel context is starting. In SMX 4.4, camel-spring is
at start-level 50, and applications are at start-level 60, so the activator
is meant to be completed before applications are starting.
However, during the first start-up, or when the bundle cache is cleaned up,
the bundles delivered as Karaf "features" are installed in parallel with the
deployment of applications in the "deploy" directory. This can explain that
the camel-spring (not yet installed at level 50) is executed after some
applications are starting.
The only solution I can think of is that the bundle cache should be built in
a first phase, then the bundle are started in a second phase.
Regards,
metatech
metatech wrote
>
> However, the Camel initialization is not finished yet, it is performed in
> the "addingBundle" method, which registers Camel components, languages,
> type converters, ...
>
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-under-OSGi-without-Spring-et-al-tp4507473p5157820.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel under OSGi without Spring et al.
Posted by Guillaume Nodet <gn...@gmail.com>.
That's why you should not try to use Spring-DM. I strongly suggest
switching to blueprint if you plan to deploy routes in OSGi.
The start level won't even fix the spring problems iirc, or at least
not at 100%, mostly because things happen asynchronously, so even
after subsequent startup, spring won't wait for the handlers. I
suppose your way (using a programmatic wait) might work, but I'm not
sure you can even know when the handler will be ready.
Though I haven't really worked on Spring-DM since a long time.
FWIW, you'll find a detailed post at
http://gnodet.blogspot.com/2010/03/spring-dm-aries-blueprint-and-custom.html
On Fri, Jan 20, 2012 at 16:00, metatech <me...@gmail.com> wrote:
> Hi,
>
> I agree with both of you, start-levels should be avoided.
> However, in this case, the application is defined with a Spring XML using
> Camel routes, so no Java beans are present in the bundle. The application
> must wait until the Camel namespace is properly registered in the
> camel-spring OSGi activator. The namespace must be available before the
> Spring XML file is parsed (which constructs the Spring bean definitions).
> This cannot be done with a "osgi:reference" nor a "depends-on" dependency,
> because they happen too late. Start levels are not reliable on the first
> start-up, but they are reliable for the next start-ups. Only a programmatic
> call in an OSGi activator for the application can wait for the camel-spring
> bundle be fully activated, but it is a bit cumbersome.
>
> Regards,
>
> metatech
>
>
> Start-level can't really be trusted, especially if you use blueprint
> for example, which does actually start the blueprint stuff
> asynchronously.
>
> On Thu, Jan 19, 2012 at 15:49, Donald Whytock <dwhytock@> wrote:
>> It may be a matter of personal taste, but I disagree with reliance on
>> start levels. It should be more reliable to use a BundleListener to
>> track whether a particular bundle has loaded, or a ServiceTracker with
>> the bundle being watched for launching a "here I am" service when
>> initialization is complete.
>>
>> Don
>>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Camel-under-OSGi-without-Spring-et-al-tp4507473p5160645.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Re: Camel under OSGi without Spring et al.
Posted by metatech <me...@gmail.com>.
Hi,
I agree with both of you, start-levels should be avoided.
However, in this case, the application is defined with a Spring XML using
Camel routes, so no Java beans are present in the bundle. The application
must wait until the Camel namespace is properly registered in the
camel-spring OSGi activator. The namespace must be available before the
Spring XML file is parsed (which constructs the Spring bean definitions).
This cannot be done with a "osgi:reference" nor a "depends-on" dependency,
because they happen too late. Start levels are not reliable on the first
start-up, but they are reliable for the next start-ups. Only a programmatic
call in an OSGi activator for the application can wait for the camel-spring
bundle be fully activated, but it is a bit cumbersome.
Regards,
metatech
Start-level can't really be trusted, especially if you use blueprint
for example, which does actually start the blueprint stuff
asynchronously.
On Thu, Jan 19, 2012 at 15:49, Donald Whytock <dwhytock@> wrote:
> It may be a matter of personal taste, but I disagree with reliance on
> start levels. It should be more reliable to use a BundleListener to
> track whether a particular bundle has loaded, or a ServiceTracker with
> the bundle being watched for launching a "here I am" service when
> initialization is complete.
>
> Don
>
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-under-OSGi-without-Spring-et-al-tp4507473p5160645.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel under OSGi without Spring et al.
Posted by Guillaume Nodet <gn...@gmail.com>.
Start-level can't really be trusted, especially if you use blueprint
for example, which does actually start the blueprint stuff
asynchronously.
On Thu, Jan 19, 2012 at 15:49, Donald Whytock <dw...@gmail.com> wrote:
> It may be a matter of personal taste, but I disagree with reliance on
> start levels. It should be more reliable to use a BundleListener to
> track whether a particular bundle has loaded, or a ServiceTracker with
> the bundle being watched for launching a "here I am" service when
> initialization is complete.
>
> Don
>
> On Thu, Jan 19, 2012 at 9:39 AM, metatech <me...@gmail.com> wrote:
>> Hi,
>>
>> My previous conclusion was not correct.
>> The Camel initialization happens indeed in the "addingBundle" method, but is
>> called from a SynchronousBundleListener, in the same thread that activates
>> the bundle, and there is only one thread ("FelixStartlevel") that activates
>> all feature bundles, so it should it should fully initialized.
>>
>> However, when the problem happens, the following error is logged :
>> 2012-01-19 09:35:41,655 | INFO | ExtenderThread-5 | |
>> CamelNamespaceHandler | OSGi environment not detected.
>>
>> This can happen if the OSGi activator of the bundle "camel-spring" was not
>> executed before the Camel context is starting. In SMX 4.4, camel-spring is
>> at start-level 50, and applications are at start-level 60, so the activator
>> is meant to be completed before applications are starting.
>>
>> However, during the first start-up, or when the bundle cache is cleaned up,
>> the bundles delivered as Karaf "features" are installed in parallel with the
>> deployment of applications in the "deploy" directory. This can explain that
>> the camel-spring (not yet installed at level 50) is executed after some
>> applications are starting.
>>
>> The only solution I can think of is that the bundle cache should be built in
>> a first phase, then the bundle are started in a second phase.
>>
>> Regards,
>>
>> metatech
>>
>>
>>
>>
>> metatech wrote
>>>
>>> However, the Camel initialization is not finished yet, it is performed in
>>> the "addingBundle" method, which registers Camel components, languages,
>>> type converters, ...
>>>
>>
>>
>> --
>> View this message in context: http://camel.465427.n5.nabble.com/Camel-under-OSGi-without-Spring-et-al-tp4507473p5157820.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Re: Camel under OSGi without Spring et al.
Posted by Donald Whytock <dw...@gmail.com>.
It may be a matter of personal taste, but I disagree with reliance on
start levels. It should be more reliable to use a BundleListener to
track whether a particular bundle has loaded, or a ServiceTracker with
the bundle being watched for launching a "here I am" service when
initialization is complete.
Don
On Thu, Jan 19, 2012 at 9:39 AM, metatech <me...@gmail.com> wrote:
> Hi,
>
> My previous conclusion was not correct.
> The Camel initialization happens indeed in the "addingBundle" method, but is
> called from a SynchronousBundleListener, in the same thread that activates
> the bundle, and there is only one thread ("FelixStartlevel") that activates
> all feature bundles, so it should it should fully initialized.
>
> However, when the problem happens, the following error is logged :
> 2012-01-19 09:35:41,655 | INFO | ExtenderThread-5 | |
> CamelNamespaceHandler | OSGi environment not detected.
>
> This can happen if the OSGi activator of the bundle "camel-spring" was not
> executed before the Camel context is starting. In SMX 4.4, camel-spring is
> at start-level 50, and applications are at start-level 60, so the activator
> is meant to be completed before applications are starting.
>
> However, during the first start-up, or when the bundle cache is cleaned up,
> the bundles delivered as Karaf "features" are installed in parallel with the
> deployment of applications in the "deploy" directory. This can explain that
> the camel-spring (not yet installed at level 50) is executed after some
> applications are starting.
>
> The only solution I can think of is that the bundle cache should be built in
> a first phase, then the bundle are started in a second phase.
>
> Regards,
>
> metatech
>
>
>
>
> metatech wrote
>>
>> However, the Camel initialization is not finished yet, it is performed in
>> the "addingBundle" method, which registers Camel components, languages,
>> type converters, ...
>>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Camel-under-OSGi-without-Spring-et-al-tp4507473p5157820.html
> Sent from the Camel - Users mailing list archive at Nabble.com.