Yeah, I understand the problem, but the code is currently written in a way that there is a single instance of the configuration save code and it's not related to which directory is scanned, so the configuration are thus global. Two solutions: better document the web page and optionally find a way to have that configurable on a per-directory basis (which does not mean we'd have to have multiple configuration listeners, just that the one should be able to find the correct property based on where the configuration comes from).
On Wed, Apr 25, 2012 at 15:47, Bengt Rodehav <[email protected]> wrote: > My bad, I did have this line in my config.properties: > > felix.fileinstall.disableConfigSave=false > > This I believe will disable configuration saving unless I also add: > > felix.fileinstall.enableConfigSave=true > > So, triggering of configuration saving works but I still consider it a bug > of some sort that the configuration values are "global". At the very list > this should be reflected in the documentation on Fileinstall's web page. > But I would very much like this to be a "per configuration factory" > setting. That way I can disable configuration saving in general but enable > it when reading configurations from certain directories (which is the way I > intended to use this setting). > > /Bengt > > > > 2012/4/25 Bengt Rodehav <[email protected]> > > > I used to use the disableConfigSave property but I've changed that to the > > enableConfigSave property when experimenting with Fileinstall 3.2.2. > > > > I also noticed that the shouldSaveConfig() method in the ConfigInstaller > > class seems to use "true" as default. What I don't know is who actually > > sets these properties on the bundle context. Perhaps the code that sets > the > > properties sets them to false if it cannot find a proper value. > > > > /Bengt > > > > > > 2012/4/25 Guillaume Nodet <[email protected]> > > > >> Do you have the disableConfigSave property set somehow ? > >> It should not take precedence over enableConfigSave, but it would be > used > >> as a default value if not set. > >> Fwiw, 3.2.0 had a problem where the test was inverted > >> > >> On Wed, Apr 25, 2012 at 10:34, Bengt Rodehav <[email protected]> wrote: > >> > >> > I'm using Karaf 2.2.5 in combination with File install 3.2.2 and have > >> > problems getting the " felix.fileinstall.enableConfigSave" work > >> properly. > >> > > >> > Karaf defines some (general?) file install properties in > >> config.properties. > >> > Karaf also adds another fileinstall factory configuration for > >> monitoring a > >> > hot deploy directory. In addition, I add a fileinstall factory > >> > configuration for monitoring an application specific directory for > >> > configurations. > >> > > >> > I put the following line in my fileinstall factory configuration: > >> > > >> > *felix.fileinstall.enableConfigSave=true* > >> > > >> > However, configuration updates are still not written back to the > >> > configuration file. Furthermore, it should not even be necessary since > >> the > >> > documentation on the File install web site says that this is the > >> default. > >> > > >> > The only way I can get configuration changes to be written back into > the > >> > configuration file is if I edit Karaf's config.properties and add: > >> > > >> > *felix.fileinstall.enableConfigSave=true* > >> > > >> > Thus, this property is "global" in some sense and does not have the > >> default > >> > value of true as the documentation says. > >> > > >> > I've browsed through the source code briefly and noticed that the > >> writing > >> > back to file functionality seems to be taken care of "globally" and > >> looks > >> > in the bundle context for a property > >> (DirectoryWatcher.ENABLE_CONFIG_SAVE) > >> > to determine whether to write back the configuration or not. Thus this > >> can > >> > never be specified per file install configuration. I haven't figured > out > >> > where this property is set. > >> > > >> > I regard this as a bug. This setting is specified at (and should > operate > >> > on) configuration basis. > >> > > >> > Shall I create a JIRA for this? > >> > > >> > /Bengt > >> > > >> > >> > >> > >> -- > >> ------------------------ > >> Guillaume Nodet > >> ------------------------ > >> Blog: http://gnodet.blogspot.com/ > >> ------------------------ > >> FuseSource, Integration everywhere > >> http://fusesource.com > >> > > > > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
