felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: Variable substitution in File install
Date Wed, 25 Apr 2012 11:47:40 GMT
The way I understood it, the InterpolationHelper is not used by config
admin but when the configuration is loaded from file (which is initiated by
file install). Thus, file install would have to be made aware of the
properties defined in custom.properties somehow. I have no idea where those
are evaluated though.

/Bengt

2012/4/25 Guillaume Nodet <gnodet@gmail.com>

> Yes, it should be possible to do that, for to be consistent, it would have
> to be done by ConfigAdmin too, else it could lead to inconsistencies
> between what FileInstall thinks the property value is and what the bundle
> actually receive.  So I'd be fine with any change if those are done by
> ConfigAdmin, but if they are done by iPojo or blueprint (for example), i'm
> not so sure.
>
> On Wed, Apr 25, 2012 at 13:36, Bengt Rodehav <bengt@rodehav.com> wrote:
>
> > Hello again Guillaume,
> >
> > I found the place where the substitution is being made. It's in the class
> > InterpolationHelper which resides in the same package as Felix Properties
> > class.
> >
> > I made a small test. It seems like variables defined as system variables
> > are preserved (because InterpolationHelper knows about them). Also, if I
> > refer to other configuration properties, they are preserved as well.
> >
> > However, the properties I define in my custom.properties file are not
> > preserved. Apparently they are not substituted by InterpolationHelper. I
> > have no idea where that substitution takes place but I would like to make
> > fileinstall aware of it. Do you think that is possible?
> >
> > /Bengt
> >
> > 2012/4/25 Guillaume Nodet <gnodet@gmail.com>
> >
> > > Yes, only properties that have change should be written back.
> > > But as you said, the check is done by substituting inside the
> properties
> > > file, but if the computed value is different from the value from the
> > > configuration, the whole property will be overwritten by the new value.
> >  Do
> > > you have substitution with system properties or other bundle
> > configuration
> > > properties ? If so, those properties will be overwritten at the first
> > > change.
> > >
> > > On Wed, Apr 25, 2012 at 12:28, Bengt Rodehav <bengt@rodehav.com>
> wrote:
> > >
> > > > You mean that only properties that have changed should be written
> back?
> > > Not
> > > > the part where variables are preserved even in changed properties - I
> > > > assume.
> > >
> > >
> > > > At a first glance I can't figure out where the variable substitution
> > > takes
> > > > place either. But for this to work, it must be done before comparing
> > with
> > > > the existing value - right?
> > > >
> > > > /Bengt
> > > >
> > > > 2012/4/25 Guillaume Nodet <gnodet@gmail.com>
> > > >
> > > > > That's exactly what is supposed to happen because we use
> > > > > the org.apache.felix.utils.properties.Properties which is known to
> > work
> > > > for
> > > > > that.
> > > > > One thing that could happen though is that the properties that are
> > > > > substituted are not know to fileinstall, so that it can't really
> > > compare
> > > > > the real values.
> > > > > The reason is that file install doesn't use the bundle system
> context
> > > > when
> > > > > computing the substitution so it only takes into account the
> > > substitution
> > > > > within the file, not with system properties or bundle context
> > > properties.
> > > > > I'm actually not sure who does such a substitution on the client
> side
> > > as
> > > > I
> > > > > doubt ConfigAdmin does not automatically.
> > > > >
> > > > > On Wed, Apr 25, 2012 at 11:11, Bengt Rodehav <bengt@rodehav.com>
> > > wrote:
> > > > >
> > > > > > One improvement I've been thinking about is to only write back
> > > > properties
> > > > > > that have actually changed. This would help in my case since
I
> have
> > > my
> > > > > own
> > > > > > web gui that disables/enables my services. I do so by setting
an
> > > iPOJO
> > > > > > @Controller property to true/false via config admin. I therefore
> > > don't
> > > > > use
> > > > > > any variables for this particular property but my other
> > configuration
> > > > > > properties (that are not changed) are "ruined" because of the
> > > variable
> > > > > > expansion.
> > > > > >
> > > > > > I'm not sure if config admin provides enough information to
> > determine
> > > > > what
> > > > > > properties have been changed. Either way file install could
> > probably
> > > > > > evaluate it's current value of the property (and do variable
> > > expansion
> > > > in
> > > > > > the process) and compare this value with the value provided
by
> > config
> > > > > > admin. If they are the same than no writing back of this property
> > is
> > > > > needed
> > > > > > and the variable would then be preserved in the configuration
> file.
> > > > > >
> > > > > > I guess it would also be possible to preserve variables in
> > properties
> > > > > that
> > > > > > have been changed as well. File install could check if the
> original
> > > > value
> > > > > > contained variables. It could then try use those variables for
> the
> > > new
> > > > > > value as well. It would then have to search in the new value
if
> the
> > > > value
> > > > > > of the property is still used and then substitute that value
for
> > the
> > > > > > property. This is not foolproof and could be ambiguous but I
> think
> > it
> > > > > could
> > > > > > be implemented to work in most cases. This feature should be
> > > > configurable
> > > > > > since it is not 100% safe.
> > > > > >
> > > > > > The feature not to write back properties that have not changed
> > could
> > > > also
> > > > > > be configurable but doesn't really have to be since I believe
it
> > can
> > > be
> > > > > > made foolprooof.
> > > > > >
> > > > > > /Bengt
> > > > > >
> > > > > > 2012/4/25 Bengt Rodehav <bengt@rodehav.com>
> > > > > >
> > > > > > > I use file install (currently 3.1.10 but have also tried
with
> > > 3.2.2)
> > > > in
> > > > > > > Karaf 2.2.5 to feed configurations (both normal and factory
> > > > > > configurations)
> > > > > > > into the config admin service.
> > > > > > >
> > > > > > > In my configuration files I use different variables that
I
> define
> > > in
> > > > > > > Karaf's custom.properties file. I'm not sure whether Karaf
> > exposes
> > > > them
> > > > > > as
> > > > > > > system properties but they are nevertheless picked up by
> > > fileinstall.
> > > > > > >
> > > > > > > However, when fileinstall is configured to write back
> > configuration
> > > > > > > changes to the configuration file, these variables are
not
> > > preserved
> > > > > but
> > > > > > > are expanded. This makes it very hard to read and further
> > maintain
> > > > the
> > > > > > > configuration files. I can easily see why this is happening
> since
> > > the
> > > > > > work
> > > > > > > is divided between file install and the configuration admin
and
> > the
> > > > > > latter
> > > > > > > does not know about the variables at all.
> > > > > > >
> > > > > > > I don't have a suggestion how to solve this but this is
a major
> > > > problem
> > > > > > > (for me at least) to use fileinstall and config admin
> together. I
> > > > guess
> > > > > > if
> > > > > > > fileinstall was just an implementation of the config admin
> > instead
> > > > of a
> > > > > > > general listener to configuration chagnes there would be
other
> > > > > > > possibilities.
> > > > > > >
> > > > > > > Does anyone have any suggestions how to combine write back
of
> > > > > > > configuration changes with preservation of variables? Could
> > > > fileinstall
> > > > > > > provide such a feature?
> > > > > > >
> > > > > > > /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
> > >
> >
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message