I didn’t investigate, so there might be a bug, but note that your field example 
has fieldOption REPLACE, so the CopyOnWriteArrayList  you set will never 
actually be used, DS will install it’s own list.  What is your evidence that 
the field is never set?  What happens if you make the field final, which will 
result in the UPDATE fieldOption?

thanks
david jencks

> On Nov 28, 2016, at 2:51 PM, Roy Teeuwen <[email protected]> wrote:
> 
> Hey,
> 
> Maybe I should start making a new thread for this hehe :). Not sure if this 
> is a bug or if I'm just using it incorrectly.
> 
> So created some test classes quickly. 
> Don't know when it used to work with the immediate = true, but I guess it 
> might not be related then, seeing as it wont work for field even with 
> immediate true. 
> I tried the following two examples. The one with the bind method does work, 
> the one with field reference does not.
> 
> # Field reference:
> 
> @Component(service = TestAggregator.class)
> public class TestAggregator {
> 
>    @Reference(policy = ReferencePolicy.DYNAMIC, cardinality = 
> ReferenceCardinality.MULTIPLE)
>    private List<TestInterface> interfaces = new 
> CopyOnWriteArrayList<TestInterface>();
> 
> }
> 
> generates following xml:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.3.0"; 
> name="org.apache.felix.osgi.ds.TestAggregator">
>    <implementation class="org.apache.felix.osgi.ds.TestAggregator"/>
>    <service>
>        <provide interface="org.apache.felix.osgi.ds.TestAggregator"/>
>    </service>
>    <reference name="interfaces" cardinality="0..n" policy="dynamic" 
> interface="org.apache.felix.osgi.ds.TestInterface" field="interfaces" 
> field-collection-type="service"/>
> </scr:component>
> 
> # Method reference: 
> 
> @Component(service = TestAggregator.class)
> public class TestAggregator {
> 
>    @Reference(policy = ReferencePolicy.DYNAMIC, cardinality = 
> ReferenceCardinality.MULTIPLE)
>    protected void bindTestInterface(TestInterface testInterface) {
>        interfaces.add(testInterface);
>    }
> 
>    protected void unbindTestInterface(TestInterface testInterface) {
>        interfaces.remove(testInterface);
>    }
> }
> 
> generates following xml:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <component name="org.apache.felix.osgi.ds.TestAggregator">
>    <implementation class="org.apache.felix.osgi.ds.TestAggregator"/>
>    <service>
>        <provide interface="org.apache.felix.osgi.ds.TestAggregator"/>
>    </service>
>    <reference name="TestInterface" cardinality="0..n" policy="dynamic"
>               interface="org.apache.felix.osgi.ds.TestInterface" 
> bind="bindTestInterface"
>               unbind="unbindTestInterface"/>
> </component>
> 
> The field reference one won't bind an existing TestInterface service, the 
> method reference will.
> 
> Greets,
> Roy
> 
> 
>> On 29 Nov 2016, at 00:28, David Jencks <[email protected]> wrote:
>> 
>> As everyone has said, the immediate setting isn’t going to make any 
>> difference to the binding.  You may be able to investigate what is going on 
>> by installing gogo and looking at the output of scr:info in various 
>> circumstances and also by installing an osgi logger and setting the 
>> ds.loglevel=debug framework or ds configuration property and examining the 
>> resulting voluminous log output.
>> 
>> For the @Reference-on-field question could you show the component xml 
>> generated by bnd (perhaps via the maven-bundle-plugin)?  Which version of 
>> bnd is in use?  Some older versions didn’t figure out the service type very 
>> well, and I’m not sure anyone has tested with the <> “diamond” notation 
>> (although I can’t imagine how this could mess anything up).
>> 
>> thanks
>> david jencks
>> 
>>> On Nov 28, 2016, at 12:33 PM, Roy Teeuwen <[email protected]> wrote:
>>> 
>>> Hey Karel,
>>> 
>>> Sorry to go further than the original question, but seeing as my question 
>>> is related to exactly the same thing, maybe you can help me understand it 
>>> better. 
>>> Using the exact same example as the in the initial post, if I don't put 
>>> immediate=true, it won't bind all of the services get created at startup or 
>>> get added during the runtime. Is there a reason why it has to be immediate 
>>> = true?
>>> 
>>> I also tried it by using the following notation, and then this it doesn't 
>>> even bind any of services:
>>> 
>>> @Reference(cardinality = ReferenceCardinality.MULTIPLE, policy = 
>>> ReferencePolicy.DYNAMIC)
>>> private List<StateMachine> stateMachines = new CopyOnWriteArrayList<>();
>>> 
>>> Greetings,
>>> Roy
>>>> On 28 Nov 2016, at 21:39, Karel Haeck <[email protected]> wrote:
>>>> 
>>>> Nicolas,
>>>> 
>>>> the spec does not specify that static references should be injected before 
>>>> dynamic,
>>>> but it does specify that references must be processed in sequence as 
>>>> specified in the component xml:
>>>> 
>>>> "When binding services, the references are processed in the order in which 
>>>> they are specified in the
>>>> component description. That is, target services from the first specified 
>>>> reference are bound before
>>>> services from the next specified reference."
>>>> 
>>>> In addition the spec specifies how @Reference annotations are ordered:
>>>> 
>>>> " In the generated Component Description for a component, the references 
>>>> must be ordered in ascending
>>>> lexicographical order (using String.compareTo ) of the reference names."
>>>> 
>>>> Note that the default name is based on the field or method name. In your 
>>>> case get aclService  for the static reference
>>>> and "" (empty string) for the dynamic reference as spec states that the 
>>>> add , bind or set prefix is removed.
>>>> ( Actually if one uses Java naming conventions the event methods will have 
>>>> names starting with an upper case character and precede the field 
>>>> references).
>>>> 
>>>> By specifying e.g.  @Reference( name = "zStateMachine", cardinality = 
>>>> ReferenceCardinality.MULTIPLE, policy = ReferencePolicy.DYNAMIC)
>>>> the static reference should be bound first.
>>>> 
>>>> Note that there is still a potential race condition between the add and an 
>>>> activate method if present,
>>>> or between two concurrent add() executions.
>>>> 
>>>> regards,
>>>> Karel
>>>> 
>>>> On 28/11/2016 12:09, Nicolas Brasey wrote:
>>>>> Hi,
>>>>> 
>>>>> I have a bind order issue with a component that has :
>>>>> 
>>>>> 1) A static reference specified with annotation @Reference on the private
>>>>> field
>>>>> 2) A dynamic multiple reference specificed with annotation on a method
>>>>> 
>>>>> The static reference is not bound before the dynamic ones.
>>>>> 
>>>>> The code looks like this:
>>>>> 
>>>>> @Component(immediate = true)
>>>>> public class MyServiceImpl implements MyService {
>>>>> 
>>>>>  @Reference
>>>>>  private AclService aclService;
>>>>> 
>>>>>  @Reference(
>>>>>          cardinality = ReferenceCardinality.MULTIPLE,
>>>>>          policy = ReferencePolicy.DYNAMIC
>>>>>  )
>>>>>  public void add(StateMachine stateMachine) {
>>>>>     ....
>>>>>      ....
>>>>>  }
>>>>> 
>>>>> 
>>>>> According to the Declarative Service specifications, the static references
>>>>> should always be injected before the activate method.
>>>>> 
>>>>> 
>>>>> Does anyone have any idea what might be wrong ?
>>>>> 
>>>>> 
>>>>> My env is Apache Karaf 4.0.5 with Felix SCR 2.0.2
>>>>> 
>>>>> 
>>>>> Thanks for you help!
>>>>> 
>>>>> Nicolas
>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> 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]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to