[jira] [Commented] (TOMAHAWK-1599) HtmlCalendarRenderer Throws ClassCastException

["Klaus Schuster (Commented) (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/TOMAHAWK-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230084#comment-13230084 ] 

Klaus Schuster commented on TOMAHAWK-1599:
------------------------------------------

Problem is not fixed in 1.1.11 ! Line 169
                
> 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
>            Assignee: Leonardo Uribe
>             Fix For: 1.1.11
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira