On Mon, Oct 17, 2016 at 4:35 AM, Tomohisa Igarashi <tm.igara...@gmail.com> wrote: > Hi, > > I'd like to resume the discussion about this. I still think 3.0 would be the > best target to get this feature fully supported, but to achieve it in better > shape, I'd like to have it in 2.19 as well as an experimental, ask feedback > and then reflect those for 3.0 full support. Fortunately this is purely an > addition to existing features, i.e. is not breaking any existing API. What > do you think? >
Having community feedback would be great. I wonder if you would mind creating a little example in the examples that uses this new feature. Then its easier for users to look at and better understand what its about. Also when we do DSL changes/additions we tend to write unit tests in camel-core, and then reuse those tests in camel-spring where we extend the unit test from camel-core-test and then provide the routes in XML DSL instead of java code. Then the unit test is the same and ensures the DSL works in both worlds (Java and XML). I am not sure if you have this in your commits? You can take a look at the existing tests in camel-spring to find some examples of this practice. Down the road we do have some kind of typeawareness with the rest-dsl where you can also specify in and output types which the swagger api-doc uses. And it does some automatic binding to/from pojo/xml/json. So we may have some overlap here, and may ponder if there is something we can eventually make use the new typeware stuff or meet in the middle or something. However maybe its better to take a look at that after the other stuff is more ready. Also in Java DSL you may want to allow to specify a java type using the Class as type instead of having to type the FQN in a String. But mind in XML DSL this is not possible where you specify a String attribute for the type. > Thanks, > Tomo > > > On 09/17/2016 10:20 PM, Tomohisa Igarashi wrote: >> >> Hi Claus, >> >> Thanks for the reply. Sure that's fine, I agree 3.0 would be better to be >> targeted than 2.x as this introduces some schema updates. >> >> Including this one, I'm always looking for the chance to make any >> contribution to Camel. If there's anything I can help please let me know. >> >> Thanks, >> Tomo >> >> On 09/17/2016 06:33 PM, Claus Ibsen wrote: >>> >>> 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
