| Summary: | FastBeanInfo needs to be more robust | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Claudio Guglielmo <claudio.guglielmo> |
| Component: | Scout | Assignee: | Ivan Motsch <ivan.motsch> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ken.lee, zimmermann |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
Fixed as described. Added checks so that more specific getters replace less specific and more specific setters replace less specific. Overall (as before) the most specific setter type wins. Setter types might be more specific than the getter type, but the bean property type is defined as the getter type. Added an additional eclipse scout james junit test for the reported bug cases. The fix does not solve the problem A with reference to forms and form datas. An analog problem is
public class FooForm extends AbstractForm {
private Long[] m_numbers;
@FormData
public void setNumbers(Long[] numbers) {
m_numbers= numbers;
}
public void setNumbers(Long number) {
m_number = new Long[]{number};
}
}
Obviously in this example both setters could be merged to one method
public void setNumbers(Long... numbers) { ... }
However, this is not possible in example A.
Problem:
Since both setters have identical names, the same key is used in the Property Descriptor Map (FastBeanUtility.createPropertyDescriptorMap), i.e. the first inserted PropertyDescriptor object will be replaced by the second one.
Consequence:
After import/export of form datas this could lead to null pointers.
Reopened because the problem A is not solved according to Ken. Fixed since 5.0 |
The FastBeanInfo is used to get all public properties of a certain class. Loading data into a formdata or filling up beans with the use of the SqlService are only two examples where it is extensively used. There exist some rare cases with certain JVMs where it does not work well. Two examples which don't always work: 1. public class A { public Long getX(); public void setX(Long x); public void setX(String y); } 2. public abstract class A { public abstract Object getX(); } public class B extends A { @Override public Long getX(); public void setX(Long x); } Depending on the order of the methods returned by Class.getDeclaredMethods() these two can fail.