There is a defect: https://issues.apache.org/jira/browse/BEANUTILS-541 Briefly: FluentPropertyBeanIntrospector changes statically cached (internal cache of java.beans.Introspector) PropertyDescriptor and it leads to failure if base POJO has two subclasses (see example in ticket).
Proposed solution: 1) For 1.x version generation it can be simply workarounded, the PR is here: https://github.com/apache/commons-beanutils/pull/69 It just makes a call that evicts cached PropertyDescriptor in the static cache of java.beans.Introspector. Keeping in mind back compatibility policy I assume that it can be enough. 2) For 2.x we can have several strategies since there is no major release yet. 2.A) Simple - the same as 1.x just make the same workaround https://github.com/apache/commons-beanutils/pull/68 As an initial effort just to avoid 2.0 release with the defect it can be accepted now and then enhanced with plan 2.B) or plan 2.C) 2.B) Change the implementation of org.apache.commons.beanutils.DefaultBeanIntrospector with own resolver (note: it may support fluent setters by default) and own cache instead of current impl Introspector.getBeanInfo(icontext.getTargetClass()). The cache will keep PropertyDescriptor for target class, not just all parents hierarchy separately like it is now. 2.C) The same as 2.B) but it can be enriched by complicated logic that supports Generic type reify (current implementation does not), Collection types with generics, etc. The reference implementation can smth like "springframework:spring-beans" BeanUtils.getPropertyDescriptors(Class<?>), or "com.fasterxml:classmate" I have some drafts with implementation based on it and can prepare some initial proposals (will take some time). IMHO, the best option will be 2.c), because there is no such strict contracts of back compatibility, and there is a chance to make it much more powerful.
