The concept of ToStringBuilder and EqualsBuilder ist good, but not completely suited for BeanUtils - the reflection pattern used does not consider the accessor methods for beans.
If your extended dynabean does the explicit use of the lang.builder code w/o the reflection parts, it should suite the bean use pattern. A dependency of beanutils on lang will need acceptance voting from the committers (to me seems to be OK, since lang is even lower level than beans).
It might be sensible to factor out parts from the lang.builder implementations to be then subclassed once for beans and once for full filed reflection usage?
Just my 2c!
Craig R. McClanahan wrote:
On Tue, 3 Jun 2003, Steven Caswell wrote:
Date: Tue, 3 Jun 2003 20:32:26 -0400 From: Steven Caswell <[EMAIL PROTECTED]> Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>, [EMAIL PROTECTED] To: Jakarta Commons Developers List <[EMAIL PROTECTED]> Subject: [beanutils] extending BasicDynaBean with toString, equals, and hashCode
I've written an extended dynabean class that extends (actually, wraps) BasicDynaBean to add toString and equals. The toString method uses commons.lang.ToStringBuilder to build the toString, and commons.lang.EqualsBuilder to perform the equals comparison. I know it needs hashCode, I just haven't taken the time to add it yet.
Is there any interest in having this class donated to commons-beanutils?
Conceptually, I like the idea. My only concern is that it would introduce a dependency on commons-lang that does not currently exist in beanutils.
Steven Caswell
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- :) Christoph Reck
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
