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
