Yes, you're of course right that there is a small period where the configuration is not up-to-date. Probably the best we can do at this point though.
Ultimately I feel that some kind of SPI interface would be needed for configuration admin. I mean what file install basically does is providing a persistent store for certain configurations - *without the configuration admin being aware of this*. Should there exist a formalised way to interact with configuration admin (e g provide a means to register who will provide the persistence of certain configurations) then this would work a lot better. Do you know if anything is in the works in the OSGi specs? /Bengt 2010/10/11 Guillaume Nodet <[email protected]> > On Mon, Oct 11, 2010 at 11:47, Bengt Rodehav <[email protected]> wrote: > > > The use of system properties as well? In that case, yes it would be a > nice > > feature. > > > > What we have in the feature shell is that if the end result (interpolated > value) has not changed, the original won't be changed either. > However, if you modify a value which was interpolated, the interpolation > will be lost. > So the idea is that only diffs are written back. > > > > 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? > > > > Yes, AFAIK, the ConfigAdmin publishes its service when ready, but if its > internal cache and the fileinstall config files aren't synchronized, you'll > still have a period during which the configuration will have the values > they > had at the previous shutdown, but will be overwritten by fileinstall later > on. > > > > > > /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 > > > > > > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
