So somebody upgrading from struts 1.0 is effectively upgrading from
Struts 1.1 depends on beanutils 1.6, which has the new "map-only" behaviour.
The question is: how many people will strike the problem Thomas did? ie be
upgrading from Struts 1.0, and have classes that both implement Map and have
properties? [I'm not forgetting other beanutils apps may have compatibility
problems too, but struts is by far the largest beanutils user AFAIK]
Struts 1.1 was released in March 2003 it looks like. So struts 1.0 is two years
old. It does seem like a reasonable number of people will be upgrading.
I have absolutely no idea how common it is to have a class that both implements
Map and has properties. But obviously Thomas does. And so did the filer of
bugzilla #14440; in that case he was trying to read from an instance of class
org.apache.util.Criteria. Any idea where that class comes from??? Any idea how
common it is to manipulate classes that implement Map? [in many years of Java
programming, I don't think I've ever done that].
If it's not common then an alternative is just to document that users can
subclass PropertyUtilsBean, and override the setNestedProperty method as shown
by Thomas below. They can then set their custom class up via this:
ConvertUtilsBean convertUtilsBean = new ConvertUtilsBean();
MyPropertyUtilsBean propertyUtilsBean = new MyPropertyUtilsBean();
BeanUtilsBean myBeanUtilsBean = new BeanUtilsBean(
[I think that will work...]
Unless there are a lot of people who will be bitten by this issue, I'm leaning
towards documenting the above workaround rather than modifying PropertyUtils
now. The workaround is only about 1 page of code after all. Maybe we could even
refactor setNestedProperty/getNestedProperty a bit to make overriding easier,
without actually having to build alternative behaviours into PropertyUtils itself?