[
https://issues.apache.org/jira/browse/EL-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521378
]
Joe Littlejohn commented on EL-13:
----------------------------------
Whilst I agree with your yes-or-no answer conclusion, this is a (dare I say
it?) pedantic argument that needn't apply to an introspection engine or EL.
This is about finding a property value, not its intended usage.
Imagine the following:
<c:if test="${bean.enabled}">
If enabled is a Boolean, I now have to add getBoolean. This still doesn't avoid
the fact that I've supplied a nullable property. I could even add a String
property in there if I wanted to, and EL would deal with it as before.
At the end of the day, I of course haven't been holding my breath since August
'06 desperately hoping that this gets included. I'm happy to have this closed
on a technicality. As far as a pragmatic approach to what's useful for
developers goes, I have no doubt that this should be included. We aren't
changing the bean spec here, just making EL more flexible.
Well, that's my way of rationalising it :) Resolve as you see fit.
> Boolean bean property not found due to Introspector limitation
> --------------------------------------------------------------
>
> Key: EL-13
> URL: https://issues.apache.org/jira/browse/EL-13
> Project: Commons EL
> Issue Type: Bug
> Affects Versions: 1.0
> Environment: Windows XP, Java 1.5.0_07-b03, Tomcat 5.5.17
> Reporter: Joe Littlejohn
> Fix For: 1.1
>
> Attachments: AdditionalIntrospection.java,
> AdditionalIntrospection.java, AdditionalIntrospection.java,
> AdditionalIntrospection.java, AdditionalIntrospection.java,
> BeanInfoManagerTest.java, BeanInfoManagerTest.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.
-
You can reply to this email to add a comment to the issue online.
