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

We are using 2.3.13, I didn't even know there was a newer version.. I will upgrade to 2.3.15 and see if it goes away.   =)

"so if no template code uses that particular property, it'll keep working"  Hmmm, I do understand your reasoning there, but I'm not sure I completely agree.  Well, it is fine really, I was going to argue that it should halt when that happens, but it does log something so the dev is actually made aware that a bug exists.  For the next release, can you please include the property descriptors name and class in the log statements?  That way we can fix these bugs if they do happen.

" and it ain't guaranteed by the JVM spec to be deterministic, so that might explain it..."

Yep, that is probably why I can't find a deterministic way to make it happen.  

Thanks,
John



 -----Original Message-----
From: Attila Szegedi [mailto:[email protected]] 
Sent: Thursday, February 19, 2009 7:01 AM
To: FreeMarker-user
Subject: Re: [FreeMarker-user] 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
_______________________________________________
FreeMarker-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemarker-user

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