Yes I agree. Updating the documentation should be definately be done. I would prefer to have the writeback configuration per fileinstaller configuration but I realize that doesn't fit too well with the current implementation. Anyway, I JIRA should be created for this (or two).
/Bengt 2012/4/25 Guillaume Nodet <[email protected]> > 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 >
