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! 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. 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]
