Chris Beams opened SPR-9723 and commented

Create an ExtendedBeanInfoFactory that inspects a given bean class, determining whether that bean class is a candidate for EBI's functionality. i.e. does the bean class have non-void returning setter methods?

If so, handle the class and return an ExtendedBeanInfo.

If not, return false from from ExtendedBeanInfo#supports(Class) and have CachedIntrospectionResults fall back to the default Introspector#getBeanInfo.

This will resolve a number of open issues that are essentially regressions due to the introduction of ExtendedBeanInfo. The issues with ExtendedBeanInfo should of course also be fixed, but getting EBI out of the execution path for classes that don't need it means better performance and lower risk of bugs in the future.

An open question is whether the ExtendedBeanInfoFactory should be discovered via the META-INF/spring.beanInfoFactories mechanism, or simply hard-coded. In either case, it will always be picked up. Hard coding it means explicitness, type safety, etc. Discovery via META-INF means that there is a prominent example of the mechanism that others can look to without digging into tests.

Issue Links:

• Introduce strategy for BeanInfo creation [SPR-9677] #14311 Introduce strategy for BeanInfo creation ("depends on")
• Support injection against setter methods with non-void return types [SPR-8079] #12734 Support injection against setter methods with non-void return types
• Overhaul non-void JavaBean write method support [SPR-10029] #14663 Overhaul non-void JavaBean write method support

Referenced from: commits spring-attic/spring-framework-issues@114ca5c