Details
Description
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.
Attachments
Issue Links
- breaks
-
TOMAHAWK-1613 HtmlCalendarRenderer Throws ClassCastException - not fixed
-
- Closed
-