You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Felix Meschberger <Fe...@day.com> on 2007/03/12 08:16:30 UTC
Configuration Admin and Declarative Service
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
Re: Configuration Admin and Declarative Service
Posted by Felix Meschberger <Fe...@day.com>.
Hi Steven,
Thanks for the elaborate reply.
On 3/12/07, Steven E. Harris <se...@panix.com> wrote:
>
> Felix Meschberger <Fe...@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 104.15.9.1:
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
ConfigurationAdmin.getConfiguration.
Regards
Felix
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
>
Re: Configuration Admin and Declarative Service
Posted by "Steven E. Harris" <se...@panix.com>.
Felix Meschberger <Fe...@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
Re: Configuration Admin and Declarative Service
Posted by Felix Meschberger <Fe...@day.com>.
Hi Clement,
Thanks for the clarification. I assume, that to comply with the spec I would
have to decide whether to register a ManagedService or a
ManagedServiceFactory for a given component in the first place. This would
probably be doable. The problem I have is with the asynchronicity: I
register the service, I get updates, I have to re-register, wich in the case
of a component means (according to the spec), deactivate and reactivate it,
which seems somewhat overkill.
I could, as you say, register two services with the same PID, one as a
ManagedService[Factory] and the other the real service (if at all needed),
where the ManagedService[Factory] would update the real service.
Regards
Felix
On 3/12/07, Clement Escoffier <cl...@gmail.com> wrote:
>
> Hello,
>
> 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
> ManagedServiceFactory
> - 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).
>
> Clement
>
>
> 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
> 38041 GRENOBLE CEDEX 9
> 04.76.51.40.24
> http://clement.plop-plop.net
>
>
>
Re: Configuration Admin and Declarative Service
Posted by Clement Escoffier <cl...@gmail.com>.
Hello,
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
ManagedServiceFactory
- 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).
Clement
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
38041 GRENOBLE CEDEX 9
04.76.51.40.24
http://clement.plop-plop.net