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 <metatec...@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
