Jaxb is not a good example because here the content of the XML will be mapped
to the POJO object directly though the marshall/unmarshall process defined
in spring xml config file of camel
With the marshall/unmarshall method of CSV or SuperCSV, I will receive an
array this
ArrayList<Map<String, String>>()
that I need to map manually to my POJO through an additional step
from("file://myCSVfile")
.marshal().csv()
.bean("bean:mapArrayListtoMyBean")
.to("");
So JAXB like Xstream have one advantage over implementation of CSV (apache)
or SuperCSV ;)
KR,
James.Strachan wrote:
>
> 2008/12/11 cmoulliard <[EMAIL PROTECTED]>:
>>
>> Hi,
>>
>> I would like to know How we can extend the existing method
>> marshall/unmarshall of the class CsvDataFormat (supercsv component) in
>> such
>> a way that we can provide the CsvPreferences (STANDARD, EXCEL, ...) and
>> the
>> bean to be used to map the data ?
>>
>> idea :
>>
>> from("file://myCSVfile")
>> .marshal().csv("CsvPrefs","UserBeanToBeUsedForMappingData")
>> .to("");
>>
>> Why such request ? Because the SuperCSV classes allow to map directly the
>> content of a CSV file (with or withour headers) to a POJO and we can
>> define
>> i nthe preference the kind of CSV provided (excel, ...) (see doc for more
>> info : http://supercsv.sourceforge.net/codeExamples_general.html) ?
>>
>> ex :
>>
>> public class UserBean {
>> String username, password, street, town;
>> int zip;
>>
>> public String getPassword() { return password; }
>> public String getStreet() { return street; }
>> public String getTown() { return town; }
>> public String getUsername() { return username; }
>> public int getZip() { return zip; }
>> public void setPassword(String password) { this.password = password; }
>> public void setStreet(String street) { this.street = street; }
>> public void setTown(String town) { this.town = town; }
>> public void setUsername(String username) { this.username = username; }
>> public void setZip(int zip) { this.zip = zip; }
>> }
>>
>> class ReadingObjects {
>> public static void main(String[] args) throws Exception{
>> ICsvBeanReader inFile = new CsvBeanReader(new FileReader("foo.csv"),
>> CsvPreference.EXCEL_PREFERENCE);
>> try {
>> final String[] header = inFile.getCSVHeader(true);
>> UserBean user;
>> while( (user = inFile.read(UserBean.class, header, processors)) !=
>> null) {
>> System.out.println(user.getZip());
>> }
>> } finally {
>> inFile.close();
>> }
>> }
>> }
>
> One of the big reasons for the DataFormat abstraction in Camel instead
> of the type conversion stuff was so that you could create a specific
> DataFormat instance - configure it in Java/Spring/Guice and use it
> explicitly in a route.
>
> e.g. see JAXB which is a great example - you typically wanna configure
> each one with a JAXB context (set of packages/classes etc)
> http://activemq.apache.org/camel/jaxb.html
>
> so sure, we should make it easy to configure all of the Data Format
> implementations - either through a DI framework like Spring/Guice or
> via Java/JNDI
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
>
-----
Charles Moulliard
SOA Architect
My Blog : http://cmoulliard.blogspot.com/ http://cmoulliard.blogspot.com/
--
View this message in context:
http://www.nabble.com/Is-there-a-way-to-extend-marshall-method-of-CsvDataFormat-class-tp20955830s22882p20956121.html
Sent from the Camel - Users mailing list archive at Nabble.com.
