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 <ben...@basistech.com> 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 org.osgi.service.cm
> 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: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Reply via email to