felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel McGreal <dan...@redbite.com>
Subject Re: SCR @Reference on fields?
Date Sat, 02 Nov 2013 15:17:12 GMT
Hi Carsten, 
Thanks a lot for your reply.

Are you saying that one can use the OSGi annotations with the Maven-SCR-Plugin? I thought
I tried this initially, without success - but thinking about it, I may have been misled because
maven complained I didn’t have the “AnnotationProcessor” (or similar) when I didn’t
have the scr.annotations bundle as a dependency - maybe I just assumed that having included
the annotations bundle, those were the annotations I should be using.

If this is the case, no need for an feature request I think.

Best, Dan.

On 2 Nov 2013, at 15:12, Carsten Ziegeler <cziegeler@apache.org> wrote:

> Hi,
> 
> as Robert wrote, the scr annotations from the Apache Felix project predate
> the annotations from the spec. Regardless of which annotations you use, the
> result is compliant to the DS specification: a descriptor XML is generated
> containing the references and for each reference the methods for bind and
> unbind are listed and these methods must exist in the contained class.
> While the Reference annotations from the OSGi spec is more pure in the
> sense that you annotate the bind method, the one from Apache Felix is more
> convenient at least for unnary references as you just annotate the field
> and the methods are generated for you.
> If you want to mimic the same behaviour, you have to use a Reference
> annotation on the class as explained by Robert as well.
> We could add support for annotation a method like the OSGi annotations do,
> you might want to create a feature request issue for this
> 
> Regards
> Carsten
> 
> 
> 2013/11/2 Robert Munteanu <rombert@apache.org>
> 
>> On Sat, Nov 2, 2013 at 4:04 PM, Daniel McGreal <daniel@redbite.com> 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 <rombert@apache.org> wrote:
>>> 
>>>> On Sat, Nov 2, 2013 at 3:50 PM, Daniel McGreal <daniel@redbite.com>
>> 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 <rombert@apache.org> wrote:
>>>>> 
>>>>>> Hi Dan,
>>>>>> 
>>>>>> On Sat, Nov 2, 2013 at 3:12 PM, Daniel McGreal <daniel@redbite.com>
>> 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: 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
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>> 
>> 
> 
> 
> -- 
> Carsten Ziegeler
> cziegeler@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