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
<webmas...@fernandoribeiro.eti.br> 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 <claus.ib...@gmail.com> wrote:
>
>> On Tuesday, March 29, 2011, Fernando Ribeiro
>> <webmas...@fernandoribeiro.eti.br> 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 <willem.ji...@gmail.com
>> >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<willem.ji...@gmail.com>
>> >>>  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
>> >>>>> <sully6...@yahoo.com>    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<claus.ib...@gmail.com>
>> >>>>>>  wrote:
>> >>>>>>
>> >>>>>>  On Fri, Mar 25, 2011 at 3:52 PM, Donald Whytock<dwhyt...@gmail.com
>> >
>> >>>>>>>  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: cib...@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>>
>

Reply via email to