Re: [osgi-dev] Regarding Collection references

BJ Hargrave Fri, 21 Jul 2017 07:01:55 -0700

From the javadoc of the Reference annotation:

The field option is based upon the policy and cardinality of the reference and the modifiers of the field. If the policy is ReferencePolicy.DYNAMIC, the cardinality is 0..n or1..n, and the field is declared final, the field option is FieldOption.UPDATE. Otherwise, the field option is FieldOption.REPLACE

@Reference(policy = ReferencePolicy.DYNAMIC)

private final Collection<MyServiceType> factories = new CopyOnWriteArrayList<>();

will set the field option to UPDATE.

--

BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
hargr...@us.ibm.com

----- Original message -----
From: "Fauth Dirk (AA-AS/EIS2-EU)" <dirk.fa...@de.bosch.com>
Sent by: osgi-dev-boun...@mail.osgi.org
To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Cc:
Subject: Re: [osgi-dev] Regarding Collection references
Date: Fri, Jul 21, 2017 1:45 AM

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
Tel. +49 7153 666-1155 | 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> 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
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

_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Regarding Collection references

Reply via email to