myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack Frosch (JIRA)" <...@myfaces.apache.org>
Subject [jira] [Created] (TOMAHAWK-1599) HtmlCalendarRenderer Throws ClassCastException
Date Wed, 13 Jul 2011 07:50:00 GMT
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

        

Mime
View raw message