There are two things about BU that irritate me (and that is the level
- irritation, not a show stopper by any stretch of the imagination).

1) If I have an Integer (or any Number subclass) property, and someone
keys in "joe", BU turns it into 0 by default. That is the last thing I
want it to do. Zero is a number, "joe" is not - BU should not try to
make it one, it should be null.

2) The static nature of BU makes it a bit funky to customize. I have
not tried to do this myself, but several developers who I know have,
and cuss about it. It would be cool to be able to specify property
conversions at a more granular level - not at the classloader (i.e.,
static) level.

Larry

On Tue, 25 Jan 2005 08:21:27 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> At 9:14 PM -0700 1/24/05, Larry Meadors wrote:
> >Nope, actually, it is bean-utils that is at fault here (something all
> >struts developers should be accustomed to saying - IMO, bean-utils is
> >the single weakest component in struts).
> >
> >According to the javabeans specification
> >(http://java.sun.com/products/javabeans/docs/spec.html), indexed
> >properties should look like this:
> >
> >1) void setter(int index, PropertyType value); // indexed setter
> >2) PropertyType getter(int index); // indexed getter
> >3) void setter(PropertyType values[]); // array setter
> >4) PropertyType[] getter(); // array getter
> >
> >But the last time I looked, bean-utils never used the indexed
> >getter/setter methods (#1 or #2) - in fact, it never even called the
> >array setter (#3). Instead, it got a reference to the array by calling
> >method #4, and set the elements in it directly.
> 
> I haven't actually looked at this in a running debugger, or with log
> output, but the code which governs this ultimately is
> PropertyUtilsbean.setIndexedProperty(...)  If you look at the code,
> you'll see that it uses an IndexedPropertyDescriptor if that's what
> the Java introspector returns when asked for the write method for the
> given property.  The "#4" option is only used when the Introspector
> returns a PropertyDescriptor which is not also an
> IndexedPropertyDescriptor.
> 
> http://cvs.apache.org/viewcvs.cgi/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java?view=markup
> 
> So, I'm wondering what has you so bothered about beanutils?  There
> was some discussion about a year ago about trying to apply some of
> the strengths of the cglib project to make beanutils better, but that
> hasn't seemed to go anywhere (http://cglib.sourceforge.net).  My
> understanding is that cglib is a much higher performing way of doing
> introspection, but I haven't spent much time looking at it, or how it
> might fit in with (or replace) beanutils.
> 
> Joe
> 
> >Larry
> >
> >On Mon, 24 Jan 2005 15:39:44 -0700, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> >>  From: "Will Stranathan" <[EMAIL PROTECTED]>
> >>
> >>  > Well, I understand the way HTTP is working there, it just SEEMS to be
> >>  > that having the additional method (setBar(int, String)) confused
> >>  > BeanUtils or something - because removing those methods (making no
> >>  > other changes) cleared the problem up.
> >>
> >>  Your original code violated the JavaBeans specification-- you're only
> >>  allowed one pair of get/set methods, and the types have to match. (Boolean
> >>  properties have slightly different rules.)  Any additional methods will, 
> >> as
> >>  you found out, confuse the introspection process.
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> 
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction"  -The Ex
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to