Attached test case that shows the issue in ICEfaces 3.1.0. Error is thrown on immediate access/rendering of the page.

From what I can tell, the converter methods are never called at all. I couldn't really tell why but then I finally tried some web searches and apparently this is "on purpose" - converters are not supported for this component in JSF 2.0.

http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-238

So it's a regression in the sense that this used to work in previous versions of ICEfaces but we may need to do some work to get it working again in the current version. The custom renderer provided is supposed to help with this issue but I don't see an instance of it being created so it's not being overridden properly for some reason.

It looks like where the exception is thrown is where it gets the value, which would later then be fed to the converter. So it happens before the converter would even have a chance to operate.

So in the basic EL coercion being used by the ValueExpression, to coerce between the component property's Boolean type and the bean property's Byte type, here are the rules:

http://commons.apache.org/el/api/org/apache/commons/el/Coercions.html

coerce A to Number type N
A is Boolean
error

coerce A to Boolean
A is null or ""
return false
A is Boolean
return A
A is String
Boolean.valueOf(A) throws exception
error
return Boolean.valueOf(A)
otherwise
error

In both directions, it's an error.

So the question is, why can't the app provide a different bean property getter/setter that is typed Boolean and does the conversion itself.

The code in the custom renderer is only applicable to decode, of converting a submittedValue. This exception happens at render time on the first lifecycle, and doesn't make it to any postback where decode would be relevant.

Slight correction to the last comment. I do see the customer renderer being created but it's methods are not invoked - including the getConvertedValue() method.

We can suggest the workaround. The original question related to the fact that "this worked before and doesn't now" during their migration from 1.8 to 3.x.

Were they using JSF 1.1 or JSF 1.2 with ICEfaces 1.8.x? That would affect the ValueBinding versus ValueExpression wiring, and it could be that affects the ValueBiding/ValueExpression's type usage with coercion. Or maybe JSF 2 changes how that's wired up. We could go into our own renderer and add code to print out the ValueBinding or ValueExpression's type, and see if that was Boolean or just Object, back in ICEfaces 1.8 and now in ICEfaces 3.1 to see if that's changed.

This isn't "solved" yet but I did convert the app back to a 1.8 version and confirmed that it worked. However my new theory is that it appears to be an issue with the resolution of the ValueExpression $

(which occurs prior to the converters being called).

First of all, I updated the el-api and el-impl libs I was using to 2.2.1_b04 and then set the following context parameter:

<context-param>
<param-name>com.sun.faces.expressionFactory</param-name>
<param-value>com.sun.el.ExpressionFactoryImpl</param-value>
</context-param>

I still ended up with the same issue but got a bit more information on the cause:

Caused by: java.lang.IllegalArgumentException: Cannot convert 0 of type class java.lang.Byte to class java.lang.Boolean
at com.sun.el.lang.ELSupport.coerceToBoolean(ELSupport.java:178)
at com.sun.el.lang.ELSupport.coerceToType(ELSupport.java:379)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:222)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)

Debugging this area showed that the coersion was being done based on the fact that there is an "expected type" for this expression. In this case a Boolean. Screen shot shows the relevant code involved.

I haven't verified with the ICEfaces 1.x code yet but I suspect that there were no ValueExpressions with expectedTypes back in the JSF 1.2 days and so there was no attempted coercion to the expected type and therefore no problem appeared before the converters got a chance to run.

Since this is likely a difference of enhanced coercion strictness in the newer EL library, and the exception happens when getting the value property, before the Converter comes into play, the simplest solution would be for the application to provide converting getter/setter methods. The value property on this ICE component is inherited from the JSF super-class, so it's not really our property to alter to try to loosen it's typing. And I doubt it would be good to generally loosen the typing on properties.