commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gabriel Belingueres (JIRA)" <j...@apache.org>
Subject [jira] Commented: (EL-13) Boolean bean property not found due to Introspector limitation
Date Tue, 22 Aug 2006 19:58:14 GMT
    [ http://issues.apache.org/jira/browse/EL-13?page=comments#action_12429790 ] 
            
Gabriel Belingueres commented on EL-13:
---------------------------------------

AFAIK, I think this is OK regarding the JavaBean spec.

Reading sections 8.3.1and 8.3.2, I see that the get/set naming convention will work allways,
but the is/set is a special case for boolean only...just a little sintactic sugar.

Further, please see that there is no uniformity even in the same document. There is no equivalent
naming convention for indexed boolean properties, i.e. you can't write:

public boolean is<PropertyName>(int a);

Anyway, regarding the patch it looks kind of expensive: there is a nested interation inside
findMissingMethods, and in foundTheReadMethod you compare with equalsIgnoreCase, which doesn't
look right, since method names are case sensitive.

Gabriel

> Boolean bean property not found due to Introspector limitation
> --------------------------------------------------------------
>
>                 Key: EL-13
>                 URL: http://issues.apache.org/jira/browse/EL-13
>             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: AdditionalIntrospection.java, 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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message