Hi, the answers from BJ and Tim are already saying everything. So I just want to give another view on this, as it took me also a while to get the difference when learning the DS 1.3 stuff.
You are using field references on a collection and you specify the reference to be dynamic. So it is a DYNAMIC reference with MULTIPLE cardinality. As you specified the Collection as a final field, I’m honestly not sure whether it is RELUCTANT or GREEDY, but that should not matter as the field is never updated by the SCR. In the OSGi Compendium specification chapter 112.3.8 the reference field option is described. There you can in short read about the two different ways how a Collection field can be handled by SCR. The default is FieldOption#REPLACE. So typically the SCR would replace the collection if a new service comes up or goes away. Having the annotation defaults in mind, this should look like this: @Reference private volatile Collection<MyServiceType> factories; If you want to take care of the Collection type yourself and require to keep the Collection instance and want only to update it via Collection#add() and Collection#remove() instead of replacing it, you could use FieldOption#UPDATE. @Reference(policy = ReferencePolicy.DYNAMIC, fieldOption = FieldOption.UPDATE) private final Collection<MyServiceType> factories = new CopyOnWriteArrayList<>(); Honestly I am not sure if you need to specify the fieldOption when setting the field to be final. The spec in chapter 112.3.8.2 says this: “The update option can only be used for a dynamic reference with multiple cardinality. The component's constructor can set the field with its choice of collection implementation. In this case, the field can be declared with the final modifier. The collection implementation used by the component should use identity rather than equals or hashCode to manage the elements of the collection. The collection implementation should also be thread-safe since SCR may update the collection from threads different than those used by the component instance.” The description of the fieldOption helped me to understand that there are different ways to deal with Collections in DS. Maybe it helps you too. Mit freundlichen Grüßen / Best regards Dirk Fauth Automotive Service Solutions, ESI application (AA-AS/EIS2-EU) Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | www.bosch.com<http://www.bosch.com> Tel. +49 7153 666-1155 | dirk.fa...@de.bosch.com<mailto:dirk.fa...@de.bosch.com> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000; Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner, Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Markus Heyn, Dr. Dirk Hoheisel, Christoph Kübel, Uwe Raschke, Peter Tyroller Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] Im Auftrag von Tim Ward Gesendet: Freitag, 21. Juli 2017 00:03 An: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Betreff: Re: [osgi-dev] Regarding Collection references Hi Scott, The SCR annotations are interpreted based on the context of where they are applied. This is described in the JavaDoc for the annotations, and the DS spec. Because you have declared your SCR reference as a final field this means that the SCR will be told to update your collection using add/remove rather than injecting a populated collection. It is therefore up to you to ensure that the collection is thread safe (so in this case ArrayList is a bad choice!). My default in this scenario is to use a CopyOnWriteArrayList. If instead you make the field non final then you do not need to initialise it. SCR will then be configured to inject a fully populated thread-safe collection and you can use it without fear of invalid state or ConcurrentModificationException. Another option would be to declare bind/unbind methods and to make the changes to the collection yourself. I hope this helps. Tim Sent from my iPhone On 20 Jul 2017, at 21:49, Leschke, Scott <slesc...@medline.com<mailto:slesc...@medline.com>> wrote: If I have a reference in an SCR component like the following, @Reference(policy = ReferencePolicy.DYNAMIC) private final Collection<MyServiceType> factories = new java.util.ArrayList<>(); Since the collection is updated by the runtime as services come and go, I assume it’s prudent to synchronize on the collection when iterating over it whereas in Blueprint I got the impression this wasn’t necessary. Would that be correct? Scott Leschke _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
