[ 
https://issues.apache.org/jira/browse/FELIX-5693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved FELIX-5693.
-------------------------------------
    Resolution: Fixed

As announced in the mailing list I changed the behaviour now completeley.
First of all, only a single persistence manager is used. Using several PMs at 
once is not supported anymore.
Persistence managers must be registered with a "name" service property. The 
FilePersistenceManager gets the name "file"
A new framework property "felix.cm.pm" defines the name of the PM to be used. 
If its not specified or empty, the default FilePersistenceManager is used.
If the property is specified, the implementation searches for a PM with that 
name and uses the one with the highest service ranking. If there is no such 
service, no configuration admin is activated. If such a service becomes 
available, the CA is registered. If such a service is unregistered, CA is 
unregistered as well.



> Improve persistent manager handling
> -----------------------------------
>
>                 Key: FELIX-5693
>                 URL: https://issues.apache.org/jira/browse/FELIX-5693
>             Project: Felix
>          Issue Type: Improvement
>          Components: Configuration Admin
>            Reporter: Carsten Ziegeler
>            Assignee: Carsten Ziegeler
>             Fix For: configadmin-1.9.0
>
>
> The current handling of persistence managers is a little bit fragile and not 
> really deterministic.
> I propose the following enhancements:
> - Persistence managers can be registered with a "name" service property. The 
> FilePersistenceManager gets a name, e.g. "file"
> - we add a new framework property configuration - if that's empty or not 
> there, CM acts as today
> - if a value is configured, it's interpreted as a comma separated list of 
> names. This list of names makes up the PMs to be used by the implementation. 
> All of them must be registered and only these are used.
> - the PMs are used in the order they are specified in the list
> With this we have deterministic behaviour and full control while the default 
> ootb behaviour is still maintained. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to