camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Charles Moulliard (JIRA)" <>
Subject [jira] Commented: (CAMEL-398) Map the content of a CSV file to a POJO using @annotation and .convertBodyTo()
Date Tue, 20 Jan 2009 14:13:59 GMT


Charles Moulliard commented on CAMEL-398:

    *  interfaces should always be fully javadoced (especially if others should use or implement
>> I'm currently working on code documentation. My first release was not fully documented
because I would like to have your feedback prior to do this job (depending on the modification
requested and the refactory required, ..)

    * the classloading should be changed to use Camel classes and be OSGi friendly.
>> I will check how to use Camel ResolverUtil

    * dependency on camel-spring should only be scope for test (= unit testing)
>> ok.  Removed form the pom.xml
 * Would it not be nice that each POJO should be annoted at classlevel as well (
does not have etc.)
>> Client is not annoted at class level because it is a slave of order class. So, this
is not required. Moreover, we need only one 'root class' where the separator is defined.

    * Why are the fields in the model objects public? We should support private fields and
use getter/setter to access them
>> I will check this point again and adapt the code. I have changed from private to
public due to introspection.

    * LinkType? Doesnt hibernate have a similar feature and maybe there is a better name?
>> I have discovered last week that Hibernate use the following annotation @OnetoMany
concerning the link type. So maybe, we can follow this convention ?

    * ModelFactory if its a shared instance then it need locking for concurrent access (we
can address this later)
>> IF my code is correct. Only one instance of the modelfactory is created for each
Dataformat(packageName) instance created

    * BindyDataFormat might be renamed to BindyCsvDataFormat (its nice when the classname
has this important piece in its name)
>> OK. Is the name that you propose not redundant with the fact that this class is in
the package org.apache.camel.bindy.csv ?

    * use Camel type converter to convert from String to byte[] as it will handle encoding
as well (exch.getContext().getTypeConverter().convertTo(byte[].class, exch, exch) in BindyDataFormat
>> ok
    * In unmarshal we should use a java.util.Scanner if we for instance is reading a very
big file and can reduce memory usage
>> ok
    * code needs to be polished a bit. If you use IDEA it reports Well we get that later
>> I use Eclipse. What do you want that I do, use the camel formating style ?

    * ModelFactory should probably have an interface and a DefaultModelFactory implementatiion
>> Absolutely
    * format.impl is not a nice package name - just use format
>> ok
    * I dont think you should use threadlocal to store pattern formatters. Yes they are not
thread safe (damm SUN). creating objects is not expensive anymore!
>> This code is coming from my colleague. It will be happy that he must change it

    * ByteFormat - new Byte(String) is not the right one to use - use parseByte instead.
>> same remark as before
   * We could probably use generics for the format, so the API is nicer (we can check that
>> If you have an example, this will help me ?

Question : What do you think about the hashmap (HashMap<String, Object> modelObjects
= new HashMap<String, Object>();) ? Do you think that this is a good idea to use hashmap
and class name as key ?

> Map the content of a CSV file to a POJO using @annotation and .convertBodyTo()
> ------------------------------------------------------------------------------
>                 Key: CAMEL-398
>                 URL:
>             Project: Apache Camel
>          Issue Type: New Feature
>          Components: camel-core
>    Affects Versions: 1.4.0
>            Reporter: Charles Moulliard
>            Assignee: Claus Ibsen
>             Fix For: 2.0.0
>         Attachments:
> Hi,
> It should be nice if in a next relase of Camel, it will be possible to map the content
of a CSV file to a POJO using @annotation.
> For the moment, I use an ArrayList + iterator (see code hereafter) to achieve the extraction
of the content but I'm sure that we can simplify this code using @Annotation
> and the following action (.convertBodyTo(Order<List>) by example.
> Current situation
> Camel route
> from("file:///c:/temp/test?noop=true")
> .unmarshal().csv()
> .to("bean:converter?methodName=TransformMessage"); --> should be replaced by something
like .convertBodyTo(Order<List>)
> Converter class
>         public void TransformMessage(Exchange in) {
>                 process(in.getIn().getBody(List.class));
>         }
>         @SuppressWarnings("unchecked")
>         private void process(List messages) {
>                 // Iterate through the list of messages
>                 for (Iterator<ArrayList> it = messages.iterator(); it.hasNext();)
>                         // Split the content of the message into field
>                         message =;
>                         field = (String[]) message.toArray();
>                         order = new Order();
>                         order.setId(Integer.valueOf(field[0]).intValue());
>                         order.setBank(field[1]);
>                         order.setAmountFrom(Double.parseDouble(field[2]));
>                         order.setAmountTo(Double.parseDouble(field[3]));
>                         order.setOrderInstruction(field[4].trim());
>                         this.orderService.createOrder(order);
>                 }
>         }
> Regards,
> Charles

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message