You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Lin Sun <li...@gmail.com> on 2010/08/24 04:58:54 UTC
ARIES-366
Hi
A while back ago, Aries-366 was committed to allow property injection
for properties with overloaded setter method.
I have one question regarding the changes for a simple scenario with
no overloading.
For example, in my bean I have -
// mismatched setters/getters
public void setValue(int v) {
this.value = v;
}
public Object getValue() {
return null;
}
In this case, should the blueprint container throw component
definition exception when attempting to create such a bean metadata?
I tends to think yes, and in our code, we should check the return of
the get method equals to the first parameter of the set method when
there is only one setter method exists.
Thoughts?
Lin
Re: ARIES-366
Posted by Alasdair Nottingham <no...@apache.org>.
Hi,
While I think this restriction is unreasonable the CT does test for it
and blueprint appears to fail that particular test.
Thanks
Alasdair
On 24 August 2010 17:07, Lin Sun <li...@gmail.com> wrote:
> Having only one setter is valid. Having multiple setters are valid too.
>
> However, there has to be one setter that is same as the return type of
> the getter.
>
> Lin
>
> On Tue, Aug 24, 2010 at 11:52 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>> Do you actually mean that having only a setter is not valid ?
>>
>> On Tue, Aug 24, 2010 at 17:32, Lin Sun <li...@gmail.com> wrote:
>>> Ok, I think that makes sense. I'll open a JIRA to address this.
>>>
>>> Thanks everyone for the comments!
>>>
>>> Lin
>>>
>>> On Tue, Aug 24, 2010 at 11:08 AM, Jarek Gawor <jg...@gmail.com> wrote:
>>>> On Tue, Aug 24, 2010 at 11:01 AM, Rick McGuire <ri...@gmail.com> wrote:
>>>>> On 8/24/2010 4:13 AM, Valentin Mahrwald wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Aries blueprint may call getters for chained property access
>>>>>>
>>>>>> <property name="foo.bar" value="..." />,
>>>>>>
>>>>>> but I would argue the scenario below even though dodgy can still be
>>>>>> supported. Essentially, I think there maybe a scenario where the setter
>>>>>> takes a primitive value but the getter
>>>>>> returns a complex object constructed from the primitive. In that scenario
>>>>>> having different arg types might be useful.
>>>>>>
>>>>>> So I would think this should be a warning rather than an error scenario,
>>>>>> but having the warning is probably quite useful.
>>>>>
>>>>> It was certainly the intent of the blueprint specification that the
>>>>> setter/getter method names follow the JavaBeans design pattern of having
>>>>> type matches when both a getter and setting method is implemented by the
>>>>> target class. This was definitely discussed during the final spec writing
>>>>> phase and the compliance tests also contain a test that validates that this
>>>>> is an error.
>>>>>
>>>>
>>>> Right. So in short there must be a matching getter and setter of the
>>>> same type and there might be additional setters that take other types.
>>>>
>>>> Jarek
>>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
--
Alasdair Nottingham
not@apache.org
Re: ARIES-366
Posted by Lin Sun <li...@gmail.com>.
Having only one setter is valid. Having multiple setters are valid too.
However, there has to be one setter that is same as the return type of
the getter.
Lin
On Tue, Aug 24, 2010 at 11:52 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> Do you actually mean that having only a setter is not valid ?
>
> On Tue, Aug 24, 2010 at 17:32, Lin Sun <li...@gmail.com> wrote:
>> Ok, I think that makes sense. I'll open a JIRA to address this.
>>
>> Thanks everyone for the comments!
>>
>> Lin
>>
>> On Tue, Aug 24, 2010 at 11:08 AM, Jarek Gawor <jg...@gmail.com> wrote:
>>> On Tue, Aug 24, 2010 at 11:01 AM, Rick McGuire <ri...@gmail.com> wrote:
>>>> On 8/24/2010 4:13 AM, Valentin Mahrwald wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Aries blueprint may call getters for chained property access
>>>>>
>>>>> <property name="foo.bar" value="..." />,
>>>>>
>>>>> but I would argue the scenario below even though dodgy can still be
>>>>> supported. Essentially, I think there maybe a scenario where the setter
>>>>> takes a primitive value but the getter
>>>>> returns a complex object constructed from the primitive. In that scenario
>>>>> having different arg types might be useful.
>>>>>
>>>>> So I would think this should be a warning rather than an error scenario,
>>>>> but having the warning is probably quite useful.
>>>>
>>>> It was certainly the intent of the blueprint specification that the
>>>> setter/getter method names follow the JavaBeans design pattern of having
>>>> type matches when both a getter and setting method is implemented by the
>>>> target class. This was definitely discussed during the final spec writing
>>>> phase and the compliance tests also contain a test that validates that this
>>>> is an error.
>>>>
>>>
>>> Right. So in short there must be a matching getter and setter of the
>>> same type and there might be additional setters that take other types.
>>>
>>> Jarek
>>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: ARIES-366
Posted by Guillaume Nodet <gn...@gmail.com>.
Do you actually mean that having only a setter is not valid ?
On Tue, Aug 24, 2010 at 17:32, Lin Sun <li...@gmail.com> wrote:
> Ok, I think that makes sense. I'll open a JIRA to address this.
>
> Thanks everyone for the comments!
>
> Lin
>
> On Tue, Aug 24, 2010 at 11:08 AM, Jarek Gawor <jg...@gmail.com> wrote:
>> On Tue, Aug 24, 2010 at 11:01 AM, Rick McGuire <ri...@gmail.com> wrote:
>>> On 8/24/2010 4:13 AM, Valentin Mahrwald wrote:
>>>>
>>>> Hi,
>>>>
>>>> Aries blueprint may call getters for chained property access
>>>>
>>>> <property name="foo.bar" value="..." />,
>>>>
>>>> but I would argue the scenario below even though dodgy can still be
>>>> supported. Essentially, I think there maybe a scenario where the setter
>>>> takes a primitive value but the getter
>>>> returns a complex object constructed from the primitive. In that scenario
>>>> having different arg types might be useful.
>>>>
>>>> So I would think this should be a warning rather than an error scenario,
>>>> but having the warning is probably quite useful.
>>>
>>> It was certainly the intent of the blueprint specification that the
>>> setter/getter method names follow the JavaBeans design pattern of having
>>> type matches when both a getter and setting method is implemented by the
>>> target class. This was definitely discussed during the final spec writing
>>> phase and the compliance tests also contain a test that validates that this
>>> is an error.
>>>
>>
>> Right. So in short there must be a matching getter and setter of the
>> same type and there might be additional setters that take other types.
>>
>> Jarek
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: ARIES-366
Posted by Lin Sun <li...@gmail.com>.
Ok, I think that makes sense. I'll open a JIRA to address this.
Thanks everyone for the comments!
Lin
On Tue, Aug 24, 2010 at 11:08 AM, Jarek Gawor <jg...@gmail.com> wrote:
> On Tue, Aug 24, 2010 at 11:01 AM, Rick McGuire <ri...@gmail.com> wrote:
>> On 8/24/2010 4:13 AM, Valentin Mahrwald wrote:
>>>
>>> Hi,
>>>
>>> Aries blueprint may call getters for chained property access
>>>
>>> <property name="foo.bar" value="..." />,
>>>
>>> but I would argue the scenario below even though dodgy can still be
>>> supported. Essentially, I think there maybe a scenario where the setter
>>> takes a primitive value but the getter
>>> returns a complex object constructed from the primitive. In that scenario
>>> having different arg types might be useful.
>>>
>>> So I would think this should be a warning rather than an error scenario,
>>> but having the warning is probably quite useful.
>>
>> It was certainly the intent of the blueprint specification that the
>> setter/getter method names follow the JavaBeans design pattern of having
>> type matches when both a getter and setting method is implemented by the
>> target class. This was definitely discussed during the final spec writing
>> phase and the compliance tests also contain a test that validates that this
>> is an error.
>>
>
> Right. So in short there must be a matching getter and setter of the
> same type and there might be additional setters that take other types.
>
> Jarek
>
Re: ARIES-366
Posted by Jarek Gawor <jg...@gmail.com>.
On Tue, Aug 24, 2010 at 11:01 AM, Rick McGuire <ri...@gmail.com> wrote:
> On 8/24/2010 4:13 AM, Valentin Mahrwald wrote:
>>
>> Hi,
>>
>> Aries blueprint may call getters for chained property access
>>
>> <property name="foo.bar" value="..." />,
>>
>> but I would argue the scenario below even though dodgy can still be
>> supported. Essentially, I think there maybe a scenario where the setter
>> takes a primitive value but the getter
>> returns a complex object constructed from the primitive. In that scenario
>> having different arg types might be useful.
>>
>> So I would think this should be a warning rather than an error scenario,
>> but having the warning is probably quite useful.
>
> It was certainly the intent of the blueprint specification that the
> setter/getter method names follow the JavaBeans design pattern of having
> type matches when both a getter and setting method is implemented by the
> target class. This was definitely discussed during the final spec writing
> phase and the compliance tests also contain a test that validates that this
> is an error.
>
Right. So in short there must be a matching getter and setter of the
same type and there might be additional setters that take other types.
Jarek
Re: ARIES-366
Posted by Rick McGuire <ri...@gmail.com>.
On 8/24/2010 4:13 AM, Valentin Mahrwald wrote:
> Hi,
>
> Aries blueprint may call getters for chained property access
>
> <property name="foo.bar" value="..." />,
>
> but I would argue the scenario below even though dodgy can still be supported. Essentially, I think there maybe a scenario where the setter takes a primitive value but the getter
> returns a complex object constructed from the primitive. In that scenario having different arg types might be useful.
>
> So I would think this should be a warning rather than an error scenario, but having the warning is probably quite useful.
It was certainly the intent of the blueprint specification that the
setter/getter method names follow the JavaBeans design pattern of having
type matches when both a getter and setting method is implemented by the
target class. This was definitely discussed during the final spec
writing phase and the compliance tests also contain a test that
validates that this is an error.
Rick
> Valentin
>
>
> On 24 Aug 2010, at 06:36, Alasdair Nottingham wrote:
>
>> Since blueprint doesn't call the getter I don't think it should care about the return type.
>>
>> So I would tend to think this should be fine.
>>
>> Alasdair
>>
>> On 24 Aug 2010, at 03:58, Lin Sun<li...@gmail.com> wrote:
>>
>>> Hi
>>>
>>> A while back ago, Aries-366 was committed to allow property injection
>>> for properties with overloaded setter method.
>>>
>>> I have one question regarding the changes for a simple scenario with
>>> no overloading.
>>>
>>> For example, in my bean I have -
>>>
>>> // mismatched setters/getters
>>> public void setValue(int v) {
>>> this.value = v;
>>> }
>>>
>>> public Object getValue() {
>>> return null;
>>> }
>>>
>>> In this case, should the blueprint container throw component
>>> definition exception when attempting to create such a bean metadata?
>>>
>>> I tends to think yes, and in our code, we should check the return of
>>> the get method equals to the first parameter of the set method when
>>> there is only one setter method exists.
>>>
>>> Thoughts?
>>>
>>> Lin
>
Re: ARIES-366
Posted by Valentin Mahrwald <vm...@googlemail.com>.
Hi,
Aries blueprint may call getters for chained property access
<property name="foo.bar" value="..." />,
but I would argue the scenario below even though dodgy can still be supported. Essentially, I think there maybe a scenario where the setter takes a primitive value but the getter
returns a complex object constructed from the primitive. In that scenario having different arg types might be useful.
So I would think this should be a warning rather than an error scenario, but having the warning is probably quite useful.
Valentin
On 24 Aug 2010, at 06:36, Alasdair Nottingham wrote:
> Since blueprint doesn't call the getter I don't think it should care about the return type.
>
> So I would tend to think this should be fine.
>
> Alasdair
>
> On 24 Aug 2010, at 03:58, Lin Sun <li...@gmail.com> wrote:
>
>> Hi
>>
>> A while back ago, Aries-366 was committed to allow property injection
>> for properties with overloaded setter method.
>>
>> I have one question regarding the changes for a simple scenario with
>> no overloading.
>>
>> For example, in my bean I have -
>>
>> // mismatched setters/getters
>> public void setValue(int v) {
>> this.value = v;
>> }
>>
>> public Object getValue() {
>> return null;
>> }
>>
>> In this case, should the blueprint container throw component
>> definition exception when attempting to create such a bean metadata?
>>
>> I tends to think yes, and in our code, we should check the return of
>> the get method equals to the first parameter of the set method when
>> there is only one setter method exists.
>>
>> Thoughts?
>>
>> Lin
Re: ARIES-366
Posted by Alasdair Nottingham <no...@apache.org>.
Since blueprint doesn't call the getter I don't think it should care about the return type.
So I would tend to think this should be fine.
Alasdair
On 24 Aug 2010, at 03:58, Lin Sun <li...@gmail.com> wrote:
> Hi
>
> A while back ago, Aries-366 was committed to allow property injection
> for properties with overloaded setter method.
>
> I have one question regarding the changes for a simple scenario with
> no overloading.
>
> For example, in my bean I have -
>
> // mismatched setters/getters
> public void setValue(int v) {
> this.value = v;
> }
>
> public Object getValue() {
> return null;
> }
>
> In this case, should the blueprint container throw component
> definition exception when attempting to create such a bean metadata?
>
> I tends to think yes, and in our code, we should check the return of
> the get method equals to the first parameter of the set method when
> there is only one setter method exists.
>
> Thoughts?
>
> Lin