camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Babo (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CAMEL-8332) Add component implementation to camel-dozer module
Date Mon, 02 Mar 2015 03:22:04 GMT

    [ https://issues.apache.org/jira/browse/CAMEL-8332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14342660#comment-14342660
] 

Keith Babo commented on CAMEL-8332:
-----------------------------------

Hey Claus - completed all of the changes I want to see, but haven't submitted a PR yet as
I want to add a few more tests.  Here's the branch for reference:
https://github.com/kcbabo/camel/tree/more-dozer

Updates include:
* Added a new converter which allows the user to evaluate an expression using Camel language
support and assign it to an output field.
* Enabled javax.el support to allow variables to be used in mappings.
* Added the ability to specify a context id via a message header or endpoint parameter to
take advantage of context-based mappings in Dozer.
* Users can specify the name of a DozerBeanMapperConfiguration bean instead of a Dozer mapping
file to allow for fine-grained configuration of the Dozer environment.
* The sourceModel option is actually used now and targetModel is marked as required.

Should I open a new JIRA for these updates or just submit another PR against CAMEL-8332? 
I will have the tests done and the PR ready tomorrow.

> Add component implementation to camel-dozer module
> --------------------------------------------------
>
>                 Key: CAMEL-8332
>                 URL: https://issues.apache.org/jira/browse/CAMEL-8332
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-dozer
>            Reporter: Keith Babo
>            Assignee: Claus Ibsen
>             Fix For: 2.15.0
>
>
> The camel-dozer component does not actually provide a Camel component implementation
today.  Rather, it provides a converter loader which can be used in combination with a set
of Dozer mapping files to register a global set of converters within a CamelContext.  This
issue proposes the addition of a full-blown component implementation within camel-dozer. 
Advantages of this approach include:
> * The ability to manage Dozer mapping configuration on a per-endpoint basis vs. global
configuration via the converter registry.
> * Dozer handles direct field assignment quite well, but does not provide other common
mapping functions OOTB.  Camel can enrich Dozer via standard Dozer extensions, e.g.
> ** Mapping constant values to target fields
> ** Support for lookup tables, using the source value as the key
> ** Convenience transformations for mappings (e.g. trim spaces, convertToLowerCase, regular
expression evaluation)
> ** Allow Camel message/exchange headers to be mapped to target fields
> * The ability to surround dozer mappings with data formats to support a single, any-to-any
transformation endpoint
> Here's an example of what the endpoint configuration would look like.
> {noformat}
> dozer:mytransform?mappingFile=dozerBeanMapping.xml&marshalId=json&unmarshalId=jaxb&targetModel=example.MyObject
> {noformat}
> An initial implementation of this component is available as a PR against the Camel GitHub
repository.  Unit tests in the PR provide examples of various transformation use cases.  Many,
but not all, of the features listed above are implemented already.  I can file follow-up JIRAs
for additional features I have in mind.  I will also post a link to the PR and the topic branch
in the issue comments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message