dcsimg
Bean Introspector (cross-posted from JSP)
0 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Christopher_Schultz
Posted On:   Wednesday, December 18, 2002 07:10 AM

(This has been cross-posted from JSP... please forgive the repetition, but I couldn't attach the question to both groups. The other post is here ) A colleague of mine has just started using the JSTL on a new project. Yesterday, it took us several hours to determine the cause of a bug that we found. He was using a class called Component which was in its own package and trying to iterate over an array of these objects. He got a very strange exception which claimed that the object he was trying to pass to a java.reflect.Method.invoke did not match the Class for this method, which seemed to be java.awt.Component.getName() . He was in fact trying to call his own Component.getName() .    More>>

(This has been cross-posted from JSP... please forgive the repetition, but I couldn't attach the question to both groups. The other post is here )



A colleague of mine has just started using the JSTL on a new project. Yesterday, it took us several hours to determine the cause of a bug that we found.



He was using a class called Component which was in its own package and trying to iterate over an array of these objects. He got a very strange exception which claimed that the object he was trying to pass to a java.reflect.Method.invoke did not match the Class for this method, which seemed to be java.awt.Component.getName() . He was in fact trying to call his own Component.getName() .



It looks like what is happening is that the Bean Introspector was looking for a class called full.package.name.ComponentBeanInfo . In the absence of such a class, it begins looking for a class called ComponentBeanInfo in any package within the bean info search path.



It turns out that a BeanInfo class is quickly found for java.awt.Component , and the Introspector gives up looking for any more BeanInfo classes. Had it not found a BeanInfo class, it would have used reflection to glean the property getter names from the class itself.



There are two obvious solutions to this problem.




  1. Create a BeanInfo class for this class and others that will be used with the JSTL
  2. Change the bean info search path


Solution 2 doesn’t sound like a great idea since JavaBeans can be used anywhere and we may interrupt some important functionality or at least degrade performance since reflection is slower than the static method calls that would be used on a BeanInfo object.



Solution 1 is tedious. We don’t want to create fully blown beans for each and every class we intend to use with the JSTL. What about classes already in the standard Java library that you want to use? There are 230 classes in the standard Java 1.4 class library that are repeated at least once. In which order might the Introspector find them? You can’t always create a BeanInfo class for an existing class, especially one that exists in the java.* namespace.



Another potential solution is to simply write BeanInfo classes for only those classes which conflict, such as the Component class in question. That would be a reasonable idea, except that the standard Java library keeps growing with every release. What happens if Sun decides to package a new class with the JDK called Person, and includes a BeanInfo class in the bean info path? That may break code that was, until that version, working correctly.



We’d rather not write BeanInfo classes for every object that we might use with the JSTL. I’m assuming that this problem exists with the standard tags as well, since I think that uses the Introspector as well.



Does anyone have any bright ideas?



-chris
   <<Less
About | Sitemap | Contact