Spring ReflectUtils#getBeanProperties does not support chained setter methods

Affects: 5.3.16

---

public class TestBean {

    private String name;

    public String getName() {
        return name;
    }

    public TestBean setName(String name) {
        this.name = name;
        return this;
    }

    public static void main(String[] args) {
        PropertyDescriptor[] beanProperties = ReflectUtils.getBeanProperties(TestBean.class);
        for (PropertyDescriptor beanProperty : beanProperties) {
            if (Objects.equals(beanProperty.getName(), "name")) {
                Method writeMethod = beanProperty.getWriteMethod();
                System.out.println("writeMethod = " + writeMethod);
            }
        }
    }
}

result:

Comment From: Deycoesr

BeanMap also have this problem

public class TestBean {

    private String name;

    public String getName() {
        return name;
    }

    public TestBean setName(String name) {
        this.name = name;
        return this;
    }

    public static void main(String[] args) {
        BeanMap beanMap = BeanMap.create(new TestBean());
        beanMap.put("name", "asd");
        System.out.println("beanMap = " + beanMap);
    }
}

result:

see BeanMapEmitter.java#L54

Comment From: Deycoesr

Can use ExtendedBeanInfo replace here ReflectUtils.java#L354 ?

Comment From: sbrannen

Can use ExtendedBeanInfo replace here ReflectUtils.java#L354 ?

No. ExtendedBeanInfo resides in the spring-beans module. So it cannot be used in ReflectUtils which resides in the spring-core module.

In any case, ReflectUtils is part of our repackaged CGLIB patch, which is not intended to be used by third parties.

Why are you using this repackaged version of ReflectUtils directly?

Comment From: Deycoesr

I found this problem when using BeanMap

Comment From: jhoeller

As Sam pointed out, BeanMap and its supporting classes are part of CGLIB (repackaged into spring-core). Standard JavaBeans setter methods need to be declared void, and that's what CGLIB is following; we are not going to deviate from that in our CGLIB fork (where we are not making use of CGLIB's BeanMap for any Spring features, it's just there because we happen to fully repackage the original CGLIB arrangement). Spring's own beans support is more lenient in that respect, but if you want that, you'll actually have to use Spring's BeanWrapper/ DataBinder/etc.