Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 335936 - Report parameters of data type 'date' are converted from java.sql.Date objects to java.util.Date object when used as drill-through parameter of chart
Summary: Report parameters of data type 'date' are converted from java.sql.Date object...
Status: CLOSED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: BIRT (show other bugs)
Version: 2.6.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.7.0 M7   Edit
Assignee: Heng Li CLA
QA Contact: Xiaoying Gu CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-01 04:05 EST by Ed Slocombe CLA
Modified: 2011-04-12 22:39 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Slocombe CLA 2011-02-01 04:05:45 EST
Build Identifier: 

The thread discussion which led to the creation of this bug can be found here:
http://www.birt-exchange.org/org/forum/index.php/topic/21427-birt-parameters-of-date-type-normally-javasqldate-but-sometimes-javautildate/page__p__72658__fromsearch__1&#entry72658

This issue only applies to drill-through links of charts (of chart sections, as far as I'm aware).

A report with a chart which as interactivity on a chart section, passing a date parameter as one of the drill-through parameters, seems to convert the date object from a java.sql.Date instance to a java.util.Date instance. This doesn't cause any issues in the report viewer or  BIRT Eclipse preview tab. It causes me problems since production code contained within a BIRT intergrated web application is now throwing ClassCastExceptions where my code always expects parameters of date type to be instances of java.sql.Date.

See forum post for full details. 

Reproducible: Always
Comment 1 Heng Li CLA 2011-04-12 22:39:22 EDT
The cause is chart uses Calendar.getTime() to return a Date instance, the default Date instance is java.util.Date. Now fixed it, add a check and return original java.sql.Date in class CDateTime.