This discussion is archived
3 Replies Latest reply: Aug 19, 2010 3:14 PM by 843807 RSS

Hierarchy vs. BeanInfo

843807 Newbie
Currently Being Moderated
Some of these beans have an inheritance hierarchy.

One could build a BeanInfo inheritance hierarchy in parallel with the beans, but one's BeanInfo classes may already have a hierarchy.

Or the BeanInfo class for each concrete class could express all the properties of interest in the hierarchy - which could be a lot of duplicate information!

Or will the Introspector find a BeanInfo class for a superclass? E.g.
class SuperClass {
  property foo;
  property decaf; // not interesting
}
class ConcreteClass extends SuperClass {
  property bar;}
}

class SuperClassBeanInfo extends SimpleBeanInfo {
  describes foo;
  // does not describe decaf;
}

class ConcreteClassBeanInfo extends SimpleBeanInfo { // not SuperClassBeanInfo 
  describes bar;
}
If I do
Introspector.getBeanInfo( ConcreteClass.class, Object.class ), 
will I get decaf, or will the Introspector find SuperClassBeanInfo and suppress it?
  • 1. Re: Hierarchy vs. BeanInfo
    EJP Guru
    Currently Being Moderated
    You don't need to respecify inherited properties. Again I forget the details but between the three overloads of getBeanInfo() you can do it all.
  • 2. Re: Hierarchy vs. BeanInfo
    843807 Newbie
    Currently Being Moderated
    To answer my own question, yes.

    If you define the BeanInfo classes as I've illustrated above, The Instrospector will not report decaf as a property.
  • 3. Re: Hierarchy vs. BeanInfo
    843807 Newbie
    Currently Being Moderated
    A little more detail on this. So far I've found only one way to achieve what I wanted in the OP. You have to create BeanInfo classes for the parts of the hierarchy you want to filter.

    The Introspector behaves differently if there is a BeanInfo class for the bean or if there isn't.

    If there is no BeanInfo, the Introspector climbs the inheritance hierarchy reporting all discovered beaninfo until it either finds a class with a BeanInfo class, or hits the stop class (if specified). Thus if you call
    Introspector.getBeanInfo( beanClz );  // no stop class
    on a class with no BeanInfo classes in its hierarrchy, the result will be all properties up to and including Object.

    However, if Introspector discovers explicit properties in a BeanInfo class (that is, the SimpleBeanInfo.getPropertyDescriptors() method is overridden), by default it returns no inherited properties. E.g.

    Object <= class A <= class B <= class C

    If there is a CBeanInfo class with explicit properties, there will be no report of properties for Object, A, or B - unless you explicitly tell it to do so. Here's how: override SimpleBeanInfo.getAdditionalBeanInfo() thusly:
        @Override
        public BeanInfo[] getAdditionalBeanInfo() { 
            try {                 
                return new BeanInfo[] { 
                        Introspector.getBeanInfo( beanClassObj.getSuperclass() )
                                      };  
            } catch( IntrospectionException ex ) {            
                return new BeanInfo[0];            
            } 
        }
    Returning an empty array (as in the catch block) has the same effect as not overriding the method. Specifying a stop class to the Introspector has no effect on the execution of getAdditionalBeanInfo() methods. If BBeanInfo calls getBeanInfo(superclass), the properties of A would be enumerated even if the Introspector was invoked thusly:
    Introspector.getBeanInfo( C.class, A.class );  // ie don't probe above B
    This behavior isn't absolute. It can be modified by using the
    Introspector.getBeanInfo( beanClz, stopClz, flags );
    overload, particularly the IGNORE_ALL_BEANINFO flag.