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
>
> <camel:processRef ref="myTransformProcessor"/>
> <camel:to uri="file://target/data"/>
>
> <bean id="myTransformProcessor"
> 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) :
<user>
<phone>1</phone2>
<phone>2</phone2>
</user>
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.
