That doesn’t seem entirely accurate to me. If the bundle location on the config is set to a multi-location any bundle with appropriate permissions (i.e. all if you aren’t enforcing permissions) will have visibility into the configuration. If the bundle location is set but not to a multi-location then: - only ManagedService/ManagedServiceFactory instances in that bundle will be notified - DS and any other well-behaved extender will only use that configuration for components in that bundle - both getConfiguration methods and the listConfiguration method will return the configuration unmodified (permissions allowing)
If the bundle location is null then: - the first ManagedService/ManagedServiceFactory to get notified will “claim” the configuration as CA will set the bundleLocation to that of the containing bundle - code using listConfiguration or getConfiguration(pid, null) won’t “claim” the configuration - code using getConfiguration(pid) or getConfiguration(pid, location) will set the bundleLocation, “claiming” it - extenders such as blueprint or DS should either be implemented using ManagedService/ManagedServiceFactory or not claim the configuration. There’s no safe way to identify and claim a configuration outside of the config admin implementation itself. Felix DS never modifies the bundle location. I’d expect Aries blueprint to have the same situation but haven’t looked. For maximum flexibility I’d think that karaf should provide a way to specify the bundle location for a configuration, basically so you can set it to “?”. Hope this isn’t too long-winded. thanks david jencks > On Aug 2, 2016, at 9:52 PM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > Hi James, > > you are right only for the ManagedService. If several bundles directly read > the configuration with ConfigAdmin (using directly the service), than there > is no problem. > > The problem occurs only when you have several ManagedService on the same > config (called when the configuration change especially). > > Regards > JB > > On 08/02/2016 09:53 PM, James Carman wrote: >> When two different bundles use the same configuration pid, you can get into >> a very weird restart loop (at least with blueprint). It violates the >> specification for two bundles to try to use the same configuration. >> Shouldn't we just fail to start the second bundle if the pid is already >> "claimed"? >> >> James >> > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
