2017-09-20 12:25 GMT+02:00 Carsten Ziegeler <cziege...@apache.org>: > 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. >
Why not simply using a META-INF/service and a fragment to configure the PM ? > > 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 > -- ------------------------ Guillaume Nodet
