Hello I like the idea of "only one PM is used" - or rather I don't like the idea of using a whole array of all available org.apache.felix.cm.PersistenceManager implementations.
In my particular case I wanted to provide "encrypting file persistence manager" - ideally I wanted to wrap existing FilePersistenceManager, so it saves/loads encrypted properties. The first problem was that I couldn't unregister default FPM, so I had to do some injection magic to replace first element of org.apache.felix.cm.impl.ConfigurationManager#persistenceManagers array. > - the file PM is not registered as a service anymore I'd like to be able to get it anyway (to implement "wrapping" persistence managers) - like configmanager is told to use (&(objectClass=org.apache.felix.cm.PersistenceManager)(name=encrypting)), but the encrypting PM itself could wrap *published* (&(objectClass=org.apache.felix.cm.PersistenceManager)(name=file)). regards Grzegorz Grzybek 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. > > 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
