Try to execute the code example from the web site get the following error :
java.lang.NoSuchMethodException: general.UserBean.setDate(java.util.Date)
at java.lang.Class.getMethod(Class.java:1605)
at org.supercsv.util.MethodCache.inspectClassForSetMethods(Unknown Source)
at org.supercsv.util.MethodCache.getSetMethod(Unknown Source)
at org.supercsv.io.CsvBeanReader.fillObject(Unknown Source)
at org.supercsv.io.CsvBeanReader.read(Unknown Source)
at general.ReadingObjects.main(ReadingObjects.java:32)
Exception in thread "main" general.UserBean.setDate(java.util.Date)
Can't find method 'setDate(class java.util.Date)' in class 'general.UserBean'. Is the name correctly spelled in the NameMapping? Have you forgot to convert the data so that a wrong set method is called? context: null offending processor: null
at org.supercsv.util.MethodCache.throwException(Unknown Source)
at org.supercsv.util.MethodCache.inspectClassForSetMethods(Unknown Source)
at org.supercsv.util.MethodCache.getSetMethod(Unknown Source)
at org.supercsv.io.CsvBeanReader.fillObject(Unknown Source)
at org.supercsv.io.CsvBeanReader.read(Unknown Source)
at general.ReadingObjects.main(ReadingObjects.java:32)
Caused by: java.lang.NoSuchMethodException: general.UserBean.setDate(java.util.Date)
at java.lang.Class.getMethod(Class.java:1605)
... 5 more
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Getting the same issue here. The problem is that the method we've defined in
the bean class is treated as java.util.Date which is wrong. It should be a
string although we are trying to do a conversion to date type later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The UserBean definition at the top is wrong. Use the full example (not quite
'full', as it doesn't import java.util.Date!) code at the end of the code
example which has :
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2011-10-21
I understand on how to assign a Date type to a column in CSV but the problem
remains the same when it comes to conversions. Converting Date to String and
vice-versa.
For instance the following code is giving me an error like this:
Exception in thread "main" java.lang.ClassCastException: java.util.Date cannot
be cast to java.lang.String
at org.supercsv.cellprocessor.ParseDate.execute(Unknown Source)
at org.supercsv.util.Util.processStringList(Unknown Source)
at org.supercsv.io.CsvBeanWriter.write(Unknown Source)
at ca.on.gov.ehealth.scheduler.SynchSchedStatTasks.writeTaskStatus(SynchSchedS
tatTasks.java:81)
at ca.on.gov.ehealth.scheduler.SynchSchedStatTasks.main(SynchSchedStatTasks.ja
va:147)
String[] header = new String[] {"TaskID","TaskStatus","DateRecorded","TaskResult" };
// write the partial data
CsvBeanWriter writer = new CsvBeanWriter(outFile, CsvPreference.EXCEL_PREFERENCE);
writer.writeHeader(header);
writer.write(newStatusFile, header, taskStatusProcessors);
writer.close();
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The first one does not use any CellProcessors, and simply writes each column
by calling the toString() method of the field in the bean.
The second one uses CellProcessors. If an element in the processor array is
null, then it will behave exactly like the first method and call toString() to
write the column. If you didn't want any special formatting or constraints
applied when writing, then you should use the first method instead. Otherwise
you would use the second method, and for each column that needs formatting or
constraints you can add a chain of CellProcessors. Where toString() is all you
need, you'd just leave that element in the CellProcessor array null.
As the goal of CsvBeanWriter is to convert Objects to Strings, the only
CellProcessors that are really relevant for writing are FmtBool, FmtDate,
FmtNumber and Trim (the ones that take Objects and return a String).
Answer
I'm assuming the dateRecorded field of your newStatusFile object is a Date,
and the definition of your taskStatusProcessors array looks something like
this
CellProcessor[] taskStatusProcessors = new CellProcessor[] {null, null, new ParseDate("dd/MM/yyyy"), null };
The problem with that is that ParseDate is used to take a formatted date
string and return a Date (i.e. it is used for reading, not writing). As it is
encountering a Date instead of a String, you're getting the
ClassCastException.
You can fix your problem by using the FmtDate CellProcessor (which formats a
Date for writing).
CellProcessor[] taskStatusProcessors = new CellProcessor[] {null, null, new FmtDate("dd/MM/yyyy"), null };
Hope this helps,
James
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2011-11-15
Thanks James,
I've fixed the issue by always passing the value to the CSV processor as a
pre-formatted string.
SimpleDateFormat sdfSource = new SimpleDateFormat("dd/MM/yyyy");
It looks like the CSV parser doesn't automatically convert between Date type
formats. I mean it doesn't have the knowledge of interpreting the different
Date Time formats unless you train it to do it. A little bit of polymorphism
could help :)
Cheers,
Dan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
Try to execute the code example from the web site get the following error :
java.lang.NoSuchMethodException: general.UserBean.setDate(java.util.Date)
at java.lang.Class.getMethod(Class.java:1605)
at org.supercsv.util.MethodCache.inspectClassForSetMethods(Unknown Source)
at org.supercsv.util.MethodCache.getSetMethod(Unknown Source)
at org.supercsv.io.CsvBeanReader.fillObject(Unknown Source)
at org.supercsv.io.CsvBeanReader.read(Unknown Source)
at general.ReadingObjects.main(ReadingObjects.java:32)
Exception in thread "main" general.UserBean.setDate(java.util.Date)
Can't find method 'setDate(class java.util.Date)' in class 'general.UserBean'. Is the name correctly spelled in the NameMapping? Have you forgot to convert the data so that a wrong set method is called? context: null offending processor: null
at org.supercsv.util.MethodCache.throwException(Unknown Source)
at org.supercsv.util.MethodCache.inspectClassForSetMethods(Unknown Source)
at org.supercsv.util.MethodCache.getSetMethod(Unknown Source)
at org.supercsv.io.CsvBeanReader.fillObject(Unknown Source)
at org.supercsv.io.CsvBeanReader.read(Unknown Source)
at general.ReadingObjects.main(ReadingObjects.java:32)
Caused by: java.lang.NoSuchMethodException: general.UserBean.setDate(java.util.Date)
at java.lang.Class.getMethod(Class.java:1605)
... 5 more
hi..
this sounds bad. what url is the code example found on?
many thanks
Getting the same issue here. The problem is that the method we've defined in
the bean class is treated as java.util.Date which is wrong. It should be a
string although we are trying to do a conversion to date type later.
The URL for this example is locate here:
http://supercsv.sourceforge.net/codeExamples_general.html
The UserBean definition at the top is wrong. Use the full example (not quite
'full', as it doesn't import java.util.Date!) code at the end of the code
example which has :
I understand on how to assign a Date type to a column in CSV but the problem
remains the same when it comes to conversions. Converting Date to String and
vice-versa.
For instance the following code is giving me an error like this:
Exception in thread "main" java.lang.ClassCastException: java.util.Date cannot
be cast to java.lang.String
at org.supercsv.cellprocessor.ParseDate.execute(Unknown Source)
at org.supercsv.util.Util.processStringList(Unknown Source)
at org.supercsv.io.CsvBeanWriter.write(Unknown Source)
at ca.on.gov.ehealth.scheduler.SynchSchedStatTasks.writeTaskStatus(SynchSchedS
tatTasks.java:81)
at ca.on.gov.ehealth.scheduler.SynchSchedStatTasks.main(SynchSchedStatTasks.ja
va:147)
Hi,
Just a bit of background information before I answer your question.
Background
CsvBeanReader - converts each column in a row (a String) to a field (Object)
in the bean.
CsvBeanWriter - converts each field (Object) in the bean to a column in a row
(String).
CsvBeanWriter has two write methods:
void write(Object source, String... nameMapping)
void write(Object source, String nameMapping, CellProcessor processor)
The first one does not use any CellProcessors, and simply writes each column
by calling the toString() method of the field in the bean.
The second one uses CellProcessors. If an element in the processor array is
null, then it will behave exactly like the first method and call toString() to
write the column. If you didn't want any special formatting or constraints
applied when writing, then you should use the first method instead. Otherwise
you would use the second method, and for each column that needs formatting or
constraints you can add a chain of CellProcessors. Where toString() is all you
need, you'd just leave that element in the CellProcessor array null.
As the goal of CsvBeanWriter is to convert Objects to Strings, the only
CellProcessors that are really relevant for writing are FmtBool, FmtDate,
FmtNumber and Trim (the ones that take Objects and return a String).
Answer
I'm assuming the dateRecorded field of your newStatusFile object is a Date,
and the definition of your taskStatusProcessors array looks something like
this
The problem with that is that ParseDate is used to take a formatted date
string and return a Date (i.e. it is used for reading, not writing). As it is
encountering a Date instead of a String, you're getting the
ClassCastException.
You can fix your problem by using the FmtDate CellProcessor (which formats a
Date for writing).
Hope this helps,
James
Thanks James,
I've fixed the issue by always passing the value to the CSV processor as a
pre-formatted string.
SimpleDateFormat sdfSource = new SimpleDateFormat("dd/MM/yyyy");
It looks like the CSV parser doesn't automatically convert between Date type
formats. I mean it doesn't have the knowledge of interpreting the different
Date Time formats unless you train it to do it. A little bit of polymorphism
could help :)
Cheers,
Dan