You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by da...@apache.org on 2021/08/18 15:34:56 UTC
[camel] branch main updated: CAMEL-16869: camel-dozer - deprecate
the dozer type converter
This is an automated email from the ASF dual-hosted git repository.
davsclaus pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/main by this push:
new 934e5b1 CAMEL-16869: camel-dozer - deprecate the dozer type converter
934e5b1 is described below
commit 934e5b19a64a5ce65c8564d72ea75dd2b07b921b
Author: Claus Ibsen <cl...@gmail.com>
AuthorDate: Wed Aug 18 17:34:26 2021 +0200
CAMEL-16869: camel-dozer - deprecate the dozer type converter
---
.../apache/camel/catalog/docs/dozer-component.adoc | 206 +++++++++++++++++++++
.../camel-dozer/src/main/docs/dozer-component.adoc | 206 +++++++++++++++++++++
.../camel/converter/dozer/DozerTypeConverter.java | 1 +
.../converter/dozer/DozerTypeConverterLoader.java | 1 +
.../modules/ROOT/pages/dozer-component.adoc | 206 +++++++++++++++++++++
docs/user-manual/modules/ROOT/nav.adoc | 1 -
.../modules/ROOT/pages/dozer-type-conversion.adoc | 204 --------------------
docs/user-manual/modules/ROOT/pages/index.adoc | 1 -
8 files changed, 620 insertions(+), 206 deletions(-)
diff --git a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/dozer-component.adoc b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/dozer-component.adoc
index 4c061b3..c742f5b 100644
--- a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/dozer-component.adoc
+++ b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/dozer-component.adoc
@@ -335,4 +335,210 @@ Note that any properties within your expression must be escaped with "\"
to prevent an error when Dozer attempts to resolve variable values
defined using the EL.
+== Dozer Type Conversion
+
+WARNING: The dozer type conversion is deprecated. Do not use.
+
+https://github.com/DozerMapper/dozer/blob/master/docs/asciidoc/about/about.adoc[Dozer] is a fast
+and flexible framework for mapping back and forth between Java Beans.
+Coupled with Camel's automatic type conversion, it's a formidable tool
+for dealing object to object mapping headaches that crop up in
+enterprise integration projects.
+
+To explain how Dozer can be used within Camel we'll use the following
+example of a simple Customer Support Service. The initial version of the
+Service defined a 'Customer' object used with a very flat structure.
+
+*Legacy Customer Service Class*
+
+[source,java]
+-----------------------------------------------------------------------------------
+public class Customer {
+ private String firstName;
+ private String lastName;
+ private String street;
+ private String zip;
+
+ public Customer() {}
+
+ public Customer(String firstName, String lastName, String zip, String street) {
+ this.firstName = firstName;
+ this.lastName = lastName;
+ this.zip = zip;
+ this.street = street;
+ }
+
+ public String getFirstName() {
+ return firstName;
+ }
+
+ public void setFirstName(String firstName) {
+ this.firstName = firstName;
+ }
+
+ ... getters and setters for each field
+-----------------------------------------------------------------------------------
+
+In the next version it was decided to structure the data better in the
+model by moving the address data into its own type, with the resulting
+domain object ending up looking like the below.
+
+*Next Gen Customer object*
+
+[source,java]
+-------------------------------------------------------------------------
+public class Customer {
+ private String firstName;
+ private String lastName;
+ private Address address;
+
+ public Customer() {}
+
+ public Customer(String firstName, String lastName, Address address) {
+ this.firstName = firstName;
+ this.lastName = lastName;
+ this.address = address;
+ }
+ ....
+
+
+public class Address {
+ private String zipCode;
+ private String streetName;
+
+ public Address() {}
+
+ public Address(String zipCode, String streetName) {
+ this.zipCode = zipCode;
+ this.streetName = streetName;
+ }
+-------------------------------------------------------------------------
+
+Much nicer! But as often occurs, the previous version of the service,
+with the old flat 'Customer' object, was in production with a client and
+the project must support the legacy interface. To support both versions,
+we must add a mechanism to convert between the old Customer service type
+and the new Customer domain type and back again. It would be a simple
+matter to write a custom converter class to map between them, but this
+may not be the only service/domain inconsistency and these tedious and
+error prone custom mappings could quickly start to add up, and bugs with
+them.
+
+To a large extent the two objects share an identical structure, with only
+the address representation being different. It would be very helpful if
+there were a practical way to automate this kind of mapping, such
+that the similar properties could get mapped automatically and only the
+inconsistencies requiring custom mapping.
+
+This is where Dozer comes in; it uses reflection to map data between two
+bean types using a set of simple mapping rules. Where no rule is
+specified, Dozer will attempt to map between them by using matching
+properties of two beans. In this way, focus can be given to the
+inconsistencies between the beans i.e. the address properties, knowing
+that Dozer will automatically match and convert the others.
+
+=== Configuring Dozer Type Converter
+
+Dozer's configuration is extremely flexible and many mapping scenarios
+are covered https://github.com/DozerMapper/dozer/blob/master/docs/asciidoc/documentation/mappings.adoc[here].
+For our simple example, the configuration looks like the following.
+
+*mapping.xml*
+
+[source,xml]
+---------------------------------------------------------------------------------------------------------
+<mappings xmlns="http://dozermapper.github.io/schema/bean-mapping"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="http://dozermapper.github.io/schema/bean-mapping http://dozermapper.github.io/schema/bean-mapping.xsd">
+ <mapping>
+ <class-a>org.apache.camel.converter.dozer.service.Customer</class-a>
+ <class-b>org.apache.camel.converter.dozer.model.Customer</class-b>
+ <field>
+ <a>street</a>
+ <b>address.streetName</b>
+ </field>
+ <field>
+ <a>zip</a>
+ <b>address.zipCode</b>
+ </field>
+ </mapping>
+</mappings>
+---------------------------------------------------------------------------------------------------------
+
+=== Support for Dozer in Camel Type Converter
+
+Camel provides a simple mechanism to integrate Dozer Mappers with it's
+own powerful xref:manual::type-converter.adoc[Type Conversion] framework.
+Its configured by creating an instance of `DozerTypeConverterLoader`
+providing it the camel context and an optional Dozer mapper.
+
+If no mapper is supplied, Camel's registry will
+be searched for suitable instances. The loader will query the Dozer
+Mapper for the types it converts and register them with Camel's
+type conversion framework to be handled by the mapper.
+
+[NOTE]
+====
+*Limitation*
+
+The Camel Dozer type converter does not support having the same type
+conversion pairs in different mapping ids (eg map-id) in Dozer.
+====
+
+In Java it can be configured as follows:
+
+[source,java]
+-----------------------------------------------------------------------------------------
+Mapper mapper = DozerBeanMapperBuilder.create()
+ .withMappingFiles("mapping.xml")
+ .build();
+
+new DozerTypeConverterLoader(camelContext, mapper);
+-----------------------------------------------------------------------------------------
+
+Or in Spring XML:
+
+[source,xml]
+--------------------------------------------------------------------------------------------------
+<bean id="dozerConverterLoader" class="org.apache.camel.converter.dozer.DozerTypeConverterLoader">
+ <argument index="0" ref="myCamel"/>
+ <argument index="1" ref="mapperConfiguration"/>
+</bean>
+
+<bean id="mapperConfiguration" class="org.apache.camel.converter.dozer.DozerBeanMapperConfiguration">
+ <property name="mappingFiles">
+ <list>
+ <value>mapping.xml</value>
+ </list>
+ </property>
+</bean>
+
+<camelContext id="myCamel" xmlns="http://camel.apache.org/schema/spring">
+ ...
+</camelContext>
+--------------------------------------------------------------------------------------------------
+
+Now, where necessary, Camel will use Dozer to do conversions; in our
+case between the new domain and legacy Customer types e.g.
+
+[source,java]
+---------------------------------------------------------------------------------------------------------------------------------------------
+// given the following route
+from("direct:legacy-service-in").bean(new CustomerProcessor());
+
+// and a processor
+
+public class CustomerProcessor {
+
+ public Customer processCustomer(org.apache.camel.converter.dozer.model.Customer customer) {
+ ...
+ }
+}
+
+// service objects can be sent to the processor and automagically converted by Camel & Dozer
+template.sendBody("direct:legacy-service-in", new org.apache.camel.converter.dozer.service.Customer("Bob", "Roberts", "12345", "1 Main st."));
+---------------------------------------------------------------------------------------------------------------------------------------------
+
+
+
include::{page-component-version}@camel-spring-boot::page$dozer-starter.adoc[]
diff --git a/components/camel-dozer/src/main/docs/dozer-component.adoc b/components/camel-dozer/src/main/docs/dozer-component.adoc
index 4c061b3..c742f5b 100644
--- a/components/camel-dozer/src/main/docs/dozer-component.adoc
+++ b/components/camel-dozer/src/main/docs/dozer-component.adoc
@@ -335,4 +335,210 @@ Note that any properties within your expression must be escaped with "\"
to prevent an error when Dozer attempts to resolve variable values
defined using the EL.
+== Dozer Type Conversion
+
+WARNING: The dozer type conversion is deprecated. Do not use.
+
+https://github.com/DozerMapper/dozer/blob/master/docs/asciidoc/about/about.adoc[Dozer] is a fast
+and flexible framework for mapping back and forth between Java Beans.
+Coupled with Camel's automatic type conversion, it's a formidable tool
+for dealing object to object mapping headaches that crop up in
+enterprise integration projects.
+
+To explain how Dozer can be used within Camel we'll use the following
+example of a simple Customer Support Service. The initial version of the
+Service defined a 'Customer' object used with a very flat structure.
+
+*Legacy Customer Service Class*
+
+[source,java]
+-----------------------------------------------------------------------------------
+public class Customer {
+ private String firstName;
+ private String lastName;
+ private String street;
+ private String zip;
+
+ public Customer() {}
+
+ public Customer(String firstName, String lastName, String zip, String street) {
+ this.firstName = firstName;
+ this.lastName = lastName;
+ this.zip = zip;
+ this.street = street;
+ }
+
+ public String getFirstName() {
+ return firstName;
+ }
+
+ public void setFirstName(String firstName) {
+ this.firstName = firstName;
+ }
+
+ ... getters and setters for each field
+-----------------------------------------------------------------------------------
+
+In the next version it was decided to structure the data better in the
+model by moving the address data into its own type, with the resulting
+domain object ending up looking like the below.
+
+*Next Gen Customer object*
+
+[source,java]
+-------------------------------------------------------------------------
+public class Customer {
+ private String firstName;
+ private String lastName;
+ private Address address;
+
+ public Customer() {}
+
+ public Customer(String firstName, String lastName, Address address) {
+ this.firstName = firstName;
+ this.lastName = lastName;
+ this.address = address;
+ }
+ ....
+
+
+public class Address {
+ private String zipCode;
+ private String streetName;
+
+ public Address() {}
+
+ public Address(String zipCode, String streetName) {
+ this.zipCode = zipCode;
+ this.streetName = streetName;
+ }
+-------------------------------------------------------------------------
+
+Much nicer! But as often occurs, the previous version of the service,
+with the old flat 'Customer' object, was in production with a client and
+the project must support the legacy interface. To support both versions,
+we must add a mechanism to convert between the old Customer service type
+and the new Customer domain type and back again. It would be a simple
+matter to write a custom converter class to map between them, but this
+may not be the only service/domain inconsistency and these tedious and
+error prone custom mappings could quickly start to add up, and bugs with
+them.
+
+To a large extent the two objects share an identical structure, with only
+the address representation being different. It would be very helpful if
+there were a practical way to automate this kind of mapping, such
+that the similar properties could get mapped automatically and only the
+inconsistencies requiring custom mapping.
+
+This is where Dozer comes in; it uses reflection to map data between two
+bean types using a set of simple mapping rules. Where no rule is
+specified, Dozer will attempt to map between them by using matching
+properties of two beans. In this way, focus can be given to the
+inconsistencies between the beans i.e. the address properties, knowing
+that Dozer will automatically match and convert the others.
+
+=== Configuring Dozer Type Converter
+
+Dozer's configuration is extremely flexible and many mapping scenarios
+are covered https://github.com/DozerMapper/dozer/blob/master/docs/asciidoc/documentation/mappings.adoc[here].
+For our simple example, the configuration looks like the following.
+
+*mapping.xml*
+
+[source,xml]
+---------------------------------------------------------------------------------------------------------
+<mappings xmlns="http://dozermapper.github.io/schema/bean-mapping"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="http://dozermapper.github.io/schema/bean-mapping http://dozermapper.github.io/schema/bean-mapping.xsd">
+ <mapping>
+ <class-a>org.apache.camel.converter.dozer.service.Customer</class-a>
+ <class-b>org.apache.camel.converter.dozer.model.Customer</class-b>
+ <field>
+ <a>street</a>
+ <b>address.streetName</b>
+ </field>
+ <field>
+ <a>zip</a>
+ <b>address.zipCode</b>
+ </field>
+ </mapping>
+</mappings>
+---------------------------------------------------------------------------------------------------------
+
+=== Support for Dozer in Camel Type Converter
+
+Camel provides a simple mechanism to integrate Dozer Mappers with it's
+own powerful xref:manual::type-converter.adoc[Type Conversion] framework.
+Its configured by creating an instance of `DozerTypeConverterLoader`
+providing it the camel context and an optional Dozer mapper.
+
+If no mapper is supplied, Camel's registry will
+be searched for suitable instances. The loader will query the Dozer
+Mapper for the types it converts and register them with Camel's
+type conversion framework to be handled by the mapper.
+
+[NOTE]
+====
+*Limitation*
+
+The Camel Dozer type converter does not support having the same type
+conversion pairs in different mapping ids (eg map-id) in Dozer.
+====
+
+In Java it can be configured as follows:
+
+[source,java]
+-----------------------------------------------------------------------------------------
+Mapper mapper = DozerBeanMapperBuilder.create()
+ .withMappingFiles("mapping.xml")
+ .build();
+
+new DozerTypeConverterLoader(camelContext, mapper);
+-----------------------------------------------------------------------------------------
+
+Or in Spring XML:
+
+[source,xml]
+--------------------------------------------------------------------------------------------------
+<bean id="dozerConverterLoader" class="org.apache.camel.converter.dozer.DozerTypeConverterLoader">
+ <argument index="0" ref="myCamel"/>
+ <argument index="1" ref="mapperConfiguration"/>
+</bean>
+
+<bean id="mapperConfiguration" class="org.apache.camel.converter.dozer.DozerBeanMapperConfiguration">
+ <property name="mappingFiles">
+ <list>
+ <value>mapping.xml</value>
+ </list>
+ </property>
+</bean>
+
+<camelContext id="myCamel" xmlns="http://camel.apache.org/schema/spring">
+ ...
+</camelContext>
+--------------------------------------------------------------------------------------------------
+
+Now, where necessary, Camel will use Dozer to do conversions; in our
+case between the new domain and legacy Customer types e.g.
+
+[source,java]
+---------------------------------------------------------------------------------------------------------------------------------------------
+// given the following route
+from("direct:legacy-service-in").bean(new CustomerProcessor());
+
+// and a processor
+
+public class CustomerProcessor {
+
+ public Customer processCustomer(org.apache.camel.converter.dozer.model.Customer customer) {
+ ...
+ }
+}
+
+// service objects can be sent to the processor and automagically converted by Camel & Dozer
+template.sendBody("direct:legacy-service-in", new org.apache.camel.converter.dozer.service.Customer("Bob", "Roberts", "12345", "1 Main st."));
+---------------------------------------------------------------------------------------------------------------------------------------------
+
+
+
include::{page-component-version}@camel-spring-boot::page$dozer-starter.adoc[]
diff --git a/components/camel-dozer/src/main/java/org/apache/camel/converter/dozer/DozerTypeConverter.java b/components/camel-dozer/src/main/java/org/apache/camel/converter/dozer/DozerTypeConverter.java
index 131d9d4..e6b387b 100644
--- a/components/camel-dozer/src/main/java/org/apache/camel/converter/dozer/DozerTypeConverter.java
+++ b/components/camel-dozer/src/main/java/org/apache/camel/converter/dozer/DozerTypeConverter.java
@@ -35,6 +35,7 @@ import org.slf4j.LoggerFactory;
*
* @see DozerTypeConverterLoader
*/
+@Deprecated
public class DozerTypeConverter extends TypeConverterSupport {
private static final Logger LOG = LoggerFactory.getLogger(DozerTypeConverter.class);
diff --git a/components/camel-dozer/src/main/java/org/apache/camel/converter/dozer/DozerTypeConverterLoader.java b/components/camel-dozer/src/main/java/org/apache/camel/converter/dozer/DozerTypeConverterLoader.java
index fdf988d..ff94f77 100644
--- a/components/camel-dozer/src/main/java/org/apache/camel/converter/dozer/DozerTypeConverterLoader.java
+++ b/components/camel-dozer/src/main/java/org/apache/camel/converter/dozer/DozerTypeConverterLoader.java
@@ -43,6 +43,7 @@ import static com.github.dozermapper.core.classmap.MappingDirection.ONE_WAY;
* mapper is queried for the types it converts. The queried types are used to register the {@link TypeConverter} with
* the context via its {@link TypeConverterRegistry}.
*/
+@Deprecated
public class DozerTypeConverterLoader extends ServiceSupport implements CamelContextAware {
private final Logger log = LoggerFactory.getLogger(getClass());
diff --git a/docs/components/modules/ROOT/pages/dozer-component.adoc b/docs/components/modules/ROOT/pages/dozer-component.adoc
index 29d9215..9093d95 100644
--- a/docs/components/modules/ROOT/pages/dozer-component.adoc
+++ b/docs/components/modules/ROOT/pages/dozer-component.adoc
@@ -337,4 +337,210 @@ Note that any properties within your expression must be escaped with "\"
to prevent an error when Dozer attempts to resolve variable values
defined using the EL.
+== Dozer Type Conversion
+
+WARNING: The dozer type conversion is deprecated. Do not use.
+
+https://github.com/DozerMapper/dozer/blob/master/docs/asciidoc/about/about.adoc[Dozer] is a fast
+and flexible framework for mapping back and forth between Java Beans.
+Coupled with Camel's automatic type conversion, it's a formidable tool
+for dealing object to object mapping headaches that crop up in
+enterprise integration projects.
+
+To explain how Dozer can be used within Camel we'll use the following
+example of a simple Customer Support Service. The initial version of the
+Service defined a 'Customer' object used with a very flat structure.
+
+*Legacy Customer Service Class*
+
+[source,java]
+-----------------------------------------------------------------------------------
+public class Customer {
+ private String firstName;
+ private String lastName;
+ private String street;
+ private String zip;
+
+ public Customer() {}
+
+ public Customer(String firstName, String lastName, String zip, String street) {
+ this.firstName = firstName;
+ this.lastName = lastName;
+ this.zip = zip;
+ this.street = street;
+ }
+
+ public String getFirstName() {
+ return firstName;
+ }
+
+ public void setFirstName(String firstName) {
+ this.firstName = firstName;
+ }
+
+ ... getters and setters for each field
+-----------------------------------------------------------------------------------
+
+In the next version it was decided to structure the data better in the
+model by moving the address data into its own type, with the resulting
+domain object ending up looking like the below.
+
+*Next Gen Customer object*
+
+[source,java]
+-------------------------------------------------------------------------
+public class Customer {
+ private String firstName;
+ private String lastName;
+ private Address address;
+
+ public Customer() {}
+
+ public Customer(String firstName, String lastName, Address address) {
+ this.firstName = firstName;
+ this.lastName = lastName;
+ this.address = address;
+ }
+ ....
+
+
+public class Address {
+ private String zipCode;
+ private String streetName;
+
+ public Address() {}
+
+ public Address(String zipCode, String streetName) {
+ this.zipCode = zipCode;
+ this.streetName = streetName;
+ }
+-------------------------------------------------------------------------
+
+Much nicer! But as often occurs, the previous version of the service,
+with the old flat 'Customer' object, was in production with a client and
+the project must support the legacy interface. To support both versions,
+we must add a mechanism to convert between the old Customer service type
+and the new Customer domain type and back again. It would be a simple
+matter to write a custom converter class to map between them, but this
+may not be the only service/domain inconsistency and these tedious and
+error prone custom mappings could quickly start to add up, and bugs with
+them.
+
+To a large extent the two objects share an identical structure, with only
+the address representation being different. It would be very helpful if
+there were a practical way to automate this kind of mapping, such
+that the similar properties could get mapped automatically and only the
+inconsistencies requiring custom mapping.
+
+This is where Dozer comes in; it uses reflection to map data between two
+bean types using a set of simple mapping rules. Where no rule is
+specified, Dozer will attempt to map between them by using matching
+properties of two beans. In this way, focus can be given to the
+inconsistencies between the beans i.e. the address properties, knowing
+that Dozer will automatically match and convert the others.
+
+=== Configuring Dozer Type Converter
+
+Dozer's configuration is extremely flexible and many mapping scenarios
+are covered https://github.com/DozerMapper/dozer/blob/master/docs/asciidoc/documentation/mappings.adoc[here].
+For our simple example, the configuration looks like the following.
+
+*mapping.xml*
+
+[source,xml]
+---------------------------------------------------------------------------------------------------------
+<mappings xmlns="http://dozermapper.github.io/schema/bean-mapping"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="http://dozermapper.github.io/schema/bean-mapping http://dozermapper.github.io/schema/bean-mapping.xsd">
+ <mapping>
+ <class-a>org.apache.camel.converter.dozer.service.Customer</class-a>
+ <class-b>org.apache.camel.converter.dozer.model.Customer</class-b>
+ <field>
+ <a>street</a>
+ <b>address.streetName</b>
+ </field>
+ <field>
+ <a>zip</a>
+ <b>address.zipCode</b>
+ </field>
+ </mapping>
+</mappings>
+---------------------------------------------------------------------------------------------------------
+
+=== Support for Dozer in Camel Type Converter
+
+Camel provides a simple mechanism to integrate Dozer Mappers with it's
+own powerful xref:manual::type-converter.adoc[Type Conversion] framework.
+Its configured by creating an instance of `DozerTypeConverterLoader`
+providing it the camel context and an optional Dozer mapper.
+
+If no mapper is supplied, Camel's registry will
+be searched for suitable instances. The loader will query the Dozer
+Mapper for the types it converts and register them with Camel's
+type conversion framework to be handled by the mapper.
+
+[NOTE]
+====
+*Limitation*
+
+The Camel Dozer type converter does not support having the same type
+conversion pairs in different mapping ids (eg map-id) in Dozer.
+====
+
+In Java it can be configured as follows:
+
+[source,java]
+-----------------------------------------------------------------------------------------
+Mapper mapper = DozerBeanMapperBuilder.create()
+ .withMappingFiles("mapping.xml")
+ .build();
+
+new DozerTypeConverterLoader(camelContext, mapper);
+-----------------------------------------------------------------------------------------
+
+Or in Spring XML:
+
+[source,xml]
+--------------------------------------------------------------------------------------------------
+<bean id="dozerConverterLoader" class="org.apache.camel.converter.dozer.DozerTypeConverterLoader">
+ <argument index="0" ref="myCamel"/>
+ <argument index="1" ref="mapperConfiguration"/>
+</bean>
+
+<bean id="mapperConfiguration" class="org.apache.camel.converter.dozer.DozerBeanMapperConfiguration">
+ <property name="mappingFiles">
+ <list>
+ <value>mapping.xml</value>
+ </list>
+ </property>
+</bean>
+
+<camelContext id="myCamel" xmlns="http://camel.apache.org/schema/spring">
+ ...
+</camelContext>
+--------------------------------------------------------------------------------------------------
+
+Now, where necessary, Camel will use Dozer to do conversions; in our
+case between the new domain and legacy Customer types e.g.
+
+[source,java]
+---------------------------------------------------------------------------------------------------------------------------------------------
+// given the following route
+from("direct:legacy-service-in").bean(new CustomerProcessor());
+
+// and a processor
+
+public class CustomerProcessor {
+
+ public Customer processCustomer(org.apache.camel.converter.dozer.model.Customer customer) {
+ ...
+ }
+}
+
+// service objects can be sent to the processor and automagically converted by Camel & Dozer
+template.sendBody("direct:legacy-service-in", new org.apache.camel.converter.dozer.service.Customer("Bob", "Roberts", "12345", "1 Main st."));
+---------------------------------------------------------------------------------------------------------------------------------------------
+
+
+
include::{page-component-version}@camel-spring-boot::page$dozer-starter.adoc[]
diff --git a/docs/user-manual/modules/ROOT/nav.adoc b/docs/user-manual/modules/ROOT/nav.adoc
index 4522dd8..af8468f 100644
--- a/docs/user-manual/modules/ROOT/nav.adoc
+++ b/docs/user-manual/modules/ROOT/nav.adoc
@@ -41,7 +41,6 @@
** xref:data-format.adoc[Data Format]
** xref:debugger.adoc[Debugger]
** xref:delay-interceptor.adoc[Delayer]
-** xref:dozer-type-conversion.adoc[Dozer Type Conversion]
** xref:endpoint.adoc[Endpoints]
** xref:endpoint-annotations.adoc[Endpoint Annotations]
** xref:exception-clause.adoc[Exception Clause]
diff --git a/docs/user-manual/modules/ROOT/pages/dozer-type-conversion.adoc b/docs/user-manual/modules/ROOT/pages/dozer-type-conversion.adoc
deleted file mode 100644
index a32ab6a..0000000
--- a/docs/user-manual/modules/ROOT/pages/dozer-type-conversion.adoc
+++ /dev/null
@@ -1,204 +0,0 @@
-[[DozerTypeConversion-DozerTypeConversion]]
-= Dozer Type Conversion
-
-https://github.com/DozerMapper/dozer/blob/master/docs/asciidoc/about/about.adoc[Dozer] is a fast
-and flexible framework for mapping back and forth between Java Beans.
-Coupled with Camel's automatic type conversion, it's a formidable tool
-for dealing object to object mapping headaches that crop up in
-enterprise integration projects.
-
-To explain how Dozer can be used within Camel we'll use the following
-example of a simple Customer Support Service. The initial version of the
-Service defined a 'Customer' object used with a very flat structure.
-
-*Legacy Customer Service Class*
-
-[source,java]
------------------------------------------------------------------------------------
-public class Customer {
- private String firstName;
- private String lastName;
- private String street;
- private String zip;
-
- public Customer() {}
-
- public Customer(String firstName, String lastName, String zip, String street) {
- this.firstName = firstName;
- this.lastName = lastName;
- this.zip = zip;
- this.street = street;
- }
-
- public String getFirstName() {
- return firstName;
- }
-
- public void setFirstName(String firstName) {
- this.firstName = firstName;
- }
-
- ... getters and setters for each field
------------------------------------------------------------------------------------
-
-In the next version it was decided to structure the data better in the
-model by moving the address data into its own type, with the resulting
-domain object ending up looking like the below.
-
-*Next Gen Customer object*
-
-[source,java]
--------------------------------------------------------------------------
-public class Customer {
- private String firstName;
- private String lastName;
- private Address address;
-
- public Customer() {}
-
- public Customer(String firstName, String lastName, Address address) {
- this.firstName = firstName;
- this.lastName = lastName;
- this.address = address;
- }
- ....
-
-
-public class Address {
- private String zipCode;
- private String streetName;
-
- public Address() {}
-
- public Address(String zipCode, String streetName) {
- this.zipCode = zipCode;
- this.streetName = streetName;
- }
--------------------------------------------------------------------------
-
-Much nicer! But as often occurs, the previous version of the service,
-with the old flat 'Customer' object, was in production with a client and
-the project must support the legacy interface. To support both versions,
-we must add a mechanism to convert between the old Customer service type
-and the new Customer domain type and back again. It would be a simple
-matter to write a custom converter class to map between them, but this
-may not be the only service/domain inconsistency and these tedious and
-error prone custom mappings could quickly start to add up, and bugs with
-them.
-
-To a large extent the two objects share an identical structure, with only
-the address representation being different. It would be very helpful if
-there were a practical way to automate this kind of mapping, such
-that the similar properties could get mapped automatically and only the
-inconsistencies requiring custom mapping.
-
-This is where Dozer comes in; it uses reflection to map data between two
-bean types using a set of simple mapping rules. Where no rule is
-specified, Dozer will attempt to map between them by using matching
-properties of two beans. In this way, focus can be given to the
-inconsistencies between the beans i.e. the address properties, knowing
-that Dozer will automatically match and convert the others.
-
-[[DozerTypeConversion-ConfiguringDozer]]
-== Configuring Dozer
-
-Dozer's configuration is extremely flexible and many mapping scenarios
-are covered https://github.com/DozerMapper/dozer/blob/master/docs/asciidoc/documentation/mappings.adoc[here].
-For our simple example, the configuration looks like the following.
-
-*mapping.xml*
-
-[source,xml]
----------------------------------------------------------------------------------------------------------
-<mappings xmlns="http://dozermapper.github.io/schema/bean-mapping"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://dozermapper.github.io/schema/bean-mapping http://dozermapper.github.io/schema/bean-mapping.xsd">
- <mapping>
- <class-a>org.apache.camel.converter.dozer.service.Customer</class-a>
- <class-b>org.apache.camel.converter.dozer.model.Customer</class-b>
- <field>
- <a>street</a>
- <b>address.streetName</b>
- </field>
- <field>
- <a>zip</a>
- <b>address.zipCode</b>
- </field>
- </mapping>
-</mappings>
----------------------------------------------------------------------------------------------------------
-
-[[DozerTypeConversion-SupportforDozerinCamel]]
-== Support for Dozer in Camel
-
-Camel provides a simple mechanism to integrate Dozer Mappers with it's
-own powerful xref:type-converter.adoc[Type Conversion] framework.
-Its configured by creating an instance of `DozerTypeConverterLoader`
-providing it the camel context and an optional Dozer mapper.
-
-If no mapper is supplied, Camel's registry will
-be searched for suitable instances. The loader will query the Dozer
-Mapper for the types it converts and register them with Camel's
-type conversion framework to be handled by the mapper.
-
-[NOTE]
-====
-*Limitation*
-
-The Camel Dozer type converter does not support having the same type
-conversion pairs in different mapping ids (eg map-id) in Dozer.
-====
-
-In Java it can be configured as follows:
-
-[source,java]
------------------------------------------------------------------------------------------
-Mapper mapper = DozerBeanMapperBuilder.create()
- .withMappingFiles("mapping.xml")
- .build();
-
-new DozerTypeConverterLoader(camelContext, mapper);
------------------------------------------------------------------------------------------
-
-Or in Spring XML:
-
-[source,xml]
---------------------------------------------------------------------------------------------------
-<bean id="dozerConverterLoader" class="org.apache.camel.converter.dozer.DozerTypeConverterLoader">
- <argument index="0" ref="myCamel"/>
- <argument index="1" ref="mapperConfiguration"/>
-</bean>
-
-<bean id="mapperConfiguration" class="org.apache.camel.converter.dozer.DozerBeanMapperConfiguration">
- <property name="mappingFiles">
- <list>
- <value>mapping.xml</value>
- </list>
- </property>
-</bean>
-
-<camelContext id="myCamel" xmlns="http://camel.apache.org/schema/spring">
- ...
-</camelContext>
---------------------------------------------------------------------------------------------------
-
-Now, where necessary, Camel will use Dozer to do conversions; in our
-case between the new domain and legacy Customer types e.g.
-
-[source,java]
----------------------------------------------------------------------------------------------------------------------------------------------
-// given the following route
-from("direct:legacy-service-in").bean(new CustomerProcessor());
-
-// and a processor
-
-public class CustomerProcessor {
-
- public Customer processCustomer(org.apache.camel.converter.dozer.model.Customer customer) {
- ...
- }
-}
-
-// service objects can be sent to the processor and automagically converted by Camel & Dozer
-template.sendBody("direct:legacy-service-in", new org.apache.camel.converter.dozer.service.Customer("Bob", "Roberts", "12345", "1 Main st."));
----------------------------------------------------------------------------------------------------------------------------------------------
diff --git a/docs/user-manual/modules/ROOT/pages/index.adoc b/docs/user-manual/modules/ROOT/pages/index.adoc
index ae53a1a..31d529e 100644
--- a/docs/user-manual/modules/ROOT/pages/index.adoc
+++ b/docs/user-manual/modules/ROOT/pages/index.adoc
@@ -77,7 +77,6 @@ For a deeper and better understanding of Apache Camel, an xref:faq:what-is-camel
* xref:data-format.adoc[Data Format]
* xref:debugger.adoc[Debugger]
* xref:delay-interceptor.adoc[Delayer]
-* xref:dozer-type-conversion.adoc[Dozer Type Conversion]
* xref:dsl.adoc[DSL]
* xref:endpoint.adoc[Endpoint]
* xref:endpoint-annotations.adoc[Endpoint Annotations]