Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
From: bugzilla@apache.org
To: commons-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 23815]  -
    [beanutils] PropertyUtils.getNestedProperty() doesn't allow getXxxx on
 Map-Instances any longer
Message-Id: <20050526090439.CF7D417F@ajax.apache.org>
Date: Thu, 26 May 2005 11:04:39 +0200 (CEST)

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 skitching@apache.org  2005-05-26 11:04 -------
My summary of the situation:

When a lookup string "a.b" is passed to getNestedProperty and a implements the
Map interface then beanutils 1.7 always treats it as a Map only, and calls
a.get(b), even if there is a getB() method available. There is no way to access
the getter methods for standard properties on an object that also implements Map. 

Unfortunately, setNestedProperty acts differently. If a.setB(obj) is available
it gets called even if the object is a Map. Only if there is no appropriate
setter method does it call a.set("b").

This bugzilla request is to make the getter act like the setter.

--beanutils release history
beanutils 1.7 = 2004-08
beanutils 1.6.1 = 2003-02
beanutils 1.6 = 2003-01
beanutils 1.5 = 2002-10
beanutils 1.4 = 2002-08

-- PropertyUtils commit history
* in very early releases, map behaviour was not supported at all.
* r128486 by craigmcc (2001-08-22) added support for classes implementing Map.
However this behaviour was triggered only if "(" was in the name string,eg
"foo.bar(baz)". In other words, this change was backwards-compatible. Format
"a.b" always meant accessing a getB or setB method and never meant using a map
get("b") or set("b") method.
* r128586 (2002-07-16) by craigmcc deliberately changed the interpretation of
a.b to mean a.get("b") if a was a map, in order to be compatible with EL and
JSP2.0. This change was part of release 1.5 and of course broke backwards
compatibility with 1.4.
* r128642 (2002-11-26) by rdonkin introduced a change that made
setNestedProperty check for an explicit setter first before using the map, as a
response to bugzilla#14440. This partially restored compatibility with 1.4 for
setNestedProperty, but forgot to fix getNestedProperty. And it wasn't 100%
compatible with 1.5 as the map would never get updated if a property was
available. This was part of release 1.6.

It's really a rather unfortunate history.

So on to solutions.

We do, alas, need to make 1.7 incompatible with 1.6 :-(. Either we fix
setNestedProperty or we fix getNestedProperty; we clearly can't leave them
inconsistent.

How about we provide an option on class PropertyUtils that lets the user select:
 * map over props
   --> keep 1.6 behaviour for getNestedProperty
   --> breaks 1.6 compatibility with setNestedProperty
   --> the behaviour recommended by Craig McClanahan as being consistent
       with EL and JSP2.0
 * props over map
   --> keep the 1.6 behaviour for setNestedProperty
   --> breaks 1.6 compatibility with getNestedProperty
   --> the behaviour requested by this user and by #14440, and compatible with
       versions 1.4 and earlier.

Which is the default is debateable. I don't mind, and would probably let the
struts team decide.

Users could do
  PropertyUtilsBean.getInstance().setNestedPropertiesBehavior(
	PropertyUtilsBean.PROPS_BEFORE_MAP);
or
  PropertyUtilsBean.getInstance().setNestedPropertiesBehavior(
	PropertyUtilsBean.MAP_BEFORE_PROPS);


We then need to find all places where "if instanceof Map" is done and test the
user-selected behaviour to determine whether to check for a real property of the
specified name first.

Comments?

-- 
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org