3 Replies Latest reply: Aug 19, 2010 5:14 PM by 843807 RSS

    Hierarchy vs. BeanInfo

      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
          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
            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
              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:
                  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.