camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bilgin Ibryam <>
Subject Re: Choosing between Mapping Options
Date Sun, 25 Jan 2015 21:41:26 GMT
1. For this option you can use Dozer to do the bean mapping and have better
control using Java for more complicated transformation that cannot be done
with xslt.

2. This option is more natural for xml processing, but some developers
(including me) don't like working xslt. Also in one situation we found out
that xslt transformation was the bottleneck in route, so changed it back to

I've seen it used both in the same project and cannot say whether one is
better than the other. It is a matter of taste.


On 21 January 2015 at 07:29, Satyam Maloo <> wrote:

> We have a camel project requirement where 5 SOAP based CXF services needs
> to
> interact with each other.
> Among these 2 camel projects are consumer and 3 cxf providers.
> The integration framework used is JBoss Fuse ESB.
> At the Integration layer we have created a common canonical format xsd.
> Now we need to do transformations from consumer data format to the common
> canonical data format and form common data format to provider data format
> and vice versa.
> We have the below options available for data mapping:
> 1. Creating POJO classes from wsdl and common xsd using wsdl2java plugin on
> wsdl and then in the routes write java converters/mapping (something like
> targetStructure.set(incomingStructure.get()))
> 2. Use xslt/xquery for transformation
> Which is a better option? Java mapping or XLST mapping? Consider that we
> are
> using CXF framwork  to push data to target system and writing integration
> flows using Spring DSL
> Kindly suggest with advantages over the other.
> Thanks in advance.
> Satyam
> -----
> Satyam
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

Bilgin Ibryam

Red Hat, Inc.
Apache Camel & Apache OFBiz committer
Twitter: @bibryam <>

Author of Instant Apache Camel Message Routing

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message