>> 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 <[EMAIL PROTECTED]> wrote:
On 10/9/06, Clinton Begin <[EMAIL PROTECTED]> 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 <[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]>
--
Kris Schneider <mailto: [EMAIL PROTECTED]>
