Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 366791

Summary: FastBeanInfo needs to be more robust
Product: z_Archived Reporter: Claudio Guglielmo <claudio.guglielmo>
Component: ScoutAssignee: 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:

Description Claudio Guglielmo CLA 2011-12-15 04:37:59 EST
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.
Comment 1 Ivan Motsch CLA 2011-12-15 06:02:36 EST
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.
Comment 2 Ken Lee CLA 2012-01-13 08:14:06 EST
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.
Comment 3 Claudio Guglielmo CLA 2012-04-30 09:47:50 EDT
Reopened because the problem A is not solved according to Ken.
Comment 4 Ivan Motsch CLA 2016-08-24 07:14:06 EDT
Fixed since 5.0