multiple-dynamic-reluctant and multiple-dynamic-greedy have exactly the same behavior, you could specify either one, i.e. you can leave out the policyOption.
Just to make things more complicated, if you are configuring your component with config admin and know exactly how many services will bind, and want them all before the component starts, you can use the <target-name>.cardinality.minimum property to specify how many services to bind must be available before the component is satisfied and activates. thanks david jencks > On Jan 22, 2016, at 11:22 AM, [email protected] 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 <[email protected]> >>> 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 <[email protected]> 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, <[email protected]> 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, [email protected] 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: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>> -- >>>> *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: [email protected] >>> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
