On Wed, Aug 10, 2016 at 5:44 PM, David Jencks <[email protected]> wrote: > I can’t think of any circumstances where you’d want to register with the > system bundle, normally you’d register with the bundle interested in the > configuration. It won’t make any difference unless you are using framework > hooks to control service visibility. An example of where it would make a > difference is if you installed a bunch of isolated subsystems each containing > their own config admin implementation. Registering the listener with a bundle > in one of these subsystems will make it visible only to that subsystem’s > config admin. Depending on how the isolation is set up registering with the > system bundle is likely to make it invisible to all the subsystem config > admins or possibly visible to all of them. >
> out of curiosity, why do you need your own ConfigurationListener? Oh, it's the collision of two issues. First, I need to have the arrangement of '.cfg' file make sense to a human being who is configuring a system, not just be a mirror of my momentary set of modularity decisions into @Component classes. So I can't use the DS connection to config-admin very well, since I need multiple objects to read the same configuration. Second, purely in my tests, I was having trouble making sure that the config of one of these items was present _before_ its @Activate was called, so I considered deferring the work until a ConfigurationListener was called back. When I registered it on the bundle at hand, it was never called. I probably registered it wrong. I've found a simpler approach. > > thanks > david jencks > >> On Aug 10, 2016, at 2:02 PM, Benson Margulies <[email protected]> wrote: >> >> I see examples that seem to be just registering these as a service on >> any old bundle. The javadoc says, "ConfigurationListener objects are >> registered with the Framework service registry". Does that mean the >> system bundle? >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
