commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joe Littlejohn (JIRA)" <>
Subject [jira] Commented: (EL-13) Boolean bean property not found due to Introspector limitation
Date Wed, 23 Aug 2006 11:33:20 GMT
    [ ] 
Joe Littlejohn commented on EL-13:

I've updated the fix as per your case observation.

I don't think the fix is too expensive for three reasons: -

1. It happens during initialize, which only occurs once for any given bean type.

2. Although there is nested iteration, the second iteration *only* occurs when there is a
Boolean property with no getter found. It's not like this is going to be doing nested iteration
for every bean type, slowing down all EL parsing.

3. With the advent of auto-boxing, many more developers are supposed to be able to throw off
the shackles of primitive types. This is a major obstruction to this. Yes, the Java Bean Spec
indicates that only the boolean type has the option of an "is" method, however this was written
long before auto-boxing was conceived. The new paradigm for primitive types in Java 5.0 would
clearly imply that a Boolean return type would warrant an "is" prefix.

As an alternative solution, some simple decoupling would allow the BeanInfo object to be returned
from a configured factory. The default implementation of this factory would look like: -

class DefaultBeanInfoFactory implements BeanInfoFactory {
    public BeanInfo getBeanInfo(Class clazz) throws IntrospectionException {
        return Introspector.getBeanInfo (mBeanClass);

But this would allow users to create their own factory. In my case I could create a factory
that used the Introspector (but also did my AdditionalIntrospection step). 

For me this (arguable) bug is compounded by the fact that Tomcat, Commons EL and java.beans.Introspector
are so tightly coupled.

> Boolean bean property not found due to Introspector limitation
> --------------------------------------------------------------
>                 Key: EL-13
>                 URL:
>             Project: Commons EL
>          Issue Type: Bug
>    Affects Versions: 1.0 Final
>         Environment: Windows XP, Java 1.5.0_07-b03, Tomcat 5.5.17
>            Reporter: Joe Littlejohn
>         Attachments:,, el_exception.txt
> There is a bug in the java.beans.Introspector which means that it cannot find
> the read method for a property of Boolean type (because it looks for the "get"
> prefix, not the "is" prefix). This is arguably the expected behaviour of the
> Introspector, however since the java.beans.PropertyDescriptor acts differently
> (it can identify the property read method), this inconsistency hints it's a bug.
> Also, with the advent of autoboxing, developers are supposed to be able to free
> themselves from primitive types.
> The commons EL library is affected by this bug, so using an interface like: -
> public interface Bean {
>     Boolean isEnabled();
> }
> and an expression like: -
> ${bean.enabled}
> fails with an ELException saying that the property could not be found (see
> attached log snippet).
> WebLogic does not suffer from this problem, presumably because they implement
> their own EL parser (don't use commons.el) which doesn't use the Introspector. I
> have written a suggested workaround for this problem which would allow the
> commons.el library to continue its use of the Introspector, but deal with this
> flaw (see attached). The AdditionalIntrospection could be used in the
> BeanInfoManager.initialise() method, like so: -
> PropertyDescriptor [] pds = mBeanInfo.getPropertyDescriptors ();
> pds = AdditionalIntrospection.findMissingMethods(mBeanClass, pds); // new step

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message