felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven E. Harris" <...@panix.com>
Subject Re: Configuration Admin and Declarative Service
Date Mon, 12 Mar 2007 15:48:43 GMT
Felix Meschberger <Felix.Meschberger@day.com> writes:

> The issue I stumbled upon is the question of how to get at the
> configuration to be provided to components. There are two ways to
> get these: (1) call ConfigurationAdmin.getConfiguration(String pid)
> and (2) register a ManagedService and have its updated(Dictionary)
> method called

There is a third way: ConfigurationAdmin.listConfigurations(), with a
filter looking like "(service.pid=...)". But even then, I think option
2 -- registering a ManagedService or ManagedServiceFactory -- is the
only way for DS to comply with the tracking/updating requirement in
Section 112.7:

  SCR must track changes in the Configuration objects used in the
  component properties of a component configuration. If a
  Configuration object that is related to a component configuration
  changes, then SCR must deactivate that component configuration and,
  if the Configuration object was not deleted, SCR must attempt to
  reactive the component configuration with the updated component
  properties.

One tricky point from earlier in that same Section:

  SCR must obtain the Configuration objects from the Configuration
  Admin service using the Bundle Context of the bundle containing the
  component.

I think this means that SCR has to register its ManagedService and
ManagedServiceFactory services using the BundleContext of the
component in order for the location binding aspect of Configurations┬╣
to work properly.

> (I assume the ManagedFactory situation is comparable, hence I ignore
> it for now).

Yes, it's similar, swapping getConfiguration() for
createFactoryConfiguration(), "(service.pid=...)" for
"(service.factoryPid=...)", and updated(Dictionary) for
updated(String, Dictionary).

> The problem with the second method is, that the configuration update
> must be executed asynchronously.

Your ManagedService and ManagedServiceFactory implementations are
allowed to synchronize their updated() methods, and the specification
advocates synchronizing the registration to the same lock. From
Section 104.15.9.1:

  The Configuration Admin service must call this method asynchronously
  which initiated the callback.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (Surely this is an error.)

  This implies that implementors of Managed Service can be assured
  that the callback will not take place during registration when they
  execute the registration in a synchronized method.

And from Section 104.15.10.3:

  The Configuration Admin service must call this method
  asynchronously.  This implies that implementors of the
  ManagedServiceFactory class can be assured that the callback will
  not take place during registration when they execute the
  registration in a synchronized method.


Footnotes: 
┬╣ Compendium Section 104.4.1, Location Binding.

-- 
Steven E. Harris

Mime
View raw message