felix-dev mailing list archives

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

Thanks for the elaborate reply.

On 3/12/07, Steven E. Harris <seh@panix.com> wrote:
> 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:

Not really. Thanks to ConfigurationEvents, I can register as a
ConfigurationEventListener an get informed on all configuration updates. In
fact my current implementation implements such a listener and - on event -
cycles the respective component. This works well.

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.

This is not  really an issue, because all other works on declared components
must have the BundleContext, too. So I use the component's BundleContext to
get the ConfigurationAdmin service for that bundle. Thus I get correctly
bound configurations.

> 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

Yes, that is so.

But: If I have a thread T1 which is activating a component C1. If C1 would
be registered as a ManagedService, I would also provide Service properties,
which are the declared properties of C1 without the Configuration Admin
properties and I would activate C1 with the same properties. Configuration
Admin would the update the ManagedService of C1 thus resulting in a
requirement to deactivate C1 and reactivate C1 with the new properties, this
time including the Configuration Admin properties.

This results in the component being activated-deactivated-activated just for
the sake of configuration, which seems overkill. And this does not even take
into account any other components, which might depend on the first resulting
in a storm of cyclings.....

I might optimize by just registering a ManagedService and wait for the
configuration update - but then, this will never come in case no
Configuration Admin Service would be available, so I would have to check for
this special case ... a nightmare.

But back to question: What is the intent of the Spec: Should the components
be provided with configuration which has undergone ConfigurationPlugin
treatment or would it be acceptable to get "raw" configuration through


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message