As usual, the answer occurred to me moments after I pressed 'send'. I
neglected to specify a version for when adding it
to the system bundle export list.

On Sun, Sep 18, 2016 at 3:18 PM, Neil Bartlett <> wrote:
> This should work, but without a code sample it’s impossible to say what might 
> be going wrong.
> The usual pattern would be:
> 1. Init and start the framework
> 2. Install the bundles, including configadmin
> 3. Create and open your tracker
> 4. Start the bundles
> 5. Enter framework.waitForStop(), where you will remain.
> Config Admin will likely publish itself synchronously in step 4, and you will 
> get a callback on the tracker. Or it might publish the service asynchronously 
> later, which is also okay.
> Neil
>> On 18 Sep 2016, at 19:53, Benson Margulies <> wrote:
>> My current task is to set up a Felix framework behind an API. To get
>> actual work done, there are some interfaces in packages on the system
>> bundle that are published by bundles of mine, and then the code
>> 'outside' the framework obtains them.
>> For the main service I created, this all works find with a
>> ServiceTracker as the tool for waiting for the code inside the
>> container to get around (via SCR) to publishing the service I need.
>> Next, I decided that, as part of my bootstrap process, it would make
>> sense for me to push some configuration into ConfigurationAdmin. So, I
>> added the 'cmpn' jar to the outer classpath, and
>> to the system bundle, and tried to use a service tracker to obtain a
>> ConfigurationAdmin reference.
>> 'waitForService' on the tracker waits forever.
>> In the debugger, I can (eventually) obtain the ConfigurationAdmin
>> reference against the system bundle context. So this leads me to
>> believe that there's something I don't understand about threads and
>> Felix; I was expecting that once I started the framework, things like
>> activation of the ConfigurationAdmin service would happen on some
>> other thread, so I could have my main thread wait for it with a
>> ServiceTracker.
>> I can give up on this ConfigurationAdmin-from-outside bootstrap in
>> favor of passing some properties into an interface of a service of
>> mine, and let _it_ negotiate with ConfigurationAdmin for me, so if
>> this whole approach is poor it's easy to abandon.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to