aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <...@apache.org>
Subject Re: [Bluerint] Injection of properties not conformant with java-beans
Date Thu, 25 Nov 2010 16:59:53 GMT
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 <gnodet@gmail.com> 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 <not@apache.org> 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 <gnodet@gmail.com> wrote:
>>> On Thu, Nov 25, 2010 at 15:05, Alasdair Nottingham <not@apache.org> 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 <gnodet@gmail.com> 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 <gnodet@gmail.com>
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
>>>> not@apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>



-- 
Alasdair Nottingham
not@apache.org

Mime
View raw message