[
https://issues.apache.org/jira/browse/EL-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521103
]
Matt Benson commented on EL-13:
-------------------------------
Wow, uh, no. You almost got me here... My thoughts were: "What? The
workaround uses the beans API to generate isFoo()? Maybe the Introspector IS
buggy after all and I've been wrong all this time." But the PropertyDescriptor
constructor in question has NO knowledge of the owning BeanInfo. It's just a
convenience constructor over a dumb data class. Though I've never seen the
concept documented anywhere, it struck me while I was slapping together a
little test of my own (which, incidentally, I never got around to even running
when I realized where this was going): isFoo() only makes semantic sense when
a non-null result is guaranteed. The "is" idiom demands a yes-or-no answer.
null is meaningless. I have long been in the camp that abides by the Boolean
vs. boolean get/is distinction, but I am now fully convinced of this
interpretation.
> 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.
