Actually, I just realized that using field injection would get me passed this error. I'll just fix the fact that field injection only considers the current class field and not the parents, but otherwise it seems to work for me.
On Thu, Nov 25, 2010 at 17:59, Alasdair Nottingham <[email protected]> wrote: > It feels like such support should only work if someone has opted in, > either via custom namespace handlers, or via some other similar opt-in > mechanism. > > Perhaps an errata bug? > > Alasdair > > On 25 November 2010 15:36, Guillaume Nodet <[email protected]> wrote: >> Yes, it does. I've tested with both >> org.springframework.osgi.blueprint.uber-2.0.0.jar and the gemini >> blueprint 1.0.0-M1 and they both accept such a property injection. >> That's why I'm tempted to say we should support it too. >> >> On Thu, Nov 25, 2010 at 16:04, Alasdair Nottingham <[email protected]> wrote: >>> My gut feel would still be no, but do you know if the RI does this? >>> >>> Alasdair >>> >>> On 25 November 2010 14:17, Guillaume Nodet <[email protected]> wrote: >>>> On Thu, Nov 25, 2010 at 15:05, Alasdair Nottingham <[email protected]> wrote: >>>>> The spec also says: >>>>> >>>>> This name refers to the set method on the constructed object as >>>>> specified in the design pattern for beans getters and setters, see [6] >>>>> Java Beans Specification. >>>>> >>>>> As I recall the java.beans.Introspector requires a void return type so >>>>> I think the answer is no. However you could argue that we should >>>>> support JavaBeans spec more generally which would allow the bean >>>>> author to provide a BeanInfo that contains a PropertyDescriptor whose >>>>> write method had a return value. I just don't know if I agree with >>>>> this argument. >>>> >>>> No, I wouldn't either. However, the question is, if it's not tested >>>> by TCK and the RI does that, can / should we do it too ? >>>> >>>>> >>>>> Alasdair >>>>> >>>>> On 25 November 2010 13:13, Guillaume Nodet <[email protected]> wrote: >>>>>> The errata (http://www.osgi.org/Release4/Errata) says: >>>>>> >>>>>> 121.5.7 >>>>>> It was stated that overloaded property set methods must not be used. >>>>>> This is relaxed. The sentence now reads: "There should only be one set >>>>>> method with a single argument for a specific property. If overloaded >>>>>> properties are encountered, the chosen set method is unspecified." >>>>>> >>>>>> It does not seem to very explicit about having setters with non void >>>>>> return values. >>>>>> Can we enhance our implementation to support that ? >>>>>> >>>>>> >>>>>> On Thu, Nov 25, 2010 at 14:08, Guillaume Nodet <[email protected]> wrote: >>>>>>> The first version of the spec specifically disallowed supporting such >>>>>>> setters afaik, but I seem to recall a discussion about an errata on >>>>>>> the spec maybe related to that? >>>>>>> Any information ? It seems our implementation does not like setters >>>>>>> which have a non void return value, just wanted to check if that was >>>>>>> still a mandated behavior or not. >>>>>>> >>>>>>> -- >>>>>>> Cheers, >>>>>>> Guillaume Nodet >>>>>>> ------------------------ >>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>> ------------------------ >>>>>>> Open Source SOA >>>>>>> http://fusesource.com >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Cheers, >>>>>> Guillaume Nodet >>>>>> ------------------------ >>>>>> Blog: http://gnodet.blogspot.com/ >>>>>> ------------------------ >>>>>> Open Source SOA >>>>>> http://fusesource.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Alasdair Nottingham >>>>> [email protected] >>>>> >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> Guillaume Nodet >>>> ------------------------ >>>> Blog: http://gnodet.blogspot.com/ >>>> ------------------------ >>>> Open Source SOA >>>> http://fusesource.com >>>> >>> >>> >>> >>> -- >>> Alasdair Nottingham >>> [email protected] >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > > > > -- > Alasdair Nottingham > [email protected] > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
