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.
https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.component.html#service.component-modification
<https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.component.html#service.component-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
*Dirk Fauth*
ETAS Advance Engineering
T +49 711 3423-2174
Dirk.Fauth@xxxxxxxx <mailto:Dirk.Fauth@xxxxxxxx>
ETAS GmbH, ETAS/ENA
Borsigstraße 24, 70469 Stuttgart, Germany
www.etas.com*
ETAS – Empowering Tomorrow’s Automotive Software*
Managing Directors: Christoph Hartung, Günter Gromeier, Götz Nigge
Chairman of the Supervisory Board: Dr. Walter Schirm
Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart,
HRB: 19033
*Von:* osgi-users <osgi-users-bounces@xxxxxxxxxxx> *Im Auftrag von
*Thomas Watson
*Gesendet:* Freitag, 10. Juni 2022 15:01
*An:* This is a community mail list for OSGi technology. Any OSGi
technical discussion or questions are acceptable here.
<osgi-users@xxxxxxxxxxx>
*Betreff:* Re: [osgi-users] OSGi DS field-option question
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
<mailto:osgi-users-bounces@xxxxxxxxxxx>> on behalf of Fauth Dirk
(ETAS/ENA) via osgi-users <osgi-users@xxxxxxxxxxx
<mailto:osgi-users@xxxxxxxxxxx>>
*Sent:* Friday, June 10, 2022 5:13 AM
*To:* This is a community mail list for OSGi technology. Any OSGi
technical discussion or questions are acceptable here.
<osgi-users@xxxxxxxxxxx <mailto:osgi-users@xxxxxxxxxxx>>
*Cc:* Fauth Dirk (ETAS/ENA) <dirk.fauth@xxxxxxxxxxxx
<mailto:dirk.fauth@xxxxxxxxxxxx>>
*Subject:* [EXTERNAL] [osgi-users] OSGi DS field-option question
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
*Dirk Fauth*
ETAS Advance Engineering
T +49 711 3423-2174
Dirk.Fauth@xxxxxxxx <mailto:Dirk.Fauth@xxxxxxxx>
ETAS GmbH, ETAS/ENA
Borsigstraße 24, 70469 Stuttgart, Germany
www.etas.com
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.etas.com%2F&data=05%7C01%7Cdirk.fauth%40de.bosch.com%7C3ce4e8a85f834f40e62208da4ae14198%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C637904628578831339%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=by3o47t8cLdP3A73j0Kxk%2B7ZsYPeb8VfFVVBO8daEOQ%3D&reserved=0>*
ETAS – Empowering Tomorrow’s Automotive Software*
Managing Directors: Christoph Hartung, Günter Gromeier, Götz Nigge
Chairman of the Supervisory Board: Dr. Walter Schirm
Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart,
HRB: 19033
_______________________________________________
osgi-users mailing list
osgi-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/osgi-users
