[
https://issues.apache.org/jira/browse/CAMEL-13302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-13302.
---------------------------------
Resolution: Won't Fix
> Instrument mapping between Message Headers and Plain Java Beans
> ---------------------------------------------------------------
>
> Key: CAMEL-13302
> URL: https://issues.apache.org/jira/browse/CAMEL-13302
> Project: Camel
> Issue Type: New Feature
> Components: extra
> Environment: JDK8
> Reporter: Adelino Rodrigues
> Priority: Trivial
> Labels: binding, headers, message, processor
>
> When developing Processor implementations to be used in Camel routes, some
> portion of the code is devoted to retrieving data from Message headers, and
> after the actual process takes place, setting the resulting headers in the
> Message.
> As this manual binding of headers to java bean properties is custom, it needs
> to be verified in unit tests. When talking about a few processors to
> implement, it is not at all an issue. But when you have a high number of
> processors, a consistent and tested approach is preferable to the custom code
> repeated in every processor.
> This issue is raised to introduce a new feature for declaratively mapping
> message headers to Plain Java bean properties in the style of the [at]Column
> JPA annotation.
> A mapper instantiated from the Plain Java bean class, then populates the Java
> bean properties:
> {code:java}
> mapper.fromHeaders(headers, myObj);{code}
>
> At the end headers can be enriched/modified from the java bean:
> {code:java}
> mapper.toHeaders(myObj, headers);{code}
> This allows the Camel Processor implementation to be less verbose, and the
> binding becomes more consistent against implementations.
> I developed a prototype which illustrates the principles above using headers
> in the form of a {{Map<String, Object>}} : see
> [https://github.com/adelinor/messaging-header-mapper]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
