or you can specify the field as final and initialize it with a thread
safe list.
There are actually three ways to handle changes in the list of
FileReaderService services
1) let SCR modify the list
@Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE,
policy=ReferencePolicy.DYNAMIC)
private final List<FileReaderService> availableServices = new
CopyOnWriteArrayList<>();
2) let SCR replace the list
@Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE,
policy=ReferencePolicy.DYNAMIC)
private volatile List<FileReaderService> availableServices;
3) let SCR activate a new component and deactivate the current
@Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE,
policyOption=ReferencePolicyOption.GREEDY)
private List<FileReaderService> availableServices;
Karel Haeck
On 22/01/2016 20:22, b...@petinou.fr wrote:
One last thing, the field has to be declared volatile. Otherwise, you
get the following error:
Field availableServices in component class org.test.FileReaderFactory
must be declared volatile to handle a dynamic reference
In the end, here is what I use:
@Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE,
policy = ReferencePolicy.DYNAMIC,
policyOption = ReferencePolicyOption.GREEDY)
private volatile List<FileReaderService> availableServices;
It works, but I'm not sure what the conclusion was regarding the
greedy option. Is it required or not? From what I understood,
multiple-dynamic-reluctant would fail.
Thanks to all for your answers
Ben
Le 22.01.2016 20:01, Neil Bartlett a écrit :
On 22 Jan 2016, at 18:41, David Jencks
<david_jen...@yahoo.com.INVALID> wrote:
um, multiple and dynamic is greedy anyway, so you don’t need to
specify it explicitly.
Not strictly 100% true… it’s more accurate to say that
multiple-dynamic-reluctant and multiple-dynamic-greedy behave the same
way, as shown in Table 112.1 in section 112.3.7 of the Compendium.
Anyway, Raymond’s intuition seems to be correct. The binding is not
randomly failing, it’s just that with the ‘reluctant’ policy option
SCR gives you just one service and then doesn’t bother
rebinding/reactivating the component in order to give you any more.
This is all according to the specification.
Neil
multiple and static requires specifying greedy explicitly to get the
greedy behavior.
Other than that, I think your explanation is correct.
david jencks
On Jan 22, 2016, at 7:20 AM, Raymond Auge
<raymond.a...@liferay.com> wrote:
Perhaps you should enable this reference to be dynamic. In your
current
configuration it's static which means that resolution of services
happens
at the moment the component is instantiated and never beyond that,
even if
later services might satisfy it as well.
You probably want something that is like a ServiceTracker (fully
dynamic
and greedy, sees all services and updates)
@Reference(
cardinality = ReferenceCardinality.MULTIPLE,
policy = ReferencePolicy.DYNAMIC,
policyOption = ReferencePolicyOption.GREEDY
)
On Fri, Jan 22, 2016 at 5:16 AM, <b...@petinou.fr> wrote:
In fact, its worst than that. Both ReferenceCardinality.MULTIPLE and
ReferenceCardinality.AT_LEAST_ONE seem to be randomly failing.
There seems to be some kind of concurrent problem when both
services start
at the same time: sometimes both are added to the service list,
sometimes
only one.
I would thus think this is a bug, but I'm not quite sure... Any SCR
specialist around to help?
I tried replacing List<FileReaderService> with
CopyOnWriteArrayList<MeshReader> but then the component is not
started at
all. Anyway, I think it would be better IMHO for SCR to deal with
concurrency conflicts.
Thanks
Le 22.01.2016 10:50, b...@petinou.fr a écrit :
Hi everyone,
I'm back with my issue for an erratum: the solution I provided does
not completely work. When I use:
@Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
private List<FileReaderService> availableServices;
Only one of the file reader services is inserted in the list. Output
of the code is:
Reading: test.txt
null
Reading: test.properties
[key6=value6, key5=value5, key4=value4]
However, when using:
@Reference(cardinality = ReferenceCardinality.MULTIPLE)
private List<MeshReader> availableServices;
The output is correct:
Reading: test.txt
[key1 value1, key2 value2, key3 value3]
Reading: test.properties
[key6=value6, key5=value5, key4=value4]
Any idea why? Is this a bug or a feature?
Kind regards,
Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
(@OSGiAlliance)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
