MM> Hi all, MM> I don't know if we discussed this already, but today the coercion MM> issue in the EL made me loose a few hours again. I've had this before, MM> but seemingly forgot about it - time to follow up on this. MM> The issue in short: collapsed="#{bb.collapsed}" MM> Boolean getCollapsed() { MM> return null; MM> } MM> will lead to a value of "false" for the collapsed attribute if MM> java.lang.Boolean is set as the expected type of the corresponding MM> value-expression, according to the EL spec. Hrmmpf. I have filed <https://uel.dev.java.net/issues/show_bug.cgi?id=12>;. I have Cc'd Kin-Man on this message. However, I think the prospects for making the change Martin suggests are low. This is a very fundamental change in a technology that's been around for years. I'm quite certain it will have unintended negative consequences. MM> Do you guys think we should fix this in the JSF implementations, by MM> passing in java.lang.Object to the underlying EL expression, and doing MM> the coercion ourselves? We - most of the time - wrap the MM> value-expression in a Facelets TagValueExpression anyways, so we could MM> certainly do this! If the RI team agrees, I can certainly give word MM> out to the MyFaces team discussing if that is reasonable to us as MM> well. I think we should definately fix this in the JSF impl right now. I don't think discarding potentially valuable semantic information is the right idea. I'm sorry to suggest this, but I'd like to have it as a configuration option. This change could be affected in the implementation of our ScopedAttributeELResolver. Because table 5-22 of the spec declares that our ScopedAttributeELResolver must come directly after BeanELResolver (which is the resolver that resolves your "collapsed" property), we can check the isPropertyResolved property to detect this case. We will also have to insert another link in the chain, immediately *before* the BeanELResolver. Ed -- | ed.burns(a)sun.com | office: 408 884 9519 OR x31640 | homepage: | http://ridingthecrest.com/