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 13:22:31 GMT
After browsing through the code it seems like this is already implemented.
The InterpolationHelper was updated to support this in

https://issues.apache.org/jira/browse/FELIX-2663

(by yourself I believe Guillaume). This should be part of version 1.1.0 of
Felix utils. Fileinstall uses 1.1.0 of Felix utils. It is marked as a
private package and is therefore colocated in the fileinstall bundle.

Looking at fileinstall it also seems like it is updated to pass the bundle
context to InterpolationHelper. All in all, it seems like this has already
been resolved...

Now, why doesn't it work for me then?

I will do a few more tests to verify that I'm not lying about this,

/Bengt

2012/4/25 Bengt Rodehav <bengt@rodehav.com>

> Will do...
>
>
> 2012/4/25 Guillaume Nodet <gnodet@gmail.com>
>
>> Sure, and if you could provide a patch, that would be awesome of course
>> ;-)
>>
>> On Wed, Apr 25, 2012 at 14:14, Bengt Rodehav <bengt@rodehav.com> wrote:
>>
>> > Wouldn't that be a neat feature? Shall I create a JIRA?
>> >
>> > /Bengt
>> >
>> > 2012/4/25 Guillaume Nodet <gnodet@gmail.com>
>> >
>> > > You're absolutely right.  Custom properties are loaded by karaf main
>> and
>> > > given to the system bundle when the osgi framework is created, which
>> are
>> > > then made available to all bundles using BundleContext#getProperty().
>> > > The InterpolationHelper can be given a BundleContext which can be
>> used in
>> > > exactly the way we want.
>> > >
>> > > On Wed, Apr 25, 2012 at 13:47, Bengt Rodehav <bengt@rodehav.com>
>> wrote:
>> > >
>> > > > 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
>> > > > >
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > ------------------------
>> > > 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