You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Guillaume Nodet <gn...@gmail.com> on 2010/11/25 14:08:11 UTC
[Bluerint] Injection of properties not conformant with java-beans
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
Re: [Bluerint] Injection of properties not conformant with java-beans
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <no...@apache.org> 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 <gn...@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 <no...@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 <gn...@gmail.com> wrote:
>>>> On Thu, Nov 25, 2010 at 15:05, Alasdair Nottingham <no...@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 <gn...@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 <gn...@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
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [Bluerint] Injection of properties not conformant with java-beans
Posted by Alasdair Nottingham <no...@apache.org>.
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 <gn...@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 <no...@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 <gn...@gmail.com> wrote:
>>> On Thu, Nov 25, 2010 at 15:05, Alasdair Nottingham <no...@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 <gn...@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 <gn...@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
Re: [Bluerint] Injection of properties not conformant with java-beans
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <no...@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 <gn...@gmail.com> wrote:
>> On Thu, Nov 25, 2010 at 15:05, Alasdair Nottingham <no...@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 <gn...@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 <gn...@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
Re: [Bluerint] Injection of properties not conformant with java-beans
Posted by Alasdair Nottingham <no...@apache.org>.
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 <gn...@gmail.com> wrote:
> On Thu, Nov 25, 2010 at 15:05, Alasdair Nottingham <no...@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 <gn...@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 <gn...@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
Re: [Bluerint] Injection of properties not conformant with java-beans
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Nov 25, 2010 at 15:05, Alasdair Nottingham <no...@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 <gn...@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 <gn...@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
Re: [Bluerint] Injection of properties not conformant with java-beans
Posted by Alasdair Nottingham <no...@apache.org>.
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.
Alasdair
On 25 November 2010 13:13, Guillaume Nodet <gn...@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 <gn...@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
Re: [Bluerint] Injection of properties not conformant with java-beans
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <gn...@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