[
https://issues.apache.org/activemq/browse/CAMEL-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48837#action_48837
]
Charles Moulliard commented on CAMEL-398:
-----------------------------------------
* interfaces should always be fully javadoced (especially if others should
use or implement em)
>> 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
(Client.java 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 later)
>> 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: https://issues.apache.org/activemq/browse/CAMEL-398
> 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: camel-bindy.zip
>
>
> 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 = it.next();
> 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.
