Hi Camel developers,

I'd like to propose an enhancement on handling data types of Camel message 
contents. To start a smooth discussion I implemented the idea first:
https://github.com/igarashitm/camel/tree/contract-based-type-awareness

And these testcases demonstrates the declarative transformer usage according to 
the declared data types:
[Java DSL] 
https://github.com/igarashitm/camel/commit/498c27d2ba99b04bbe7b90a93329d42b7c718a29#diff-c14a7e8e88a6e41492946e1537bfb1cf
[Spring DSL] 
https://github.com/igarashitm/camel/commit/498c27d2ba99b04bbe7b90a93329d42b7c718a29#diff-b2506c84ddde91438fc6374039e21534

This adds input/output content type declaration on from and all other 
processors. It also introduces well-known Exchange properties, INPUT_TYPE and 
OUTPUT_TYPE which are used to specify the current message content type. The 
data type is URN like string starts with scheme, like java:org.example.ItemA or 
xml:{org.example.xml}ItemA.

If the content type is declared via inputType/outputType/contract, the ContractProcessor 
wraps the actual processor and process transformation/validation according to the type, say 
if INPUT_TYPE exchange property has xml:{org.example.xml}ItemA and the declared inputType 
is xml:{org.example.xml}ItemB, then it transforms xml:{org.example.xml}ItemA content into 
xml:{org.example.xml}ItemB. The <transformers> element which is introduced right 
under the <camelContext> is the one to declare the mappings between transformer 
implementation and those from/to data type. I implemented only transformer first, but 
validator would be brought in in a same way. This way allows users to make data types 
visible in the route definition and keep the transformation/validation apart from route 
definition itself.

The most important thing is that the ContractProcessor is involved only when 
content type is explicitly declared in a route definition, so that it never 
breaks existing camel routes. Ofcourse programatic transformations/validations 
we're doing today are still fully available. It's purely an addition to the 
existing camel features.

Any thoughts? Does it sound acceptable to get merged into camel? ANY feedback 
would be really appreciated!

Thanks,
Tomo

Reply via email to