ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kris Schneider" <kschnei...@gmail.com>
Subject Re: Lack of BeanInfo support
Date Tue, 10 Oct 2006 02:47:31 GMT
On 10/9/06, Clinton Begin <clinton.begin@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 <kschneider@gmail.com> wrote:
> > On 10/9/06, Clinton Begin <clinton.begin@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 <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>
> >
> > --
> > Kris Schneider <mailto: kschneider@gmail.com>

-- 
Kris Schneider <mailto:kschneider@gmail.com>

Mime
View raw message