> 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
