For configadmin 1.9 (R7 branch) I've implemented the following changes now:

Only one PM is used.

If no configuration (through framework prop) is provided the current
file PM is used.

The file PM is registered as a service with the name "file"

If a config is provided, this is the name of the PM (service property)
and only if that service is available, the CM is activated/registered.
Service Ranking is handled in this case as well and the one with the
specified name and highest ranking is used

Regards

Carsten


Carsten Ziegeler wrote
> Hi
> 
> the current way of handling persistence managers in our config admin
> implementation is not 100% reliable and ultimately can lead to confusion
> and wrong results (see FELIX-5693 and FELIX-5685).
> 
> Now, I've suggested an improvement in FELIX-5693 which should solve the
> problem and provides a 100% compatible solution. However while
> implementing this, I found out that being 100% compatible makes the code
> really ugly. So I'm wondering now if we really need to go that far.
> 
> Today, one can register as many persistence managers and *all* of them
> are picked up and used ordered by service ranking. As the file PM is
> registered by default, there is always one and this one is used from the
> beginning. Some more details are in those issues.
> 
> I think we should change this to:
> - only one PM is used
> - if no configuration (through framework prop) is provided the current
> file PM is used
> - the file PM is not registered as a service anymore (there is no use in
> doing so)
> - if a config is provided, this is the name of the PM (service property)
> and only if that service is available, the CM is activated/registered
> 
> This simplifies the config of the CM, the handling of PMs and also the
> code. The downside is that if you want to use a custom PM it requires
> you to set a configuration. As this is usually not the common use case I
> think thats fine.
> 
> If we want to be 100% compatible, then we have the ugly handling by
> default and if you want to restrict this to just the file PM you have to
> provide a config option. Which ultimately every user of our bundle
> should do (unless a custom PM should be used)
> 
> WDYT?
> 
> Regards
> Carsten
> 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Reply via email to