Using a service tracker on ConfigurationAdmin from outside the framework

[Benson Margulies <be...@basistech.com>]

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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Using a service tracker on ConfigurationAdmin from outside the framework

[Benson Margulies <be...@basistech.com>]

On Sun, Sep 18, 2016 at 3:53 PM, Neil Bartlett <nj...@gmail.com> wrote:
> 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).

Yes, felix exports 1.5 and imports [1.5,1.6). I feel as if this is
about to be one of those discussions about spec bundles that come
through here from time to time.

>
> 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.

It was my vague impression that we all use the 'Import your Exports'
cliché just for cases like this, which would imply that the resolution
process should always prefer the non-local version. However, I have
another reason to switch at some point from accessing config admin
from my 'outside' code to pushing the bootstrap information through an
interface of my own -- I will need to pass an NIO Path in there some
day, and config admin won't allow Path objects as values, and there
are issues with serializing them as URIs. So, eventually, I'll move
this code away from whatever risk it now has.

>
> Neil
>
>
>> On 18 Sep 2016, at 20:44, Benson Margulies <be...@basistech.com> wrote:
>>
>> As usual, the answer occurred to me moments after I pressed 'send'. I
>> neglected to specify a version for org.osgi.service.cm when adding it
>> to the system bundle export list.
>>
>> On Sun, Sep 18, 2016 at 3:18 PM, Neil Bartlett <nj...@gmail.com> 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 <be...@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-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>

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

Re: Using a service tracker on ConfigurationAdmin from outside the framework

[Neil Bartlett <nj...@gmail.com>]

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.

Neil


> On 18 Sep 2016, at 20:44, Benson Margulies <be...@basistech.com> wrote:
> 
> As usual, the answer occurred to me moments after I pressed 'send'. I
> neglected to specify a version for org.osgi.service.cm when adding it
> to the system bundle export list.
> 
> On Sun, Sep 18, 2016 at 3:18 PM, Neil Bartlett <nj...@gmail.com> 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 <be...@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-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


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

Re: Using a service tracker on ConfigurationAdmin from outside the framework

[Benson Margulies <be...@basistech.com>]

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

On Sun, Sep 18, 2016 at 3:18 PM, Neil Bartlett <nj...@gmail.com> 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 <be...@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-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>

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

Re: Using a service tracker on ConfigurationAdmin from outside the framework

[Neil Bartlett <nj...@gmail.com>]

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 <be...@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


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