Hey Can we take this discussion post Camel 2.18 release.
We are working on the last details to get it ready, and its our main focus to get this new release out. After this release we will pickup talks about the next releases whether that is 2.19 or 3.0, and for the latter what the broad goals of that is. What you talk about seems more of a 3.0 candidate to me, than on 2.x. On Fri, Sep 16, 2016 at 6:50 AM, Tomohisa Igarashi <tm.igara...@gmail.com> wrote: > 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 -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
