camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From metatech <>
Subject Re: Camel under OSGi without Spring et al.
Date Fri, 20 Jan 2012 15:00:11 GMT

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.  



Start-level can't really be trusted, especially if you use blueprint
for example, which does actually start the blueprint stuff

On Thu, Jan 19, 2012 at 15:49, Donald Whytock &lt;dwhytock@&gt; 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:
Sent from the Camel - Users mailing list archive at

View raw message