You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Guido Spadotto <gs...@soluta.net> on 2009/03/26 10:32:56 UTC
Can a DS component be also a managed service?
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
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender and delete the
material from any computer.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Can a DS component be also a managed service?
Posted by Guido Spadotto <gs...@soluta.net>.
Felix Meschberger wrote:
> Hi Guido,
>
> [...]
> 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.
>
> [...]
>
Hi Felix and Jeremias, thanks for your precious tips.
I'm writing how I solved my issue here, in case someone else
might have my doubts in the future.
From the compendium specs, section 112.2:
"If an activated component configuration’s configuration properties change,
SCR must deactivate the component configuration and then attempt to
reactivate the component configuration using the new configuration
information."
So the next question is:
"How do I programatically alter a component configuration's
configuration property, so that the
'activate' method of the component will be invoked?"
On section 112.6 of the compendium specs, there's written:
"Each component configuration is associated with a set of component
properties.
The component properties are specified in the following places [...]:
[...]
2 Properties retrieved from the OSGi Configuration Admin service with a
Configuration object that has a PID equal to the name of the component.
[...]
The precedence behavior allows certain default values to be specified in the
component description while allowing properties to be replaced and
extended by:
• A configuration in Configuration Admin"
So I've come up with this snippet of code:
String COMPONENT_NAME = "<@name value in the 'component' element of the
component descriptor>";
Configuration config =
this.confAdminService.getConfiguration(COMPONENT_NAME);
Dictionary serviceProperties = config.getProperties();
if (serviceProperties == null) {
serviceProperties = new Hashtable();
serviceProperties.put(Constants.SERVICE_PID, COMPONENT_NAME);
}
serviceProperties.put("prop1", prop1_new_value);
serviceProperties.put("prop2", prop2_new_value);
config.update(serviceProperties);
Prop1 and Prop2 have default values specified in the component
descriptor.
Seems to be working...
Thanks again
--
Logo
Guido Spadotto
Soluta.net, Italy
http://www.soluta.net
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender and delete the
material from any computer.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Can a DS component be also a managed service?
Posted by Felix Meschberger <fm...@gmail.com>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Can a DS component be also a managed service?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org