The use of system properties as well? In that case, yes it would be a nice feature.
I've been thinking about the risk with "unlucky timing" - is there really such a risk? I think configuration manager publishes an OSGi service and file install I imagine will require that service. If configuration manager restores its state from the cache prior to publishing its service then the startup sequence should be guaranteed - right? /Bengt 2010/10/11 Guillaume Nodet <[email protected]> > 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 >
