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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]>
