You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Rhett Sutphin <rh...@detailedbalance.net> on 2009/10/16 21:09:00 UTC
ConfigurationAdmin, persistence, and bundles with versions in their filenames
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.
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
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?
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ConfigurationAdmin, persistence, and bundles with versions in their filenames
Posted by Rhett Sutphin <rh...@detailedbalance.net>.
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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ConfigurationAdmin, persistence, and bundles with versions in
their filenames
Posted by Felix Meschberger <fm...@gmail.com>.
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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org