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 <[email protected]> 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 <[email protected]> > >> 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] >> >> > > > -- > Carsten Ziegeler > [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
