Hi Felix,
On Oct 17, 2009, at 3:54 PM, Felix Meschberger wrote:
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 see, that explains it. In my case, Felix is running inside a
traditional webapp under Tomcat. The bundle cache directories are
inside the exploded webapp. Whenever the application is redeployed,
the exploded webapp is removed and replaced, including all of Felix's
runtime cache information.
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.
I'll see if I can figure out a way to do this in my situation.
Thanks for the advice,
Rhett
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
