| Re: [osgi-users] OSGi DS field-option question |
|
Hi, While setting up a minimal example to reproduce the issue, I came across an old blog post of mine that explained the behavior. This is what I have noted down in my blog post. “If you do not specify a modified life cycle method, the Component Configuration is deactivated and afterwards activated again with the
new configuration object.” Looking into the specification, this is covered in chapter 112.5.14 Modification. After I added a modified life cycle event method, the behavior that the component instance is kept works as expected. No bug, the problem
was sitting between keyboard and chair. 😉 Mit freundlichen Grüßen / Best regards Von: osgi-users <osgi-users-bounces@xxxxxxxxxxx> Im Auftrag von
Thomas Watson At first glance this appears to be a bug. I suggest you open an issue against Felix SCR (assuming that is what you use). Be sure to include an example to reproduce. Before that, ensure that
the cardinality is set to 0..n in the component XML that is generated. Tom From: osgi-users <osgi-users-bounces@xxxxxxxxxxx> on behalf of Fauth Dirk (ETAS/ENA) via osgi-users <osgi-users@xxxxxxxxxxx> Hi, I am trying to create a service that stores some other service references and exchange them based on a target property. @Component(service = StringModifierRegistry.class)
public class StringModifierRegistry {
ZjQcmQRYFpfptBannerStart This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd Hi, I am trying to create a service that stores some other service references and exchange them based on a target property. @Component(service = StringModifierRegistry.class) public
class StringModifierRegistry {
@Reference(target =
"(!(service.intents=jaxrs))", policy = ReferencePolicy.DYNAMIC)
final List<StringModifier>
stringModifier =
new CopyOnWriteArrayList<>();
@Activate
void activate() { System.out.println("registry
activated"); }
@Deactivate
void deactivate() { System.out.println("registry
deactivated"); }
public List<StringModifier> getStringModifier() {
return
this.stringModifier; } } Since the policy is DYNAMIC and the list is final which leads to
field-option="update"
I would have expected that the list is updated and not replaced if I change the target filter via ConfigurationAdmin. But what I see is that the component gets deactivated and activated whenever I update the configuration. Switching to event binding also causes deactivate and activate. Maybe it is then not related to the collection update, but I am not sure. Is the deactivate and activate caused by the configuration update of the target target property or because the bound services change? I haven’t found a passage
in the specification on that topic. But maybe I looked in the wrong sections.
Mit freundlichen Grüßen / Best regards |