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
