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:48:10 UTC
Variable substitution in File install
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
Re: Variable substitution in File install
Posted by Bengt Rodehav <be...@rodehav.com>.
Did you have a chance to look at my patch Guillaume? It'd be great if this
improvement could make it into Karaf's next release since that's where it
could be really useful.
/Bengt
2012/4/25 Bengt Rodehav <be...@rodehav.com>
> Patch attached.
>
> /Bengt
>
> 2012/4/25 Bengt Rodehav <be...@rodehav.com>
>
>> JIRA created: https://issues.apache.org/jira/browse/FELIX-3487
>>
>> Patch is in the works...
>>
>> /Bengt
>>
>> 2012/4/25 Bengt Rodehav <be...@rodehav.com>
>>
>>> OK, I'll look closer then...
>>>
>>>
>>> 2012/4/25 Guillaume Nodet <gn...@gmail.com>
>>>
>>>> At a first glance, it looks like this patch fix the problem substitution
>>>> when loading properties, but not when saving.
>>>>
>>>> On Wed, Apr 25, 2012 at 15:22, Bengt Rodehav <be...@rodehav.com> wrote:
>>>>
>>>> > 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 <be...@rodehav.com>
>>>> >
>>>> > > Will do...
>>>> > >
>>>> > >
>>>> > > 2012/4/25 Guillaume Nodet <gn...@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 <be...@rodehav.com>
>>>> wrote:
>>>> > >>
>>>> > >> > Wouldn't that be a neat feature? Shall I create a JIRA?
>>>> > >> >
>>>> > >> > /Bengt
>>>> > >> >
>>>> > >> > 2012/4/25 Guillaume Nodet <gn...@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 <gn...@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 <gn...@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 <gn...@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 <be...@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
>>>> > >>
>>>> > >
>>>> > >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> FuseSource, Integration everywhere
>>>> http://fusesource.com
>>>>
>>>
>>>
>>
>
Re: Variable substitution in File install
Posted by Bengt Rodehav <be...@rodehav.com>.
Patch attached.
/Bengt
2012/4/25 Bengt Rodehav <be...@rodehav.com>
> JIRA created: https://issues.apache.org/jira/browse/FELIX-3487
>
> Patch is in the works...
>
> /Bengt
>
> 2012/4/25 Bengt Rodehav <be...@rodehav.com>
>
>> OK, I'll look closer then...
>>
>>
>> 2012/4/25 Guillaume Nodet <gn...@gmail.com>
>>
>>> At a first glance, it looks like this patch fix the problem substitution
>>> when loading properties, but not when saving.
>>>
>>> On Wed, Apr 25, 2012 at 15:22, Bengt Rodehav <be...@rodehav.com> wrote:
>>>
>>> > 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 <be...@rodehav.com>
>>> >
>>> > > Will do...
>>> > >
>>> > >
>>> > > 2012/4/25 Guillaume Nodet <gn...@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 <be...@rodehav.com>
>>> wrote:
>>> > >>
>>> > >> > Wouldn't that be a neat feature? Shall I create a JIRA?
>>> > >> >
>>> > >> > /Bengt
>>> > >> >
>>> > >> > 2012/4/25 Guillaume Nodet <gn...@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 <gn...@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 <gn...@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 <gn...@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 <be...@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
>>> > >>
>>> > >
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> FuseSource, Integration everywhere
>>> http://fusesource.com
>>>
>>
>>
>
Re: Variable substitution in File install
Posted by Bengt Rodehav <be...@rodehav.com>.
JIRA created: https://issues.apache.org/jira/browse/FELIX-3487
Patch is in the works...
/Bengt
2012/4/25 Bengt Rodehav <be...@rodehav.com>
> OK, I'll look closer then...
>
>
> 2012/4/25 Guillaume Nodet <gn...@gmail.com>
>
>> At a first glance, it looks like this patch fix the problem substitution
>> when loading properties, but not when saving.
>>
>> On Wed, Apr 25, 2012 at 15:22, Bengt Rodehav <be...@rodehav.com> wrote:
>>
>> > 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 <be...@rodehav.com>
>> >
>> > > Will do...
>> > >
>> > >
>> > > 2012/4/25 Guillaume Nodet <gn...@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 <be...@rodehav.com>
>> wrote:
>> > >>
>> > >> > Wouldn't that be a neat feature? Shall I create a JIRA?
>> > >> >
>> > >> > /Bengt
>> > >> >
>> > >> > 2012/4/25 Guillaume Nodet <gn...@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 <be...@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 <gn...@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 <gn...@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 <gn...@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 <be...@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
>> > >>
>> > >
>> > >
>> >
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> FuseSource, Integration everywhere
>> http://fusesource.com
>>
>
>
Re: Variable substitution in File install
Posted by Bengt Rodehav <be...@rodehav.com>.
OK, I'll look closer then...
2012/4/25 Guillaume Nodet <gn...@gmail.com>
> At a first glance, it looks like this patch fix the problem substitution
> when loading properties, but not when saving.
>
> On Wed, Apr 25, 2012 at 15:22, Bengt Rodehav <be...@rodehav.com> wrote:
>
> > 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 <be...@rodehav.com>
> >
> > > Will do...
> > >
> > >
> > > 2012/4/25 Guillaume Nodet <gn...@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 <be...@rodehav.com>
> wrote:
> > >>
> > >> > Wouldn't that be a neat feature? Shall I create a JIRA?
> > >> >
> > >> > /Bengt
> > >> >
> > >> > 2012/4/25 Guillaume Nodet <gn...@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 <be...@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 <gn...@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 <gn...@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 <gn...@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 <be...@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
> > >>
> > >
> > >
> >
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com
>
Re: Variable substitution in File install
Posted by Guillaume Nodet <gn...@gmail.com>.
At a first glance, it looks like this patch fix the problem substitution
when loading properties, but not when saving.
On Wed, Apr 25, 2012 at 15:22, Bengt Rodehav <be...@rodehav.com> wrote:
> 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 <be...@rodehav.com>
>
> > Will do...
> >
> >
> > 2012/4/25 Guillaume Nodet <gn...@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 <be...@rodehav.com> wrote:
> >>
> >> > Wouldn't that be a neat feature? Shall I create a JIRA?
> >> >
> >> > /Bengt
> >> >
> >> > 2012/4/25 Guillaume Nodet <gn...@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 <be...@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 <gn...@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 <gn...@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 <gn...@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 <be...@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
> >>
> >
> >
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Re: Variable substitution in File install
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <be...@rodehav.com>
> Will do...
>
>
> 2012/4/25 Guillaume Nodet <gn...@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 <be...@rodehav.com> wrote:
>>
>> > Wouldn't that be a neat feature? Shall I create a JIRA?
>> >
>> > /Bengt
>> >
>> > 2012/4/25 Guillaume Nodet <gn...@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 <be...@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 <gn...@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 <be...@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 <gn...@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 <gn...@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 <be...@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
>>
>
>
Re: Variable substitution in File install
Posted by Bengt Rodehav <be...@rodehav.com>.
Will do...
2012/4/25 Guillaume Nodet <gn...@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 <be...@rodehav.com> wrote:
>
> > Wouldn't that be a neat feature? Shall I create a JIRA?
> >
> > /Bengt
> >
> > 2012/4/25 Guillaume Nodet <gn...@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 <be...@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 <gn...@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 <be...@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 <gn...@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 <gn...@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 <be...@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
>
Re: Variable substitution in File install
Posted by Guillaume Nodet <gn...@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 <be...@rodehav.com> wrote:
> Wouldn't that be a neat feature? Shall I create a JIRA?
>
> /Bengt
>
> 2012/4/25 Guillaume Nodet <gn...@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 <be...@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 <gn...@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 <be...@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 <gn...@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 <be...@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 <gn...@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 <be...@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
Re: Variable substitution in File install
Posted by Bengt Rodehav <be...@rodehav.com>.
Wouldn't that be a neat feature? Shall I create a JIRA?
/Bengt
2012/4/25 Guillaume Nodet <gn...@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 <be...@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 <gn...@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 <be...@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 <gn...@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 <be...@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 <gn...@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 <be...@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
>
Re: Variable substitution in File install
Posted by Guillaume Nodet <gn...@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 <be...@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 <gn...@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 <be...@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 <gn...@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 <be...@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 <gn...@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 <be...@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 <be...@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
Re: Variable substitution in File install
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <gn...@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 <be...@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 <gn...@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 <be...@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 <gn...@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 <be...@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 <be...@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
>
Re: Variable substitution in File install
Posted by Guillaume Nodet <gn...@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 <be...@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 <gn...@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 <be...@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 <gn...@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 <be...@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 <be...@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
Re: Variable substitution in File install
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <gn...@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 <be...@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 <gn...@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 <be...@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 <be...@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
>
Re: Variable substitution in File install
Posted by Guillaume Nodet <gn...@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 <be...@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 <gn...@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 <be...@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 <be...@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
Re: Variable substitution in File install
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <gn...@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 <be...@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 <be...@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
>
Re: Variable substitution in File install
Posted by Guillaume Nodet <gn...@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 <be...@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 <be...@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
Re: Variable substitution in File install
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <be...@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
>
>
>