karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com.INVALID>
Subject Re: [DISCUSSS] Duplicate persistent-id usage can cause bundle restart loop...
Date Wed, 03 Aug 2016 06:08:54 GMT
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é <jb@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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com


Mime
View raw message