JDK-4750368 : Introspector not returning the correct BeanInfo for class name collision
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.beans
  • Affected Version: 1.4.0,1.4.0_01,1.4.1
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_nt,windows_2000
  • CPU: generic,x86
  • Submitted: 2002-09-19
  • Updated: 2002-10-19
  • Resolved: 2002-10-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
Seems like a duplicate of 4346874 but this time a simple solution is provided.

Rich, the developer here who works most with the introspector has been
trying to fix a bug recently that occurs where users create a class that
has the same name as one that exists that has a BeanInfo class defined for
it.  For example, suppose there is the class somepackage.WindowBeanInfo
that is in the introspector's search path designed to provide the
descriptors for java.awt.Window.  The user may create their own class
called com.mycorp.myapp.Window, and what occurs is that the introspector
picks up the WindowBeanInfo class designed for the AWT class.  This is
causing us problems because the property sheet shows the wrong set of
details, the icon and customizer are from the wrong class, etc....  The
best fix seems to be in the Introspector itself that actually checks the
value of getBeanClass() in the bean descriptor before using the incorrect
BeanInfo as a match. 

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis
14-06-2004

SUGGESTED FIX private static synchronized BeanInfo findInformant(Class beanClass) { String name = beanClass.getName() + "BeanInfo"; try { return (java.beans.BeanInfo)instantiate(beanClass, name); } catch (Exception ex) { // Just drop through } // Now try checking if the bean is its own BeanInfo. try { if (isSubclass(beanClass, java.beans.BeanInfo.class)) { return (java.beans.BeanInfo)beanClass.newInstance(); } } catch (Exception ex) { // Just drop through } // Now try looking for <searchPath>.fooBeanInfo while (name.indexOf('.') > 0) { name = name.substring(name.indexOf('.')+1); } for (int i = 0; i < searchPath.length; i++) { try { String fullName = searchPath[i] + "." + name; ---------> New section replacing old code java.beans.BeanInfo bi = (java.beans.BeanInfo)instantiate(beanClass, fullName); if (bi.getBeanDescriptor().getBeanClass() == beanClass) return bi; <--------- End of new section } catch (Exception ex) { // Silently ignore any errors. } }
11-06-2004

PUBLIC COMMENTS .
10-06-2004

EVALUATION The fix is really elegant: don't return the BeanInfo unless it represents the class that it encapsulates in the BeanDescriptor. This is a fairly simple fix and doesn't require the work arounds presented in 4346874. ###@###.### 2002-09-19
19-09-2002