You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Kris Schneider <ks...@gmail.com> on 2006/10/09 21:53:07 UTC
Lack of BeanInfo support
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 <ma...@gmail.com>
Re: Lack of BeanInfo support
Posted by Kris Schneider <ks...@gmail.com>.
On 10/9/06, Clinton Begin <cl...@gmail.com> wrote:
> >> I haven't, but I think the JavaBeans standard is actually much more
> >> pervasive than most folks realize
>
> Which is a very good thing. I'm quite familiar with the full spec, and I'm
> very happy that 99% of Java developers only know (or at least use) 1% of it.
I suppose I get the part about using only a small percentage of the
capabilities, but I'd personally be happier if more developers had a
more complete understanding of the spec. Even (especially?) if they
come to the conclusion that it's to be avoided.
> >> How about the possibility of plugging-in custom Probe/ProbeFactory
> >> impls? I'm assuming that would be a feature request?
>
> Yes...but to be honest, that wouldn't come any time soon. There is already
> an interface called Probe that I beleve most of the iBATIS code uses as a
> facade in front of ClassInfo.
I'm sure it wouldn't be a high priority. The Probe interface is fine,
it looks like the real roadblock to custimization is actually
ProbeFactory.
> Cheers,
> Clinton
>
>
> On 10/9/06, Kris Schneider <ks...@gmail.com> wrote:
> > On 10/9/06, Clinton Begin <cl...@gmail.com> wrote:
> > > Only two reasons:
> > >
> > > 1) Performance. At the time (not sure about now) ClassInfo was much
> faster
> > > than BeanUtils.
> >
> > Understood. I wasn't suggesting that iBATIS should use BeanUtils, it
> > was just an example of extending JavaBeans while maintaining
> > compatibility.
> >
> > > 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.
> >
> > I haven't, but I think the JavaBeans standard is actually much more
> > pervasive than most folks realize, especially in the J2EE world (and
> > no, I'm not confusing JavaBeans with EJB). I won't claim to have seen
> > widespread use of the BeanInfo facilities though.
> >
> > How about the possibility of plugging-in custom Probe/ProbeFactory
> > impls? I'm assuming that would be a feature request?
> >
> > > Cheers,
> > > Clinton
> >
> > Thanks for the feedback.
> >
> > > On 10/9/06, Kris Schneider <ks...@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 <ma...@gmail.com>
> >
> > --
> > Kris Schneider <mailto: kschneider@gmail.com>
--
Kris Schneider <ma...@gmail.com>
Re: Lack of BeanInfo support
Posted by Clinton Begin <cl...@gmail.com>.
>> I haven't, but I think the JavaBeans standard is actually much more
>> pervasive than most folks realize
Which is a very good thing. I'm quite familiar with the full spec, and I'm
very happy that 99% of Java developers only know (or at least use) 1% of
it.
>> How about the possibility of plugging-in custom Probe/ProbeFactory
>> impls? I'm assuming that would be a feature request?
Yes...but to be honest, that wouldn't come any time soon. There is already
an interface called Probe that I beleve most of the iBATIS code uses as a
facade in front of ClassInfo.
Cheers,
Clinton
On 10/9/06, Kris Schneider <ks...@gmail.com> wrote:
>
> On 10/9/06, Clinton Begin <cl...@gmail.com> wrote:
> > Only two reasons:
> >
> > 1) Performance. At the time (not sure about now) ClassInfo was much
> faster
> > than BeanUtils.
>
> Understood. I wasn't suggesting that iBATIS should use BeanUtils, it
> was just an example of extending JavaBeans while maintaining
> compatibility.
>
> > 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.
>
> I haven't, but I think the JavaBeans standard is actually much more
> pervasive than most folks realize, especially in the J2EE world (and
> no, I'm not confusing JavaBeans with EJB). I won't claim to have seen
> widespread use of the BeanInfo facilities though.
>
> How about the possibility of plugging-in custom Probe/ProbeFactory
> impls? I'm assuming that would be a feature request?
>
> > Cheers,
> > Clinton
>
> Thanks for the feedback.
>
> > On 10/9/06, Kris Schneider <ks...@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 <ma...@gmail.com>
>
> --
> Kris Schneider <ma...@gmail.com>
>
Re: Lack of BeanInfo support
Posted by Kris Schneider <ks...@gmail.com>.
On 10/9/06, Clinton Begin <cl...@gmail.com> wrote:
> Only two reasons:
>
> 1) Performance. At the time (not sure about now) ClassInfo was much faster
> than BeanUtils.
Understood. I wasn't suggesting that iBATIS should use BeanUtils, it
was just an example of extending JavaBeans while maintaining
compatibility.
> 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.
I haven't, but I think the JavaBeans standard is actually much more
pervasive than most folks realize, especially in the J2EE world (and
no, I'm not confusing JavaBeans with EJB). I won't claim to have seen
widespread use of the BeanInfo facilities though.
How about the possibility of plugging-in custom Probe/ProbeFactory
impls? I'm assuming that would be a feature request?
> Cheers,
> Clinton
Thanks for the feedback.
> On 10/9/06, Kris Schneider <ks...@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 <ma...@gmail.com>
--
Kris Schneider <ma...@gmail.com>
Re: Lack of BeanInfo support
Posted by Clinton Begin <cl...@gmail.com>.
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 <ks...@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 <ma...@gmail.com>
>