Thanks for your mail. As you note, such a change would break all other users (or at least all users not using the default persistence manager). Therefore moving it to another bundle is maybe a too dramatical change. Now, what about a simpler solution: adding the evaluation of a framework property. If that is set, the default persistence manager is not registered, and an external one is used - the implementation will wait until such a service arrives in the registry.
If you think this is a good solution and want to provide a patch, please create a issue in our Jira and attach the patch. The patch should be based on the latest code from trunk. Regards Carsten Mailing-list wrote > By write and use a implementation of my own PersistenceManager the default > FilePersistenceManager start with the cm bundle and after this default > implementation, my own implementation with a higher service id. But my > implementation not use and the default implementation calls the > ManagedServiceFactory update method of my Declarative Service components with > null properties. The null Dictionary is fix at 1.8.16. But my implementation > of PersistenceManager will only use if the bundle with my PersistenceManager > implementation are start before the felix cm bundle. To solve this the cm > bundle start with osgi start level 3 and my PersistenceManager implementation > bundle with start level 2. It works but it is not my opinion of start osgi > bundles. I think the bundles and services start by dependency resolution - > like Declarative Services. Only the dependencies define the start and stop > order of the component, service and bundles. > > I have refactor the felix cm bundle and move the default implementation into > a separate bundle with own live cycle. It works fine for me. Now I want > contribute the refactor bundles. > Is it possible and if it possible with version is it possible. I wouldn't > break other projects, because the the default behavior of the felix cm change. > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
