felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karel Haeck <karel.ha...@telenet.be>
Subject Re: ComponentException: Field value type must not be set for unary field references.
Date Sun, 24 Jan 2016 15:22:18 GMT
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, ben@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_jencks@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.auge@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, <ben@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, ben@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-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@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-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message