Hi Guido,
Guido Spadotto schrieb:
> Hi all,
> I have already sent this mail to the Knopflerfish users mailing list
> and received this answer from Gunnar Ekolin:
>
> <quote>
> If I remember correctly, please correct me if not, a declarative
> service component can not be a managed service itself.
>
> I think there was a discussion about this (or was it
> ManagedServiceFactories) on the OSGi list a while back.
>
> The id of the component can be used as CM PID. The actual
> configuration data is made available to the component as properties in
> the component context, an update()-method in the component itself will
> never be called.
> </quote>
This is correct. Point is that the Declarative Services implementation
is providing the configuration to the component as part of the
properties of the ComponentContext the component receives in the
activate and deactivate method.
So, given that the runtime is providing the configuration, there is no
need for the component to register as a ManagedService.
If you still want to do that, it gets a bit hairy since you would have
to register your component as a service manually to properly the set
service.pid property to a value which is different than configuration
name. Of course you should also then unregister the component as a
service when the component is deactivated.
All in all, I suggest to not register a component as a ManagedService
and just extract the configuration from the ComponentContext properties.
Regards
Felix
>
> Since I've not been able to find out if that is actually the case (that
> is: a DS component
> cannot be a ManagedService too), I would like you to provide some input.
>
> Here's the scenario:
>
> I have an interface that extends ManagedService:
>
> public interface ITemperatureService extends ManagedService {
>
> public double getTemperature();
>
> }
>
> and it's "exposed" by an API bundle.
>
> In another bundle I have the implementation, exposed as a component
> using declarative services.
> Here's the XML component descriptor:
>
> <?xml version='1.0' encoding='utf-8'?>
> <component name='TemperatureSensorService'>
> <implementation
>
> class='[packages].impl.TemperatureSensorService.TemperatureSensorServiceImpl'
> />
> <property name="service.pid">ITemperatureService</property>
> <service>
> <provide
> interface='[packages].api.TemperatureSensorService.ITemperatureService' />
> </service>
> <reference name='logService' interface='org.osgi.service.log.LogService'
> cardinality='0..1' bind='setLogService' unbind='unsetLogService'
> policy='dynamic' />
> </component>
>
> Given that ITemperatureService extends ManagedService, the
>
> public void updated(Dictionary dictionary)
>
> method should be invoked when the configuration dictionary is updated,
> right?
>
> The problem is that the "updated" method from the implementation
> component of
> ITemperatureService is not being invoked even though a
> ConfigurationEvent is being fired:
> org.osgi.service.event.Event
> [topic=org/osgi/service/cm/ConfigurationEvent/CM_UPDATED]
>
> Am I missing something? Does the component have to provide EXACTLY the
> ManagedService
> interface, or can it provide an interface that extends ManagedService
> and yet be able to be called back
> when a configuration change occurs? What am I supposed to do to make a
> DS component "react" to
> configuration changes?
>
> Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
