The Felix implementation has such a store abstraction, but unfortunately, it's not bi-directional, meaning it's really possible to let the store push some changes to config admin. Also, I haven't used that since I did not really want to have the karaf etc/ folder poluted by lots of configurations and I wanted the user to be in control of those.
On Mon, Oct 11, 2010 at 14:14, Bengt Rodehav <[email protected]> wrote: > 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 > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
