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
