Should PropertyUtilsBean catch NoSuchMethodException?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Should PropertyUtilsBean catch NoSuchMethodException?

Will Pugh
Hi,

I ran into a problem when using CGLib and Beanutils.  The gist seems to
be CGLib adds a number of getters and setters, but in particularly, it adds

       Callback[]  getCallbacks()
       void           setCallbacks(Callback[])
       Callback    getCallback(int)
       void           setCallback(Callback)

It seems a little troubling that they dropped the "s" in the singular
case (since they end up working with the same properties anyways).  
However, I now get a wacky problem in that BeanUtils.copyProperties()
now works as I would expect, but BeanUtils.clone() does not work.

This discreperency seems to be that one calls
BeanUtilsBean.copyProperties and the other calls
PropertyUtilsBean.copyPropteries.

It would appear that both implementations of copyProperty have the
problem where they use isReadable to determine if they can read a
property, but use getSimpleProperty to get the property.  The problem
here is that isReadable returns true even if the property is an indexed
property, however, in such a case getSimpleProperty throws an exception.

BeanUtilsBean.copyProperties catches this exception.  
PropertyUtilsBean.copyProperties does not.  Is there a reason for this
discreperency?  Also, as a side note, why are there two copyProperties
methods?  What are supposed to be the differences between the two?



    Thanks,
    --Will

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [beanutils] Should PropertyUtilsBean catch NoSuchMethodException?

Wendy Smoak-4
From: "Will Pugh" <[hidden email]>
> I ran into a problem when using CGLib and Beanutils.  The gist seems to
> be CGLib adds a number of getters and setters, but in particularly, it
adds
>
>        Callback[]  getCallbacks()
>        void           setCallbacks(Callback[])
>        Callback    getCallback(int)
>        void           setCallback(Callback)
>
> It seems a little troubling that they dropped the "s" in the singular
> case (since they end up working with the same properties anyways).

More than troubling.  A class with these methods is not compliant with the
JavaBeans specification, so BeanUtils can't be expected to work right.

This will be seen as two separate properties.  The Callback[] pair is fine.
The other pair of methods, taken by themselves, aren't valid due to the
'int' parameter in the 'get' method.

Do you have any control over this code?  IMO it needs to be changed to
four methods with the same property name and the proper signatures for an
indexed property:

From Section 7.2 of the JavaBeans 1.01 Specification:
   For indexed properties the accessor type signatures are:
      void setter(int index, PropertyType value); // indexed setter
      PropertyType getter(int index); // indexed getter
      void setter(PropertyType values[]); // array setter
      PropertyType[] getter(); // array getter

--
Wendy Smoak


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [beanutils] Should PropertyUtilsBean catch NoSuchMethodException?

Will Pugh
I sent off a mail to the CGLib alias to see if there is any workaround.

I am still a bit perplexed about the differences between
BeanUtilBean.copyProperties and PropertyUtilBean.copyProperties, why are
they different?  Why are there two?  I noticed that the copyProperties
in BeanUtilBean is more complicated (in that it can deal with
expressions) but copyProperties will never actually send it expressions
any more complicated than property name.  The only other difference I
see is that BeanUtilBean.copyProperty will try to convert a property in
the case you have same name different types rather then just exploding.  
Is there a reason PropertyUtilBean.copyProperties does not want to convert?

    --Will


Wendy Smoak wrote:

>From: "Will Pugh" <[hidden email]>
>  
>
>>I ran into a problem when using CGLib and Beanutils.  The gist seems to
>>be CGLib adds a number of getters and setters, but in particularly, it
>>    
>>
>adds
>  
>
>>       Callback[]  getCallbacks()
>>       void           setCallbacks(Callback[])
>>       Callback    getCallback(int)
>>       void           setCallback(Callback)
>>
>>It seems a little troubling that they dropped the "s" in the singular
>>case (since they end up working with the same properties anyways).
>>    
>>
>
>More than troubling.  A class with these methods is not compliant with the
>JavaBeans specification, so BeanUtils can't be expected to work right.
>
>This will be seen as two separate properties.  The Callback[] pair is fine.
>The other pair of methods, taken by themselves, aren't valid due to the
>'int' parameter in the 'get' method.
>
>Do you have any control over this code?  IMO it needs to be changed to
>four methods with the same property name and the proper signatures for an
>indexed property:
>
>>From Section 7.2 of the JavaBeans 1.01 Specification:
>   For indexed properties the accessor type signatures are:
>      void setter(int index, PropertyType value); // indexed setter
>      PropertyType getter(int index); // indexed getter
>      void setter(PropertyType values[]); // array setter
>      PropertyType[] getter(); // array getter
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [beanutils] Should PropertyUtilsBean catch NoSuchMethodException?

Simon Kitching
On Fri, 2005-06-17 at 15:36 -0700, Will Pugh wrote:

> I sent off a mail to the CGLib alias to see if there is any workaround.
>
> I am still a bit perplexed about the differences between
> BeanUtilBean.copyProperties and PropertyUtilBean.copyProperties, why are
> they different?  Why are there two?  I noticed that the copyProperties
> in BeanUtilBean is more complicated (in that it can deal with
> expressions) but copyProperties will never actually send it expressions
> any more complicated than property name.  The only other difference I
> see is that BeanUtilBean.copyProperty will try to convert a property in
> the case you have same name different types rather then just exploding.  
> Is there a reason PropertyUtilBean.copyProperties does not want to convert?


>From the javadocs for BeanUtilBean.copyProperties:
 * <p>If you know that no type conversions are required, the
 * <code>copyProperties()</code> method in {@link PropertyUtils} will
 * execute faster than this method.</p>

Sometimes you don't want type conversion to occur; you know there is no need for it
so there's no point in calling a method that might try to do type conversion.

Nothing in the entire PropertyUtilBean class uses ConvertUtils.

And when cloning a bean you obviously don't need typeconversion; by
definition the target properties for the copy have the same types as the
source properties. So BeanUtilsBean.clone calls the faster and simpler
method.

I agree with Wendy about CGLib method naming being in violation of the
javabeans standard. You can probably work around this for the meantime
by defining a BeanInfo class for the problem class, but pushing CGLib to
fix their class is a good idea.

As for why BeanUtilsBean.copyProperties catches exceptions from
getSimpleProperty while PropertyUtilsBean.copyProperties does not -
well, yes they should probably have been consistent. No doubt they were
written months apart, possibly by different people, and just weren't
done quite the same. However fixing this isn't likely now as changing
either behaviour would probably fall into the category of
non-backwards-compatible-change. And anyway the problem will only be
caused by non-javabeans-compliant input classes, so the real fix is
fixing the bean you're trying to copy.

Note that BeanUtils isn't the best designed of libraries; it really
needs a rewrite. However there's an extremely low probability of that
happening.


Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]