Hi, Rhett Sutphin schrieb: > Hi, > > I've been using felix for a while to provide a plugin layer for an > existing webapp. It's working pretty well, but I've recently run into > an issue with the configuration admin service and I'm not sure if I'm > resolving it the right way. So: > > I wanted to add persistence to my plugins' configurations, so I > implemented a org.apache.felix.cm.PersistenceManager. Felix made this > very easy.
Thanks ;-) > > The problem arose when I released my application and started working on > the next version. The configurations for my development deployment had > disappeared. Looking in the logs, I saw messages like this: > > ERROR: Configuration plugin.a.pid belongs to bundle > file:/path/to/plugin-a-2.6.0.DEV.jar but was requested for bundle > file:/path/to/plugin-a-2.6.1.DEV.jar This most probably stems from the fact, that you removed the bundle cache folders instead of uninstalling or upgrading the bundles. If you uninstall bundles, the configurations should automatically be unbound. If you just upgrade the bundles, the bundle location remains the same. But, if you remove the bundle cache folders from underneath the framework, the configurations will not be updated and remain bound to the bundles. > > I eventually understood why this was happening: the ConfigurationAdmin > spec requires that a particular Configuration be tied to a specific > bundle location[1]. I'm working around it now by filtering out the > service.bundleLocation property in my custom persistence manager. This > works but it seems like potentially unsupported behavior -- a bug > exploit rather than a solution. > > Has anyone else run into the problem? Any better solutions, or is > filtering out service.bundleLocation the best way to go? As I said, use the official framework API for managing the bundles, this should keep the configurations up to date. Though, on the other hand, it would probably be a worth while extension to our config admin to validate the bundle binding before barking in the log file: If a configuration bound to another bundle location should be supplied, check whether a bundle with said location still exists in the framework. If so, bark. Otherwise just rebind the configuration to the "new" bundle. Regards Felix > > Thanks, > Rhett > > [1]: It's not clear to me why this is desirable -- isn't tying it to the > PID sufficient? -- but I'll leave that aside for the moment. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
