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<[email protected]> 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
