Re: Beanswrapper - java.beans.IntrospectionException: type mismatch between read and write methods

Hi John,

what FreeMarker version are you using? There was a corner case problem  
when using FreeMarker with property getters of classes implementing a  
parametrized (generic) interface, see:
<http://www.nabble.com/BeansWrapper-issue-with-%22overlapping%22-getters-td19015364.html 
 >

I fixed that for 2.3.14. If you're experiencing this with 2.3.14 or  
later, then we'll need to dig in further. You're correct that adding  
class/method information to the exception would help - I'll make sure  
to do that regardless of whether you still have the problem post 2.3.14.

As for log warning - we're logging if we can't perform some part of  
introspecting a class, but allow the processing to proceed. Rationale  
being that this particular property will then be inaccessible from the  
template, but others will work, so if no template code uses that  
particular property, it'll keep working. It's just a basic example of  
graceful degradation principle. However, this kind of thing should not  
be happening ordinarily, so we log the warning because there's  
definitely something wrong going on.

As to why does this only occur sporadically -- it actually depends on  
the order of methods and properties being returned in the  
introspection, which in turn relies on the order of methods being  
returned from Class.getMethod(), and it ain't guaranteed by the JVM  
spec to be deterministic, so that might explain it...

Attila.

On 2009.02.19., at 0:14, Newman, John W wrote:

> Hello,
>
> We are using beanswrapper here, and every once in a while (this is  
> very hard to reproduce) I see this stack trace:
>
> java.beans.IntrospectionException: type mismatch between read and  
> write methods
> at  
> java 
> .beans.PropertyDescriptor.findPropertyType(PropertyDescriptor.java: 
> 603)
> at  
> java.beans.PropertyDescriptor.setWriteMethod(PropertyDescriptor.java: 
> 270)
> at java.beans.PropertyDescriptor.<init>(PropertyDescriptor.java:117)
> at  
> freemarker 
> .ext 
> .beans.BeansWrapper.populateClassMapWithBeanInfo(BeansWrapper.java: 
> 1136)
> at  
> freemarker.ext.beans.BeansWrapper.populateClassMap(BeansWrapper.java: 
> 1027)
> at  
> freemarker 
> .ext.beans.BeansWrapper.introspectClassInternal(BeansWrapper.java:965)
> at  
> freemarker.ext.beans.BeansWrapper.introspectClass(BeansWrapper.java: 
> 938)
> at freemarker.ext.beans.BeanModel.<init>(BeanModel.java:139)
> at freemarker.ext.beans.StringModel.<init>(StringModel.java:90)
> at freemarker.ext.beans.StringModel$1.create(StringModel.java:75)
> at freemarker.ext.beans.BeansModelCache.create(BeansModelCache.java: 
> 45)
> at freemarker.ext.util.ModelCache.getInstance(ModelCache.java:115)
> at freemarker.ext.beans.BeansWrapper.wrap(BeansWrapper.java:463)
> ….
>
> So after some google searches I’ve found that this is a problem with  
> a getter/setter not having the same return/first param types.  I’ve  
> looked through every bean, and unless I’m missing something, the  
> getters & setters all match up.  We do not provide setter methods  
> for read only or calculated properties.
>
> This is the block in beanswrapper that is throwing the error
>
> Method readMethod = pd.getReadMethod();
>                     Method publicReadMethod =  
> getAccessibleMethod(readMethod, accessibleMethods);
>                     if(publicReadMethod != null &&  
> isSafeMethod(publicReadMethod)) {
>                         try {
>                             if(readMethod != publicReadMethod) {
>                                 pd = new  
> PropertyDescriptor(pd.getName(),
>                                         publicReadMethod,  
> pd.getWriteMethod());
>                                 pd.setReadMethod(publicReadMethod);
>                             }
>                             classMap.put(pd.getName(), pd);
>                         }
>                         catch(IntrospectionException e)
>                         {
>                             logger.warn("Couldn't properly perform  
> introspection", e);
>                         }
>                     }
>
>
> First, can anyone explain why this is happening very rarely?  If  
> it’s a getter/setter mismatch, shouldn’t it be happening quite often  
> (static code..)?  We’ve been working on this app since mid August  
> and this has showed itself probably less than 10 times, 2 of which  
> were at the beginning of a demo :-| .  It seems to happen early on  
> after the container is started but not always…
>
> More importantly, since the exception is just swallowed here and  
> nothing is actually thrown, is this exception really exceptional?   
> Are you logging it to tell me that there is a slight problem I  
> should fix (but it’s really no big deal, totally recoverable)?   If  
> so the NAME and containing class of the property that mismatches  
> should be logged (really the java.beans pkg should do this for beans  
> wrapper, but it doesn’t..)  Or if it’s just noise the log stmt  
> should be removed.   If it’s actually a problem, it should be  
> wrapped and thrown, again with the name of the failing property  
> logged.
>
> So if anybody has any tips for how I can find out what property is  
> mismatching and why it is only mismatching under hard to produce  
> user input, please share.  I think I’ll have to check out FM and  
> hack this method a bit.  But if a dev could provide some insight on  
> what is happening here and why the catch block does what it does I  
> would really appreciate it.
>
> Thanks,
> John




------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H