Felix and Guillaume,
Yes I think that this must be the responsibility of file install (possible
configurable). However, this approach is generally a bit tricky since the
original configuration files would be overwritten programmatically. I have
bad experience from this kind of approach.
The configuration files need to be readable by humans and will/should
contain comments and is probably formatted the way a user wants it. Thus
this approach must preserver comments and formatting.
Also, the configuration files might use system properties, e g ${mybasedir}
that must be honored. I think the "write back" approach can only work in
very simple scenarios (not mine I think).
Currently, we regard changes done in the web console as "not persistent" and
tell our users that the values in the configuration files are the persistent
values. Maybe not ideal but it works if we can guarantee this.
/Bengt
2010/10/11 Felix Meschberger <[email protected]>
> Hi,
>
> On 11.10.2010 08:51, Guillaume Nodet wrote:
> > On Fri, Oct 8, 2010 at 14:33, Bengt Rodehav <[email protected]> wrote:
> >
> >> I'm using Karaf 1.6.0 (Felix 2.0.5 I think) and File install 3.0.2.
> >>
> >> I use iPOJO (1.6.4) to create service factories that are instantiated by
> >> file install by dropping a configuration file in a dedicated directory.
> >> When
> >> I update the configuration file, file install immediately propagates,
> the
> >> changes to the instantiated service.
> >>
> >
> > The files in etc/*.cfg are monitored by fileinstall and are used to feed
> > ConfigAdmin
> >
> >
> >>
> >> However, I can also change my configuration properties using
> configuration
> >> manager directly (e g via the Felix web console). When I change
> >> configuration properties this way, the properties are stored in
> >> configuration manager's bundle cache but they are not propagated back to
> >> file install and my configuration file.
> >>
> >
> > Yeah, it's a bit of a problem. Maybe a good thing would be to have the
> > webconsole plugin update the properties file directly when inside karaf,
> as
> > the command console do.
>
> As I said already, this would not be a good thing since the Web Console
> only talks to the Configuration Admin service and does not know (and
> must not know) of other configuration sources.
>
> Instead File Install should probably implement a ConfigurationListener
> which writes back modified configuration: File Install knows it sets
> configuration and it knows where it reads the config from and it knows
> the file format. So it is File Install only which can safely write back
> (if required). See FELIX-2571.
>
> Regards
> Felix
>
> >
> >
> >>
> >> This means that my configuration file (used by file install) can differ
> >> from
> >> the configuration actually used and what is stored in the bundle cache.
> An
> >> important question regarding this is which configuration takes
> precedence
> >> on
> >> startup?
> >>
> >> My tests indicate that what I specify in my configuration file (which is
> >> picked up by file install) is the configuration that will be used
> directly
> >> after startup. I need to know whether this behavior is guaranteed
> >> (deterministic) or if this is just the way it happens to work in my
> case.
> >>
> >
> > Yes, the files in etc/*.cfg should take precedence because fileinstall
> will
> > update all the configurations with what it founds in there, so any change
> > done by another mean in ConfigAdmin will certainly be overwritten by
> > fileinstall.
> >
> >
> >>
> >> I think I can live with either scenario - file install taking precedence
> or
> >> the bundle cache taking precedence - as long as the behavior is
> >> deterministic.
> >>
> >> /Bengt
> >>
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
