um, multiple and dynamic is greedy anyway, so you don’t need to specify it explicitly. 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
