John, Perhaps I shouldn't have said that PIDs must be "globally" unique since that implies the whole world. I meant that they must be unique within the context of an OSGi runtime instance. Sorry about that!
The implementation of Config Admin that I'm using is available as a CVS checkout from the Equinox repository. There's no downloadable JAR available as yet, I believe. However it appears to be fully compliant. It was developed by Simon Kaegi who I'm sure is reading this conversation. My bundle lives outside of the Config Admin bundle, and in theory it could work with any compliant Config Admin implementation. It simply does the following: 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). The point is to allow administrators to alter the config using the world's most popular Configuration Management Tool: vi. I wrote it as an external bundle because I didn't want to write my own Config Admin implementation. Of course if you ARE writing your own Config Admin, then you will have more flexibility, but also more work to do. However it would certainly be very useful if there was an implementation of Config Admin with a pluggable persistance mechanism. Regards, Neil > Neil, > > Yes, your comments were very helpful. > > I too thought we maybe pushing the envelope on the intention of the spec. > > In regards to PIDs I agree where the spec (104.3) says "Pids must be > unique for each service." But are they truly 'globally' unique? What I > mean - Is there yet a concept (a concept of global) within OSGi R4 where > more than one runtime is a consideration? (Maybe only these Config > Admin issues we are now discussing are touching on this?) > >> However I think >> the mistake you are making is assuming that there needs to be a >> one-to-one >> correspondence between Configuration objects and your external storage >> of >> those, i.e. in LDAP or whatever > > Right I was hung up on that 1..1 persistence. Thanks to you and BJ for > pointing it out. > > Regarding your implementation I'm not really clear on what your bundle > does in relationship to what the Equinox Config Admin does. Can you > give me some more details? (I tried to navigate to the Equinox Config > Admin @ > http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox.config > But got a 404 not found error.) > > Well the implementation I am working with is being done as part of an > ApacheDS team effort. Enrique Rodriguez did the initial work and I > have taken over with clean up of the initial prototype. (BTW- We > certainly can use some additional help;-) > > As far as multiple adapters go I've tried to set this up so we can plug > in different DAO backends. Right now we are using of course a JNDI based > one. > > cheers, > John > > Neil Bartlett wrote: >> John, >> >> I believe that what you say is technically correct, but you may be using >> Config Admin in a way that it was not designed to be used. >> >> It's true that there is a one-to-one mapping of Configuration objects to >> services. (NB in your third paragraph you suggest a second bundle that >> registers a service with the same PID as another service. PIDs are meant >> to be globally unique, so you shouldn't do this anyway). However I think >> the mistake you are making is assuming that there needs to be a >> one-to-one >> correspondence between Configuration objects and your external storage >> of >> those, i.e. in LDAP or whatever. >> >> I am using Config Admin with external configuration stored in flat files >> (actually JSON format but that's unimportant). The key point is there is >> a >> one-to-many mapping between configuration "records" stored in the >> filesystem and Configuration objects managed by Config Admin. The Config >> Admin objects are also persisted by the Config Admin implementation (I'm >> using the one supplied with Equinox, developed by Simon Kaegi) but I >> regard that as an internal implementation detail of the Config Admin >> service. I have my own bundle that is responsible for loading the >> external >> config files and keeping them in sync with Config Admin. >> >> I know this involves some extra coding to map the same concept onto your >> requirements. In my opinion it would be a great to have a little open >> source project with a few of the most commonly-needed "adaptors" in >> there, >> eg for XML files, LDAP, RDBMS, etc). I would contribute JSON adaptor I'm >> using, but unfortunately the copywrite is not owned by me. >> >> I hope this helps. Regards, >> Neil >> >> >> >>> Your right when the Configuration object is created it can be bound to >>> a >>> >> bundleLocation or not (left null). But when a Configuration Target >> (ManagedService or ManagedServiceFactory) registers and the >> >>> bundleLocation of its matched configuration is found to be null. (ie >>> >> not bound) Then its bundleLocation is bound dynamically to the >> >>> configuration. >>> >>> 104.12.3 says: "In this scenario the Configuration Object must become >>> >> bound to the first bundle that registers a ManageService (or >> >>> ManagedServiceFactory) with the right PID." >>> >>> If a second bundle in the same or a different OSGi runtime tries to >>> >> register a bundle that also utilizes the same configuration data (same >> ServicePID) 'an error should be logged and that the registering bundle >> should only be given a null'. >> >>> 104.4.1 : "If a Managed Service is registered with a PID that is >>> already >>> >> bound to another location, the normal callback to ManagedService.updated >> must not take place." >> >>> On the other hand this binding is set to null when the bundle is >>> >> unregistered from the runtime, but this still limits the configuration >> to a one at a time binding. >> >>> So if I have a enterprise directory server that I wish to use to serve >>> >> up configurations to OSGi applications throughout the enterprise. I >> will not be able to have more than one bundle registering and bound to >> each configuration. Effectively limiting the enterprise directory to >> service one application instance at a time. If I needed N number of >> instances of an application deployed through out an enterprise I would >> need a number of configurations on the directory server equal to the >> number of expected concurrent configuration targets. In other words >> ConfigurationAdmin is constrained to a 1..1 relationship of concurrent >> configuration targets to persisted configurations. >> >>> Perhaps I am overlooking a workaround somewhere? >>> >>> cheers, >>> >>> John >>> >>> >>> >>> Peter Kriens wrote: >>> >>>> First the location binding is option, if it is set to null, it no >>>> >> longer plays a role. >> >>>> I am not sure I can follow your logic. Could you give a concrete use >>>> >> case that seems impossible to you? I do not think a backend is in any >> way constrained. >> >>>> Kind regards, >>>> >>>> Peter Kriens >>>> >>>> >>>> JEC> Section 104.15.2.8 of the R4 for Configuration Admin, specifies >>>> that >>>> JEC> bundle locations can be be bound at configuration creation time >>>> to >>>> >> JEC> persisted Configuration entities. Does 'bound' mean that this >> value >> >>>> JEC> should be persisted along with the configuration data? >>>> >>>> JEC> Section 104.4.1 specifies how Configuration Target bundles >>>> should be >>>> JEC> bound dynamically on registration to Configuration objects. >>>> >>>> JEC> These location binding requirements seem to constrain the >>>> Configuration >>>> JEC> Admin to offer only a 1..1 relationship between a persisted JEC> >>>> >> configuration entity and a single configuration target instance. As I >> >>>> JEC> understand it the spec also seem to rule out the use case where >>>> an >>>> >> JEC> organization wishes to use a common Enterprise Store as a central >> JEC> configuration repository for persisted entities serving N number >> of JEC> configuration targets on multiple osgi runtimes. (1..n >> >>>> relationship >>>> JEC> between persisted entities and configuration targets.) >>>> >>>> JEC> Is this the intention? If so, how could the 1..n use case I >>>> >> describe be >> >>>> JEC> accomplished? >>>> >>>> JEC> thanks for any clarification, >>>> >>>> JEC> John Conlon >>>> JEC> Verticon, Inc. >>>> JEC> _______________________________________________ >>>> JEC> OSGi Developer Mail List >>>> JEC> [email protected] >>>> JEC> http://www2.osgi.org/mailman/listinfo/osgi-dev >>>> >>>> >>>> >>> _______________________________________________ >>> 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 >> >> >> > > _______________________________________________ > 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
