Re: Using a service tracker on ConfigurationAdmin from outside the framework
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 Margulieswrote: > > 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 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 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 >> > > - > 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
Re: Using a service tracker on ConfigurationAdmin from outside the framework
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 Margulieswrote: > > 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
Using a service tracker on ConfigurationAdmin from outside the framework
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
Re: Using a service tracker on ConfigurationAdmin from outside the framework
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 Bartlettwrote: > 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 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 > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Using a service tracker on ConfigurationAdmin from outside the framework
On Sun, Sep 18, 2016 at 3:53 PM, Neil Bartlettwrote: > 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 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 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 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 >>> >> >> - >> 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 >