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:
At the end headers can be enriched/modified from the java bean:
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