Would it make sense to add also a ProcessClause (later on) to have something similar for process ?
process() .exchange(e -> ...) // not needed but for consistency process() .message(m -> ...) process() .body(b -> ... ) // should return the body --- Luca Burgazzoli On Wed, Sep 7, 2016 at 4:02 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > On Wed, Sep 7, 2016 at 3:47 PM, Luca Burgazzoli <lburgazz...@gmail.com> wrote: >> @Clauss >> >> - I've removed intermediate funtional interfaces like ExchangeFunction >> - added simple message(...) >> >> Result here: >> 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 >> > > Yay looks much nicer and simpler. > >> @Vitalii >> It may be nice to support existing expressions, like: >> >> transform().body( >> String.class, >> String::indexOf, >> header("toFindHeader", String.class) >> ) >> >> Maybe this deserve an additional JIRA >> > > Yeah lets avoid making the first version too complex and to many bells > and whistles. > It just becomes too confusing with functional lambdas extreme here, > and then regular DSL with EIPs not as functional. > > > > >> >> --- >> Luca Burgazzoli >> >> >> On Wed, Sep 7, 2016 at 2:45 PM, Vitalii Tymchyshyn <v...@tym.im> wrote: >>> Sure, I really appreciate the effort, especially since I am now also >>> working on making Camel more J8-friendly (in the reactive programming part). >>> Please don't forget ".mandatoryBody", it's extremely useful. It produces >>> much nicer exception instead of just NPE if your body is of wrong type or >>> null. I'd even vote for making .body(Class, Function) calling mandatoryBody >>> on exchange, since .getBody(class) gives much confusion in error cases when >>> body of a wrong type, but I am not sure if it would be consistent with >>> existing code. >>> Also talking about BiFunctions, consider passing not only map, but also >>> exact header or property as again it makes it very easy to use tons of >>> 2-parameter preexisting methods, may be even something like this can be >>> done: >>> transform().body(BiFunction).withHeader("headerName") >>> transform().body(BiFunction).withProperty("propertyName") >>> >>> that would make something like the next possible: >>> transform().body(String::indexOf).withHeader("toFindHeader") >>> >>> BTW: It would be great to have async versions, like .asyncBody(Class, >>> Function<Object, CompletableStage>) >>> >>> Best regards, Vitalii Tymchyshyn >>> >>> Ср, 7 вер. 2016 о 08:22 Luca Burgazzoli <lburgazz...@gmail.com> пише: >>> >>>> Vitalii, it was the first iteration just to have some feedbacks ;) >>>> >>>> I've added something more now as experiment so your suggestions should >>>> have been covered now. >>>> By extending ExpressionClause built-in body/inMessage/etc, we could >>>> have something like: >>>> >>>> from("timer:simple?period=503") >>>> .id("simple-route") >>>> .transform() >>>> .exchange(this::dateToTime) >>>> .choice() >>>> .when() >>>> .body(Integer.class, b -> (b & 1) == 0) >>>> .log("Received even number") >>>> .when() >>>> .body(Integer.class, (b, h) -> h.containsKey("skip") ? >>>> false : (b & 1) == 0) >>>> .log("Received odd number") >>>> .when() >>>> .body(b -> b instanceof Number) >>>> .log("Received a number number") >>>> .when() >>>> .inMessage(m -> m.getBody() == null) >>>> .log("Received null body") >>>> .when() >>>> .body(Integer.class, b -> (b & 1) == 0) >>>> .log("Received odd number") >>>> .endChoice(); >>>> >>>> >>>> >>>> --- >>>> Luca Burgazzoli >>>> >>>> >>>> On Wed, Sep 7, 2016 at 2:16 PM, Vitalii Tymchyshyn <v...@tym.im> wrote: >>>> > Hi. >>>> > >>>> > Why BodyFunction is a BiFunction? It would be great to have some method >>>> to >>>> > pass any Functional interface (any function) that would receive body as >>>> > parameter and result would be stored as an answer. This would allow to >>>> use >>>> > tons of existing functional method. >>>> > E.g. something like this would be possible: >>>> > .transform(function(String.class, String::toUpperCase)) >>>> > Another thing is that often body type is not needed, e.g. >>>> > .transform(onBody(String::toUpperCase)) looks more readable. >>>> > i'd also rename other "function" calls with something that gives more >>>> > information like "onExchange", "onMessage" (or even simply body(), >>>> > exchange(), message()). This would also make casting unnesessary. >>>> > >>>> > Best regards, Vitalii Tymchyshyn >>>> > >>>> > Вт, 6 вер. 2016 о 11:38 Luca Burgazzoli <lburgazz...@gmail.com> пише: >>>> > >>>> >> 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