[
https://issues.apache.org/jira/browse/TOMAHAWK-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064820#comment-13064820
]
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: https://issues.apache.org/jira/browse/TOMAHAWK-1599
> 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: http://www.atlassian.com/software/jira
