felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clement Escoffier <clement.escoff...@gmail.com>
Subject Re: Configuration Admin and Declarative Service
Date Mon, 12 Mar 2007 07:59:51 GMT

I am not sure that it's compliant with the SCR specification (in fact, I 
am sure that it's not compliant), but I implement the config admin 
support in iPOJO as following :
- (Public) Component factory exposes ManagedServiceFactory
- Component Instance can be created (and deleted) by using the 
- Component Instance does not directly exposed ManagedService. Indeed, 
the exposed pid and the pid who create the instance are the same, and 
the config admin does not suport this case. The reconfiguration of the 
instance must use the ManagedServiceFactory, but as you mentioned this 
update is called asynchronously.

The problem of this strategy in iPOJO is that instances created by 
private factories are not configurable. An extension of this way could be :
if an instance want to be configurable, and the ManagedServiceFactory is 
not exposed (private factory), the instance can exposes ManagedService.
I don't implement this extension because it seems to be difficult to 
understand (and to use).


Felix Meschberger a écrit :
> Hi all,
> I am currently integrating support for Configuration Admin Service 
> into the
> Felix Declarative Service implementation (o.a.f.scr). This includes
> providing the configuration from Configuration Admin to the component.
> 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 (I 
> assume the
> ManagedFactory situation is comparable, hence I ignore it for now).
> The problem with the first method is, that the ConfigurationPlugins 
> are not
> called (I interpret this from the sentence "If a bundle needs to force a
> Configuration plugin service to be called again, it must fetch the
> appropriate Configuration object from the Configuration Admin Service and
> call the update() method (the no parameter version) on this object" in
> Section 104.9.4, Forcing a Callback). The problem with the second 
> method is,
> that the configuration update must be executed asynchronously.
> What shall I do in the SCR ? Should I ignore the Configuration Plugin
> services and use the "simple" getConfiguration method or do I have to
> support this (nasty) asynchronous situation ?
> What is the intention of the Specification here ?
> Thanks alot for any clarifications.
> Regards
> Felix

Clement Escoffier
Grenoble University
LSR - Bat. C
220, Rue de la Chimie
BP 53

View raw message