You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Filippo Diotalevi <fi...@gmail.com> on 2009/04/16 10:25:03 UTC

Re: [jira] Updated: (FELIX-1036) FileInstaller spawns multiple watchers for same directory

On Thu, Apr 16, 2009 at 10:13 AM, Filippo Diotalevi (JIRA)
<ji...@apache.org> wrote:
>
>     [ https://issues.apache.org/jira/browse/FELIX-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>    Attachment: FELIX-1036.patch
>
> Sahoo, can you give this patch a run? I tried againt you use case and in my application, and it seems to work.
> [...]
> The patch assumes that configuration files always "win". In other words, at startup, all cached configurations are updated with
> dictionaries coming from configuration files.
> I think it's acceptable, since when you use FileInstall you are not supposed to change the configurations using other tools like
> WebConsole.

Just an additional note on this bug.

In my OSGi applications (all server side) I never felt the need for a
bundle cache, so I always delete it before restarts and never
experienced similar problems.

However, while debugging fileinstall I realized that there's at least
one more issue when using bundle cache and the fileinstall approach.
If you
- have your application running with a set of configuration files
managed by FileInstall
- stop the application
- remove one configuration file
- restart the application *and your application use the felix-cache*
then the deleted configuration dictionary will be still present,
because it's retrieved from cache and never deleted.

Honestly for me it's a non-issue. Caching and FileInstall are kind of
opposite approaches, either you store your configuration files in the
cache, or in the FileInstall. However I see that it can be seen as a
strange behavior.

I'm wondering how (and if) other fileinstaller/dirpoller, like the
servicemix one, solve this problem.

-- 
Filippo Diotalevi