You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Bengt Rodehav <be...@rodehav.com> on 2012/04/25 10:34:07 UTC
Bug in Fileinstall, felix.fileinstall.enableConfigSave does not work
per configuration
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
Re: Bug in Fileinstall, felix.fileinstall.enableConfigSave does not
work per configuration
Posted by Bengt Rodehav <be...@rodehav.com>.
I created two JIRA's:
https://issues.apache.org/jira/browse/FELIX-3488
https://issues.apache.org/jira/browse/FELIX-3489
/Bengt
2012/4/25 Bengt Rodehav <be...@rodehav.com>
> 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 <gn...@gmail.com>
>
>> 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 <be...@rodehav.com> 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 <be...@rodehav.com>
>> >
>> > > 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 <gn...@gmail.com>
>> > >
>> > >> 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 <be...@rodehav.com>
>> 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
>>
>
>
Re: Bug in Fileinstall, felix.fileinstall.enableConfigSave does not
work per configuration
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <gn...@gmail.com>
> 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 <be...@rodehav.com> 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 <be...@rodehav.com>
> >
> > > 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 <gn...@gmail.com>
> > >
> > >> 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 <be...@rodehav.com>
> 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
>
Re: Bug in Fileinstall, felix.fileinstall.enableConfigSave does not
work per configuration
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <be...@rodehav.com> 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 <be...@rodehav.com>
>
> > 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 <gn...@gmail.com>
> >
> >> 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 <be...@rodehav.com> 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
Re: Bug in Fileinstall, felix.fileinstall.enableConfigSave does not
work per configuration
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <be...@rodehav.com>
> 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 <gn...@gmail.com>
>
>> 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 <be...@rodehav.com> 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
>>
>
>
Re: Bug in Fileinstall, felix.fileinstall.enableConfigSave does not
work per configuration
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <gn...@gmail.com>
> 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 <be...@rodehav.com> 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
>
Re: Bug in Fileinstall, felix.fileinstall.enableConfigSave does not
work per configuration
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <be...@rodehav.com> 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