Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 87580 invoked from network); 10 Oct 2006 00:47:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 10 Oct 2006 00:47:53 -0000 Received: (qmail 85255 invoked by uid 500); 10 Oct 2006 00:47:50 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 85237 invoked by uid 500); 10 Oct 2006 00:47:50 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 85219 invoked by uid 99); 10 Oct 2006 00:47:50 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Oct 2006 17:47:50 -0700 X-ASF-Spam-Status: No, hits=2.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of clinton.begin@gmail.com designates 64.233.182.186 as permitted sender) Received: from [64.233.182.186] (HELO nf-out-0910.google.com) (64.233.182.186) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Oct 2006 17:47:49 -0700 Received: by nf-out-0910.google.com with SMTP id x30so122907nfb for ; Mon, 09 Oct 2006 17:47:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=X5MoptJ7jBy6O/71bbK+kVl7+9UF0fznNKCJYbtlVCld1zrvIfgOFhMOD9dTh2Wt0KIb3HcrgkxJ6XdD99Glz/q0MeGgzU8BYlKYe+jnRyl7LkN/rLRu1gAk2nQfoEhUCbgyw1RomZVGU/uj8lwIK1BE/9Pmbwx2WWpYMhhuKJc= Received: by 10.49.80.12 with SMTP id h12mr619562nfl; Mon, 09 Oct 2006 17:47:27 -0700 (PDT) Received: by 10.48.48.14 with HTTP; Mon, 9 Oct 2006 17:47:27 -0700 (PDT) Message-ID: <16178eb10610091747l21ceed8y13f96b93d9087dcb@mail.gmail.com> Date: Mon, 9 Oct 2006 18:47:27 -0600 From: "Clinton Begin" To: user-java@ibatis.apache.org Subject: Re: Lack of BeanInfo support In-Reply-To: <3d242a3d0610091742i2f94602fn5745246515ce6535@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_69_14415492.1160441247023" References: <3d242a3d0610091253q23a6c4cbsb5dbf8f97a5b22c1@mail.gmail.com> <16178eb10610091628t7b5e904r8bc5b9b8310b8c74@mail.gmail.com> <3d242a3d0610091742i2f94602fn5745246515ce6535@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_69_14415492.1160441247023 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline >> 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 wrote: > > On 10/9/06, Clinton Begin 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 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 > > -- > Kris Schneider > ------=_Part_69_14415492.1160441247023 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline >> 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 <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>

------=_Part_69_14415492.1160441247023--