You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Gabriel Belingueres (JIRA)" <ji...@apache.org> on 2006/08/22 21:58:14 UTC

[jira] Commented: (EL-13) Boolean bean property not found due to Introspector limitation

    [ 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