[beanutils] FluentPropertyBeanIntrospector issue

[Sergey Chernov <se...@gmail.com>]

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.