On Wed, Sep 7, 2016 at 11:39 AM, Luca Burgazzoli <lburgazz...@gmail.com> wrote: > In line comments. > > --- > Luca Burgazzoli > > > On Wed, Sep 7, 2016 at 10:34 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: >> Hi Luca >> >> Good to see some experiments with this. >> >> The OUT functions is not needed as end users would only work with the >> IN message in the routes. We have deprecated OUT stuff in the Java DSL >> in some places. >> > > Removed out and reduced to a single function method, this requires to explicit > set the type like: > > function((Message m) -> m.getBody() ) > function((Exchange e) -> e.getIn()) > > Is that ok ? >
I think we need to tweak this a bit to find the right balance. Would like if we could omit the type for normal use-cases. Working on Message is a bit shorter than Exchange as you can call getBody / getHeader asap. And if you need Exchange there is a getExchange method. >> Just a mind that the goal of Camel 2.18 is to be a gentle Java8 >> upgrade where the APIs are backwards compatible, so end users can take >> any existing Java 7 based Camel 2.17 or older and compile as Java 8 >> and run on Camel 2.18 as-is. >> >> Therefore we have so far only done Java 8 stuff internally in Camel, >> eg inside component implementations and so on. >> >> But your changes seems non invasive and can be a candidate to include. >> But we could consider marking that as "experimental" so we can do API >> changes for the next release, and when we get more hands down on Camel >> 3.0 where the APIs can be more Java 8 aggressive. >> > > Is there an annotation or documentation convention for that ? > No we dont have that, but we can add to javadoc that its "work in progress" or "subject for change" or something. Just so we have freedom to change it in the following release(s). >> Also mind that a goal of the DSL is also to let Java and XML be 1:1 so >> end users can use the same EIPs in either one, and usually an easy >> migration between them, as they are similar. Just be more cautious >> when working on Java DSL that you dont end up in a situation with >> something that is not possible to do in XML. > > I think in xml it will be more about bean binding/method reference so it > should work out of the box but I will test it before merging. > > >> Also we should avoid turning the Java DSL into un-readable and >> cluttered/complex DSL as the Spring Integration Java DSL: >> https://github.com/spring-projects/spring-integration-samples/blob/master/dsl/cafe-dsl/src/main/java/org/springframework/integration/samples/dsl/cafe/lambda/Application.java >> >> But this is a great start, and like that its gentle and only about >> doing lambda style functions as Camel expressions. >> >> >> >> >> >> >> >> On Tue, Sep 6, 2016 at 5:37 PM, Luca Burgazzoli <lburgazz...@gmail.com> >> wrote: >>> Hello everyone, >>> I've started working on CAMEL-7831 to create a Java8 example to use >>> Expressions and I've ended up with a simple example - see [1]. >>> Of course it is only for demonstrative purpose. >>> >>> Java8 lambda support to Expressions has been added to >>> - ExpressionClause to avoid adding overload method for every method >>> accepting an Expressions definition >>> - ExpressionBuilder so you can use something like transform(function(e -> >>> ...)) >>> >>> There are some additional functional interfaces to select the argument >>> of the lambda >>> - ExchangeFunction >>> - MessageFunction >>> - BodyFunction >>> >>> >>> Any feedback would be really appreciated. >>> >>> Regards, >>> Luca >>> >>> >>> [1] >>> https://github.com/lburgazzoli/apache-camel/blob/CAMEL-7831/examples/camel-example-dsl-java8/src/main/java/org/apache/camel/example/dsl/java8/MyRoute.java >>> >>> >>> --- >>> Luca Burgazzoli >> >> >> >> -- >> Claus Ibsen >> ----------------- >> http://davsclaus.com @davsclaus >> Camel in Action 2: https://www.manning.com/ibsen2 -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
