I'm relatively new to OSGi so please take this with caution:
DS constructs a ManagedService for you in the background. You don't have
to do that yourself (so don't make ITemperatureService extend
ManagedService). Instead, add the following method to your component
(TemperatureSensorServiceImpl):
protected void activate(ComponentContext context) {
context.getProperties().........
}
This is called by DS during activation and gives you access to the
properties associated with your component.
Finally, "protected void deactivate(ComponentContext context)" is called
when the component is deactivated.
See also: 112.2.2 "Immediate Component" in the R4 Compendium, page 285
HTH
On 26.03.2009 11:32:56 Guido Spadotto wrote:
> 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>
>
> 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
> --
> Logo
> Guido Spadotto
> Soluta.net, Italy
> http://www.soluta.net
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
