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 37987]  - [beanutils] Proposition for "controlled"
 copy of bean properties
In-Reply-To: <bug-37987-7685@http.issues.apache.org/bugzilla/>
Message-Id: <20051221141730.2767BCB@ajax.apache.org>
Date: Wed, 21 Dec 2005 15:17:30 +0100 (CET)

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=37987>.
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=37987


------- Additional Comments From adelino.rodrigues@emea.eu.int  2005-12-21 15:17 -------
(In reply to comment #1)
> I don't understand how this behavior is inconsistent.  Only the matching (same
> name and type) properties can be copied.  So, case 3, IMO is fine the way it's
> implemented.  A Project object doesn't have a purchaseNr property, so the
> purchaseNr property can't be copied from the PurchaseItem object to the 
Project
> object.  However, what I do think might be nice is if we had an additional
> parameter to copyProperties() which specified exactly which properties to copy
> (a collection/array of Strings which specified the property names).  This 
would
> be a bit more flexible, because there could be instances where you can't use a
> class/interface to specify which properties to copy (you don't want to copy 
the
> "id" property for instance).  Would that work for you?  We could actually
> provide both, I guess so that you wouldn't have to manually construct the
> collection of property names by hand.

For instance you get (EditablePriceableItem a, EditablePriceableItem b) as
parameters of a function. The only you know about it is that they are instances
 of EditablePriceableItem. Thus when copying a to b using introspections you 
don't want to alter properties that are outside of your scope: here the 
interface EditablePriceableItem.

A 3rd argument, as you propose (and as proposed in enhancement 32642), would do 
the job.
Neverthless, getting a list of property names from an interface that 
potentially extends several other interfaces is not trivial. It would then be 
very handy to have an helper method such as:

getReadableProperties(Class aclass): List/or array
getSettableProperties(Class aclass): List/or array


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