[osgi-dev] Configuration Admin and Bundle Location

John E. Conlon johnconlon at verticon.com
Mon Jan 22 10:46:43 EST 2007

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 

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?



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 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

More information about the osgi-dev mailing list