>IIUIC, the connection between the text files and the Configuration object is >bi-directional. What happens in case of a conflict?
It's a simple tool, so it simply allows the runtime Configuration objects to override any changes to the text files. >Also, does your tool follow the specification's definition of a Configuration >Plugin and support the all the types that Configuration Admin does? My understanding of a Config Plugin is that it modifies a Configuration before it reaches its target ManagedService(Factory). The purpose of my tool is to supply the Configuration object in the first instance. >Where can I find it? This is the problem... you can't, because I don't own the IP :-( If people are interested, I can try to get it opened up. However I'm coming around to the opinion that what is really needed is an actual Config Admin implementation with pluggable persistence, rather than something that works as a client to Config Admin. It sounds like the ApacheDS guys might be working on something like that, or (as Harald points out) there is the one included in OSXA. Neil > On Wednesday 24 January 2007 18:58, Neil Bartlett wrote: >> 1) On startup, reads the persisted config records and compares with the >> Configuration objects which it queries from Config Admin. It then makes >> whatever adjustments are necessary to the runtime Configuration, based >> on >> changes in the persisted records. >> 2) While running, periodically polls the persisted config for changes, >> making the corresponding adjustments to the runtime Configuration >> objects. >> 3) On shutdown, queries Config Admin again and writes out to the >> persisted >> files any changes that were made at runtime (e.g. by a management tool). > > IIUIC, the connection between the text files and the Configuration object > is > bi-directional. What happens in case of a conflict? > > Also, does your tool follow the specification's definition of a > Configuration > Plugin and support the all the types that Configuration Admin does? > > Where can I find it? > > > Cheers > Niclas > _______________________________________________ > OSGi Developer Mail List > [email protected] > http://www2.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
