Hi, On 11.10.2010 14:21, Guillaume Nodet wrote: > 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
Yes, it is so by intent. The abstraction just allows the implementation to use different persistence layers for its own internal store assuming it is in full control of the layer and all changes go through the official API as it is intended to be. Regards Felix > 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 >>> >> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
