[osgi-dev] Configuration Admin and Bundle Location

Simon Kaegi simon.kaegi at gmail.com
Wed Jan 24 13:36:00 EST 2007


Just to follow up on Neil's comment, the Config Admin implementation is in 
the equinox incubator.
e.g.
Host: dev.eclipse.org
Repository Path: /cvsroot/eclipse
Module: equinox-incubator/org.eclipse.equinox.cm

The implementation is fairly simple but it's complete, supported and correct 
at least as far as I know.
It should also be portable to other OSGi frameworks and requires an 
OSGi/Minimum-1.1 EE.

-Simon

----- Original Message ----- 
From: "Neil Bartlett" <neil at integility.com>
To: "OSGi Developer Mail List" <osgi-dev at www2.osgi.org>
Sent: Wednesday, January 24, 2007 5:58 AM
Subject: Re: [osgi-dev] Configuration Admin and Bundle Location


> 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> osgi-dev at www2.osgi.org
>>>>> JEC> http://www2.osgi.org/mailman/listinfo/osgi-dev
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> osgi-dev at www2.osgi.org
>>>> http://www2.osgi.org/mailman/listinfo/osgi-dev
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev at www2.osgi.org
>>> http://www2.osgi.org/mailman/listinfo/osgi-dev
>>>
>>>
>>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev at www2.osgi.org
>> http://www2.osgi.org/mailman/listinfo/osgi-dev
>>
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev at www2.osgi.org
> http://www2.osgi.org/mailman/listinfo/osgi-dev 



More information about the osgi-dev mailing list