struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <>
Subject Re: [OT] PropertyUtils internals (Re: Select Multiple Issues)
Date Tue, 25 Jan 2005 15:45:25 GMT
At 7:58 AM -0700 1/25/05, Larry Meadors wrote:
>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.

Actually, for quite a while now, the important parts of BeanUtils 
have been performed by instances: BeanUtilsBean, PropertyUtilsBean, 
ConvertUtilsBean etc.  The static methods just do this against a 
singleton instance.  A lot of legacy code continues to use the static 
methods, but you're not stuck with it.

Given this, (1) is manageable also; you can register an 
IntegerConverter with a default value of null.  I'm not sure what it 
would do if you registered it against Integer.TYPE, but it should 
work against Integer.class.

Now, Struts is one of the places with legacy code which uses the 
static methods.  If you decide to get into this, your suggestions on 
how Struts might make it easier for you to configure these things 
would be welcomed.  It might be as simple as creating a chain command 
which could be used in place of the current PopulateForm step, or 
pursuing an idea Ted mentioned once about putting a populate method 
on ActionForm (although I would want to do this in a way which didn't 
depend directly on HttpServletRequest.)


>On Tue, 25 Jan 2005 08:21:27 -0600, Joe Germuska <> 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
>>  >(, 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.
>>  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 (  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 
>><> wrote:
>  > >>  From: "Will Stranathan" <>
>>  >>
>>  >>  > Well, I understand the way HTTP is working there, it just SEEMS to
>>  >>  > 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:
>>  >For additional commands, e-mail:
>>  --
>>  Joe Germuska
>>  "Narrow minds are weapons made for mass destruction"  -The Ex
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail:
>>  For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

Joe Germuska       
"Narrow minds are weapons made for mass destruction"  -The Ex

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message