On Sat, Nov 2, 2013 at 4:04 PM, Daniel McGreal <[email protected]> wrote:
> Thanks again Robert,
>
>> I'm not sure about the reason behind it, but I think that the
>> Felix-specific SCR annotations predate the OSGi spec for annotations.
>
>
> That occurred to me, but the naming was so similar that I ignored it. SCR has
> been very inspirational then!
> In that case, would it be an idea to extend the annotation’s target to
> methods as well as fields?
Maybe. Hopefully SCR devs can chime in regarding this design decision.
>
>> Hm, have you tried setting the property annotation on the class,
>> rather than a field?
>
>
> In my case, the value must be computed and retrieved from an external source
> (the first time) but can then be cached and expected not to change, which is
> why I have a service to provide it. I wonder how I could achieve that with
> configuration?
What I mean was writing something like ( not tested )
@Reference(name="myValue", interfaceReference = MyValue.class)
@Component
public class MyComp {
protected void bindMyValue(MyValue val) { /* whatever */ }
}
The only advantage of declaring a Reference on a field is that you
don't have to declare the name and interfaceReference properties,
which are inferred from the field. For more details, see [1].
Robert
[1]:
http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#reference
>
> Many thanks,
> Dan.
>
> On 2 Nov 2013, at 13:57, Robert Munteanu <[email protected]> wrote:
>
>> On Sat, Nov 2, 2013 at 3:50 PM, Daniel McGreal <[email protected]> wrote:
>>> Hi Robert,
>>>
>>> Thanks for your reply. I was not actually aware the plugin generated the
>>> methods, that’s very helpful!
>>>
>>> I have implemented the bind method in such a manner, but am forced to have
>>> a pointless (and potentially destructively misleading) field that I can’t
>>> prevent other people from using and therefore have to document that it’s
>>> not to be used or put effort into writing the class to ensure it’s null and
>>> thread safe on the reference - a task that would be implicit if the field
>>> never existed. To illustrate, when all is well in my class I have to have a
>>> warning that the field is unused, whereas what I need is a warning if it is!
>>
>> Hm, have you tried setting the property annotation on the class,
>> rather than a field? You might need to use a holder @Properties
>> annotation if you have more than one annotation.
>>
>>>
>>> I am curious as to the rationale of it being a field annotation rather than
>>> a method (or method + field), as it must have been a conscious choice to
>>> deviate from the way the OSGi spec does it.
>>
>> I'm not sure about the reason behind it, but I think that the
>> Felix-specific SCR annotations predate the OSGi spec for annotations.
>>
>> Robert
>>
>>>
>>> Best, Dan.
>>>
>>>
>>> On 2 Nov 2013, at 13:43, Robert Munteanu <[email protected]> wrote:
>>>
>>>> Hi Dan,
>>>>
>>>> On Sat, Nov 2, 2013 at 3:12 PM, Daniel McGreal <[email protected]> wrote:
>>>>> Hi Felix users,
>>>>> I wonder if anyone knows why the Felix @Reference annotations are valid
>>>>> on fields, but not methods, whereas the opposite is true for the OSGi
>>>>> standard @Reference annotation.
>>>>> I would very much like to have a service bound, which I don’t keep a
>>>>> reference to in the rest of my class (so that I can guarantee that code
>>>>> in the rest of the class doesn’t depend directly on the reference). For
>>>>> example:
>>>>>
>>>>> int value;
>>>>> private void bindValueGetter(ValueGetter s){
>>>>> value = s.getValue();
>>>>> }
>>>>>
>>>>> With the annotation on the field, I am forced to have a reference to the
>>>>> ValueGetter, which might mislead programmers into using it - without the
>>>>> reference there I can just keep the cached values when the service
>>>>> arrives the first time and not have to document, etc that it might be
>>>>> null.
>>>>
>>>> The maven-scr-plugin ( and I think the ant task as well ) generates a
>>>> 'bindValueGetter' method automatically if you don't have it in your
>>>> class. If you implement it yourself, you can control its behaviour,
>>>> just like in your snippet above.
>>>>
>>>> Robert
>>>>
>>>>>
>>>>> Thanks, Dan.
>>>>> ---------------------------------------------------------------------
>>>>> 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]
