Return-Path: Delivered-To: apmail-camel-users-archive@www.apache.org Received: (qmail 50111 invoked from network); 21 Oct 2009 18:26:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 21 Oct 2009 18:26:45 -0000 Received: (qmail 68719 invoked by uid 500); 21 Oct 2009 17:41:36 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 58613 invoked by uid 500); 21 Oct 2009 17:38:34 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Received: (qmail 49669 invoked by uid 99); 21 Oct 2009 16:53:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Oct 2009 16:53:18 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of lists@nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Oct 2009 16:53:09 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1N0eQZ-0005oJ-DW for users@camel.apache.org; Wed, 21 Oct 2009 09:52:47 -0700 Message-ID: <25996212.post@talk.nabble.com> Date: Wed, 21 Oct 2009 09:52:47 -0700 (PDT) From: llecaroz To: users@camel.apache.org Subject: Re: How to save a select result from camel-sql componnent to xml ( No type converter available to convert from type: java.util.ArrayList issue ) In-Reply-To: <5380c69c0910160839l5c70ce7cxdd39aaaf0846eccd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: louis.lecaroz@sap.com References: <25927249.post@talk.nabble.com> <5380c69c0910160839l5c70ce7cxdd39aaaf0846eccd@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org Claus Ibsen-2 wrote: > > > You can use Java code to transform the payload into a more appropriate > format. > > You can use a org.apache.camel.Processor or POJO > > > > > class="com.mycompany.MyTransformProcessor"/> > > public class MyTransformProcessor implements Processor { > ... > List data = exchange.getIn().getBody(List.class); > // use regular java code to transform to a better form > exchange.getIn().setBody(betterBody); > } > > > > See more at the Message Translator EIP > http://camel.apache.org/message-translator.html > > The SQL component returns raw data in a List that is like the sql > ResultSet. > You gotta transform that manually to something else using Java code. > > Or use some ORM that can map from the database to POJO classes which > are easier to marshal to XML using camel-xstream or JAXB annotations > etc. > > > Hello Claus, firt, I would like to thank you for your answer. That's a little bit sad :( regarding the power of the sql camel component. At this time due to the constraint of implementing a translator EIP, it is easier for me in my project to call a bean method with the camel-bean "bean:" uri & to give the sql parameter as parameter ! Why ? because as I use Hibernate -I added jpa+jaxb annotations on the same class, by the way, -When I execute the sql request, it returns a list of entity, -I just have next to add the sql results returned in a list of entities in a xml root/parent element, & finally, -to simply returns the parent node which contains the entities ! So in term of code it is (from my personnal point of view of sure & preferences & as I already write this code as workaround), easier to do as this instead of having the sql result being stored in the inbody of the camel message to be converted & next to be returned. for sure, it the converter type is really interesting in term of re-usability in multiple workflows... But I feel that lot of users (me ;) ), would like to use the caml-sql "sql:" component & next would like to work directly on the result by using the "split" or choice, or other camel components. It would be also really interesting to have the camel-sql being able as enhencement request to automatically map the result in a parent xml node (something like sql:select from table?dataSourceRef=mydataSource&parentJaxbElement=org.sample.user) : 1 2 So the phone & user class implementations contains @XMLRootElement & also @Entity annotations. Just imagine the power of having a camel-sql returning an "understandable" format by other camel componnent like "split" or choice with xpath, ect... I hope that I was able to give a clear feedback on my attended/wanted usage of the camel sql component & why in my situation it is simple to use a bean, returning sql results in a jaxb/jpa annotated member of an annoated jaxb class. But I would like to really thank you as your contribution in this discussion really helped me to do the good choice on my project. Regards Louis -- View this message in context: http://www.nabble.com/How-to-save-a-select-result-from-camel-sql-componnent-to-xml-%28-No-type-converter-available-to-convert-from-type%3A-java.util.ArrayList-issue-%29-tp25927249p25996212.html Sent from the Camel - Users mailing list archive at Nabble.com.