The comments and formatting can all be preserved. I've done that as part of FELIX-1718, and I don't see why it could not be done from fileinstall itself.
On Mon, Oct 11, 2010 at 10:02, Bengt Rodehav <[email protected]> wrote: > 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] > > > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
