[ http://issues.apache.org/jira/browse/EL-13?page=comments#action_12429971
]
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: 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,
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
