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 <[email protected]> wrote:
> On Wed, Sep 7, 2016 at 3:47 PM, Luca Burgazzoli <[email protected]> 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 <[email protected]> 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 <[email protected]> пише:
>>>
>>>> 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 <[email protected]> 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 <[email protected]> пише:
>>>> >
>>>> >> 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
