ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clinton Begin" <clinton.be...@gmail.com>
Subject Re: Lack of BeanInfo support
Date Mon, 09 Oct 2006 23:28:10 GMT
Only two reasons:

1) Performance.  At the time (not sure about now) ClassInfo was much faster
than BeanUtils.
2) More important -- I never thought in a million years anyone would ever
touch that nightmare of an API ... BeanInfo.

Seriously...I would strongly recommend you avoid that stuff.  You're
wandering a path full of complexity and verbosity with very little benefit.

Don't fall for "Sun Standards".  I did, and iBATIS is worse for it.

Cheers,
Clinton



On 10/9/06, Kris Schneider <kschneider@gmail.com> wrote:
>
> Not sure if this should be a dev list discussion, but I'll start it
> here and see where it leads...
>
> I guess I never realized this, but iBATIS doesn't seem to honor
> BeanInfo classes. For example, given this class:
>
> public class Foo {
>     private String name;
>     public String name() { return this.name; }
>     public void name(String name) { this.name = name; }
> }
>
> and its BeanInfo:
>
> import java.beans.*;
> import java.lang.reflect.*;
> public class FooBeanInfo extends SimpleBeanInfo {
>     private static final Class BEAN_CLASS = Foo.class;
>     public PropertyDescriptor[] getPropertyDescriptors() {
>         PropertyDescriptor[] props = null;
>         try {
>             Method nameReadMethod = BEAN_CLASS.getDeclaredMethod("name",
> null);
>             Method nameWriteMethod =
> BEAN_CLASS.getDeclaredMethod("name", new Class[] { String.class });
>             props = new PropertyDescriptor[] { new
> PropertyDescriptor("name", nameReadMethod, nameWriteMethod) };
>         } catch (NoSuchMethodException ignore) {
>         } catch (IntrospectionException ignore) {
>         }
>         return props;
>     }
> }
>
> com.ibatis.common.beans.ClassInfo reports that the bean has a single,
> read-only property called "class". However, java.beans.Introspector
> reports that it has a read/write property called "name". Was there a
> reason to ignore the existing JavaBeans framework and implement custom
> introspection? I can understand the need to extend the core JavaBeans
> framework to support features like List-based indexed properties or
> mapped properties, but that can be done without breaking
> compatibility. For example, Jakarta Commons BeanUtils implements both
> of those previously mentioned features, but also honors BeanInfo.
>
> In addition, if someone wanted to override the current implementation,
> I don't see a way to plug in a different Probe/ProbeFactory. Is there
> any way to do that?
>
> Thanks.
>
> --
> Kris Schneider <mailto:kschneider@gmail.com>
>

Mime
View raw message