ExtendedBeanInfo exception - java.beans.IntrospectionException [SPR-9702]

[spring-projects-issues]

Scott Bartram opened SPR-9702 and commented

After upgrading our existing application from 3.0.5 to 3.1.2, we see java.beans.IntrospectionException on our domain model classes. It appears to be triggered by interaction with the java.beans code and GC on Weak/Soft Reference objects.

I will create a test sample in github.

---

Affects: 3.1.2

Issue Links:

• Overhaul non-void JavaBean write method support [SPR-10029] #14663 Overhaul non-void JavaBean write method support ("depends on")
• Bean Introspection problem under IBM Java 1.6 with new ExtendedBeanInfo [SPR-9453] #14088 Bean Introspection problem under IBM Java 1.6 with new ExtendedBeanInfo ("duplicates")
• Processing java.math.BigDecimal via Spring's ExtendedBeanInfo fails sporadically [SPR-10111] #14744 Processing java.math.BigDecimal via Spring's ExtendedBeanInfo fails sporadically
• Support injection against setter methods with non-void return types [SPR-8079] #12734 Support injection against setter methods with non-void return types
• Simplify CachedIntrospectionResults caching arrangements [SPR-10028] #14662 Simplify CachedIntrospectionResults caching arrangements

[spring-projects-issues]

Chris Beams commented

Hi Scott,

This is very probably a duplicate of #14088. Put a watch on that, and I'll make sure your repro project unit tests turn green when it gets resolved.

Thanks!

[spring-projects-issues]

Scott Bartram commented

I'm not sure but my issue seems fairly different based on the description in #14088. My issue can be reproduced on Mac, Windows, and Linux 1.6. I have not tried 1.7. The failure is definitely GC related as the tests do not fail until there is heap memory pressure.

However, as long as you are willing to make sure this issue is fixed along with #14088, I'm happy :-)

Thanks

[spring-projects-issues]

Scott Bartram commented

It appears to me that this code in ExtendedBeanInfo is incorrect:

// is the method a NON-INDEXED setter? ignore return type in order to capture non-void signatures
if (method.getName().startsWith("set") && method.getParameterTypes().length == 1) {}

A method such as void setFoo(Foo[] arr) is an indexed setter. The subsequent call to

this.addOrUpdatePropertyDescriptor(pd, propertyName, readMethod, method);

causes the IntrospectionException because it is passing null for the indexedReadMethod and indexedWriteMethod when it eventually calls this code:

void addOrUpdatePropertyDescriptor(PropertyDescriptor pd, String propertyName, Method readMethod, Method writeMethod, Method indexedReadMethod, Method indexedWriteMethod)

[spring-projects-issues]

Scott Bartram commented

I tested my code under 3.2.0.BUILD-SNAPSHOT and 3.1.3.BUILD-SNAPSHOT and it is still failing with the same error.

[spring-projects-issues]

Chris Beams commented

Hi Scott,

I'm particularly surprised to hear that you're still experiencing this under 3.2.0.BUILD-SNAPSHOT, as ExtendedBeanInfo is now out of the code path entirely unless you're actually wiring up objects that have non-void returning JavaBeans setter methods (which is pretty rare, and usually an intentional act).

Perhaps it would be best if you put together that reproduction project after all. Feel free to follow the instructions at the spring-framework-issues repository, or simply attach a self-contained project here - whichever is easiest for you.

[spring-projects-issues]

Scott Bartram commented

My test code is checked into the issues repo under #14336.

[spring-projects-issues]

Chris Beams commented

Thanks, Scott. Per https://github.com/SpringSource/spring-framework-issues/tree/master/SPR-9702, I've indeed just confirmed that your problem persists under 3.2.0.M2. My apologies that your repro project slipped through the cracks. Will dig back into this for 3.2 RC1 / 3.1.3 (which will very likely co-release in early October).

[spring-projects-issues]

Scott Bartram commented

Any chance of getting this fixed for 3.1.4 or 3.2?

[spring-projects-issues]

Chris Beams commented

now scheduled for 3.2 RC2

[spring-projects-issues]

Chris Beams commented

Scott, this issue is resolved based on the changes in #14663. These changes have been backported to 3.1.4 as well. Please give 3.1.4.BUILD-SNAPSHOT and/or 3.2.0.BUILD-SNAPSHOT a try and let us know how it goes. Thanks!

[spring-projects-issues]

Sean Brandt commented

This also doesn't appear to work with regards to a BigDecimal class ( with it's admittedly broken api as far as setters/getters go ) due to the setScale(*) methods, where it used to work prior to these non-void return method changes.

[spring-projects-issues]

Sean Brandt commented

Just to clarify this fails by simply calling BeanUtils.getPropertyDescriptors(BigDecimal.class) in 3.1.4.BUILD-SNAPSHOT as of today.

I might also suggest that this was a .. not very well thought out approach to resolving this problem. Some method for builder classes to elect for special treatment would have had far less far reaching effect on existing codebases attempting to upgrade. ( For instance an annotation @BuilderBean or some such ).

[spring-projects-issues]

Sean Brandt commented

This issue is still broken, calls to BeanUtils.getPropertyDescriptors(clazz) with non void setter methods that aren't javabean spec compliant (otherwise) causes spurious errors where previous versions of this class do not.

For instance: BeanUtils.getPropertyDescriptors(BigDecimal.class) fails because of the setScale(...) methods.

[spring-projects-issues]

Scott Bartram commented

Chris, our application is still broken due to the issues described above - BigDecimal, etc.

[spring-projects-issues]

Chris Beams commented

Sean, Scott,

I am unable to reproduce this under 3.1.3.RELEASE or 3.1.3.BUILD-SNAPSHOT, i.e. he following causes no exception:

@Test
public void test() {
     BeanUtils.getPropertyDescriptors(BigDecimal.class);
}

Note there is already a reproduction project at https://github.com/SpringSource/spring-framework-issues/tree/master/SPR-9702. Feel free to add a new test case there to demonstrate.