It seems to be the issue discussed at http://fernandoribeiro.eti.br/2011/01/10/issues-with-routes-in-progress-fuse-4-2/. Let me know if it the case. Thanks.
On Wed, Mar 30, 2011 at 6:31 PM, Donald Whytock <[email protected]> wrote: > Okay...I bundled camel-core-osgi separately, created a bundle that > instantiates OsgiDefaultCamelContext on activation then registers > ContextUtil as a service to provide the instance as a singleton, and > created another bundle called Sender that uses a ServiceTracker to > wait until ContextUtil is registered before fetching a CamelContext > from it. Sender creates endpoints for two seda queues. > > If I activate both ContextUtil and Sender manually, after starting > Felix, it works, regardless of the order I activate them in. > > If I allow Felix to automatically activate either one and then > manually activate the other, it works, regardless of which is > automatic and which is manual. > > If I allow Felix to automatically activate both, I get a stacktrace, > I'm guessing because there's a bundle that has to activate before > Sender, which ContextUtil should probably wait for before registering: > > org.apache.camel.ResolveEndpointFailedException: Failed to resolve > endpoint: seda://sender due to: No component found with scheme: seda > at > org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:457) > at > org.chatterbot.sender.SenderActivator$SenderServiceImpl.camelStart(SenderActivator.java:180) > at > org.chatterbot.sender.SenderActivator$SenderServiceImpl$CamelTracker.start(SenderActivator.java:128) > at > org.chatterbot.camel.AbstractCamelTracker$CamelTracker.addingService(AbstractCamelTracker.java:45) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) > at > org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) > at > org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184) > at > org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:339) > at > org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:273) > at > org.chatterbot.camel.AbstractCamelTracker.camelTrack(AbstractCamelTracker.java:30) > at > org.chatterbot.sender.SenderActivator$SenderServiceImpl.start(SenderActivator.java:167) > at > org.chatterbot.servicefactory.GenericActivator$GenericFactoryImpl.makeService(GenericActivator.java:173) > at > org.chatterbot.servicefactory.GenericActivator$GenericFactoryImpl.makeServices(GenericActivator.java:157) > at > org.chatterbot.servicefactory.GenericActivator.startFactory(GenericActivator.java:122) > at > org.chatterbot.servicefactory.GenericActivator.start(GenericActivator.java:107) > at > org.chatterbot.sender.SenderActivator.start(SenderActivator.java:76) > at > org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:629) > at org.apache.felix.framework.Felix.activateBundle(Felix.java:1835) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1752) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1156) > at > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) > at java.lang.Thread.run(Unknown Source) > > Any ideas? > > Don > > On Tue, Mar 29, 2011 at 3:13 PM, Fernando Ribeiro > <[email protected]> wrote: > > I'd think it doesn't get any easier than having both bundles depending on > > the third, isn't it? Thanks. > > > > On Tue, Mar 29, 2011 at 4:11 PM, Claus Ibsen <[email protected]> > wrote: > > > >> On Tuesday, March 29, 2011, Fernando Ribeiro > >> <[email protected]> wrote: > >> > Out of curiosity, did I get it right that the code is going to > continue > >> in > >> > the camel-spring and camel-blueprint even when the camel-core-osgi is > >> there? > >> > If so, why? Thanks. > >> > > >> > >> This allow us to easily have common osgi code to share for spring and > >> blueprint. > >> > >> > >> > On Tue, Mar 29, 2011 at 2:52 AM, Willem Jiang <[email protected] > >> >wrote: > >> > > >> >> It's harmless to provide the bundle of camel-core-osgi in camel. > >> >> I just created a JIRA[1] of it, we will provide a bundle of > >> camel-core-osgi > >> >> in Camel 2.8.0. > >> >> > >> >> [1]https://issues.apache.org/jira/browse/CAMEL-3814 > >> >> > >> >> Willem > >> >> > >> >> On 3/29/11 1:17 PM, Donald Whytock wrote: > >> >> > >> >>> Thanks, I'll try that. > >> >>> > >> >>> Shall I assume this is going to be the standard architecture? As > in, > >> >>> if/when there's a 2.8, I should expect to need to re-bundle > >> >>> camel-core-osgi again? > >> >>> > >> >>> Don > >> >>> > >> >>> On Mon, Mar 28, 2011 at 11:10 PM, Willem Jiang< > [email protected]> > >> >>> wrote: > >> >>> > >> >>>> As we shipped the camel-spring and camel-blueprint at the same > time, > >> so > >> >>>> the > >> >>>> org.apache.camel.core.osgi is not exported as public class. > >> >>>> The reason that we don't create another bundle of camel-core-osgi, > is > >> >>>> camel-spring bundle detect OSGi and no-OSGi environment rightly. > Which > >> >>>> means > >> >>>> we could let camel-spring supports OSGi and no-OSGi platform at the > >> same > >> >>>> time. > >> >>>> > >> >>>> In most case, customer doesn't want to use the OSGi without any > help > >> of > >> >>>> spring-dm or blueprint. > >> >>>> > >> >>>> If you want to create OSGiDefaultCamelContext yourself, you can > wrap > >> the > >> >>>> camel-core-osgi bundle yourself. > >> >>>> > >> >>>> Willem > >> >>>> > >> >>>> On 3/29/11 6:01 AM, Donald Whytock wrote: > >> >>>> > >> >>>>> > >> >>>>> Okay...added camel-blueprint-2.7.0.jar, which required > >> >>>>> org.apache.aries.blueprint-0.3.jar, which required > >> >>>>> org.apache.aries.proxy-0.3.jar, which required > >> >>>>> org.apache.aries.util-0.3.jar, asm-3.3.1.jar and > >> >>>>> org.apache.felix.configadmin-1.0.4.jar. > >> >>>>> > >> >>>>> Tried creating an OsgiDefaultCamelContext, which worked in Eclipse > >> but > >> >>>>> not in Felix, since org.apache.camel.core.osgi isn't exported by > >> >>>>> camel-blueprint. > >> >>>>> > >> >>>>> Tried creating a BlueprintCamelContext, but that seems to want a > >> >>>>> BundleContext and a BlueprintContainer. I can get the > BundleContext > >> >>>>> easily enough, but where do I get the BlueprintContainer? > >> >>>>> > >> >>>>> Or am I going about this the wrong way? > >> >>>>> > >> >>>>> And yes, I'd rather do this in Java and not in XML. > >> >>>>> > >> >>>>> Don > >> >>>>> > >> >>>>> On Fri, Mar 25, 2011 at 3:05 PM, Scott England-Sullivan > >> >>>>> <[email protected]> wrote: > >> >>>>> > >> >>>>>> > >> >>>>>> If a project doesn't use Spring or Blueprint how do you create a > >> >>>>>> CamelContext in an OSGi container programmatically? > >> >>>>>> > >> >>>>>> > >> >>>>>> Thanks, > >> >>>>>> Scott > >> >>>>>> > >> >>>>>> Scott England-Sullivan > >> >>>>>> C. (217) 390-3058 > >> >>>>>> H. (952) 440-4568 > >> >>>>>> > >> >>>>>> Sent from my iPhone > >> >>>>>> > >> >>>>>> On Mar 25, 2011, at 1:05 PM, Claus Ibsen<[email protected]> > >> >>>>>> wrote: > >> >>>>>> > >> >>>>>> On Fri, Mar 25, 2011 at 3:52 PM, Donald Whytock< > [email protected] > >> > > >> >>>>>>> wrote: > >> >>>>>>> > >> >>>>>>>> > >> >>>>>>>> Okay. Where is the OSGi version? Is that in a different jar? > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>> Yes > >> >>>>>>> > >> >>>>>>> camel-spring if using spring-dm > >> >>>>>>> camel-blueprint if using blueprint > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> -- > >> >>>>>>> Claus Ibsen > >> >>>>>> > >> > >> -- > >> Claus Ibsen > >> ----------------- > >> FuseSource > >> Email: [email protected] > >> Web: http://fusesource.com > >> Twitter: davsclaus > >> Blog: http://davsclaus.blogspot.com/ > >> Author of Camel in Action: http://www.manning.com/ibsen/ > >> > > >
