myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack Frosch (JIRA)" <>
Subject [jira] [Commented] (TOMAHAWK-1599) HtmlCalendarRenderer Throws ClassCastException
Date Wed, 13 Jul 2011 20:28:00 GMT


Jack Frosch commented on TOMAHAWK-1599:

In looking more at the code in HtmlCalendarRenderer, I see that a java.util.Date is expected
later in the encodeEnd method. That makes this fix I suggested invalid:

           textValue = converter.getAsString(facesContext, inputCalendar, inputCalendar.getValue());

Instead, the fix I've applied locally to restore the behavior using DateConverter is this:

           if(converter instanceof DateConverter) {
               value = ((DateConverter) converter).getAsDate(facesContext, inputCalendar);
           } else {
               value = (Date) inputCalendar.getValue();

That yields a Date via DateConverter, just as it did in 1.1.8 and eliminated the ClassCastException
I was getting.

> HtmlCalendarRenderer Throws ClassCastException
> ----------------------------------------------
>                 Key: TOMAHAWK-1599
>                 URL:
>             Project: MyFaces Tomahawk
>          Issue Type: Bug
>          Components: Calendar
>    Affects Versions: 1.1.10
>         Environment: Windows 7 64-bit, JDK 1.6.0_24 64-Bit, Tomcat 6.0.32, Tomahawk20-1.1.10,
JSF 2.1.2
>            Reporter: Jack Frosch
> When migrating from JSF 1.2 to 2.1.2, we moved from Tomahawk12-1.1.8 to Tomahawk20-1.1.10.
Line 200 in org.apache.myfaces.custom.calendar.HtmlCalendarRenderer is now throwing a ClassCastException.
Here's the line and the line after it:
> value = (Date) inputCalendar.getValue();
> textValue = converter.getAsString(facesContext, inputCalendar, value);
> The problem is, we've been storing a non-Date value in the HtmlInputCalendar using a
custom converter. In 1.1.8, this was no issue because HtmlCalendarRenderer extracted the value
as a Date using our custom converter that implemented a DateConverter, as Line 127-130 shows
from the 1.1.8 HtmlCalendarRenderer:
> if (converter instanceof DateConverter)
> {
>     value = ((DateConverter) converter).getAsDate(facesContext, component);
> }
> Why we've been storing the value as a non-Date type is a long story, but we are. For
legacy reasons, project may want to store a Date in many types other than java.util.Date.
A Long value comes to mind. As the contract for the value property of UIInput only requires
an Object type, this should be allowed. The cast to a Date type seems  to unnecessarily impose
a constraint on what projects use for their projects.
> Interestingly, the very next line (Line 201 in 1.1.10) passed the Date value to the getAsString
method, which only requires a java.lang.Object be passed for the value. The cast is a wasted
operation anyway.
> Both lines, 200 and 201 could be replaced with this line:
> textValue = converter.getAsString(facesContext, inputCalendar, inputCalendar.getValue());
> This would eliminate the ClassCastException and allow projects the greatest flexibility
in how to store the calendar input.
> Because the cast is not needed when passing the value to the converter, and doing the
cast will cause a ClassCastException when a non-Date is stored in the UIInput, I'm logging
this as a bug. It definitely breaks our app.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message