Hmm. This indicates that previously the cm export was satisfied by another 
bundle. Which of course it was because the Felix Config Admin implementation 
exports that package (in addition to importing it).

I am a little uncomfortable relying on this. I believe it would be legal for 
the framework to choose the export from the Config Admin bundle rather than 
from the system bundle. Ordinarily this would be fine because the consumer 
bundle would just wire to that export instead, but in your scenario the 
consumer bundle IS the system bundle, which cannot import.

Then again maybe the system bundle export will reliably take precedence. I’m 
not 100% clear on this.


> On 18 Sep 2016, at 20:44, Benson Margulies <> wrote:
> 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:

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

Reply via email to