Thanks a lot, That’s good to know. Dan. On 2 Nov 2013, at 16:03, Carsten Ziegeler <[email protected]> wrote:
> Hi Dan, > > yes you can use the OSGi annotations with the scr plugin, you need to add > this dependency to your project: > <groupId>org.apache.felix</groupId> > <artifactId>org.apache.felix.scr.ds-annotations</artifactId> > <version>1.2.4</version> > > Carsten > > > 2013/11/2 Daniel McGreal <[email protected]> > >> 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] >> >> > > > -- > Carsten Ziegeler > [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
