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]
