DO NOT REPLY [Bug 23815] - [beanutils] PropertyUtils.getNestedProperty() doesn't allow getXxxx on Map-Instances any longer

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

DO NOT REPLY [Bug 23815] - [beanutils] PropertyUtils.getNestedProperty() doesn't allow getXxxx on Map-Instances any longer

Bugzilla from bugzilla@apache.org
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG?
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=23815>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND?
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23815





------- Additional Comments From [hidden email]  2005-05-28 08:03 -------
Thanks Niall.

So somebody upgrading from struts 1.0 is effectively upgrading from
beanutils-pre-1.0.

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(
     convertUtilsBean, propertyUtilsBean);
  BeanUtilsBean.setInstance(myBeanUtilsBean);

[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?

--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]