On Tue, Nov 1, 2016 at 4:15 PM, Luca Burgazzoli <lburgazz...@gmail.com> wrote:
> Something like:
>
> public void configure() throws Exception {
> from("direct:start")
> .aggregate()
> .always()
> .body(String.class, (existing, next) -> next + existing)
> .completionSize(3)
> .to("mock:result");
> }
>
Yeah that seems really good. And I guess always is a shorthand for
constant(true). For that we may need to ponder if we want to have
these in the Java DSL as they are not in XML DSL, so people cannot map
from Java <-> XML as easily.
So its maybe
aggregate()
.constant(true)
.withStrategy(body(String.class, (existing, next) -> next + existing))
.completionSize(3)
And for Content Enricher
enrich("http://foobar";)
.withStrategy(body(String.class, (existing, next) -> next + existing))
> ---
> Luca Burgazzoli
>
>
> On Tue, Nov 1, 2016 at 7:44 PM, Claus Ibsen <claus.ib...@gmail.com> wrote:
>> Hi
>>
>> Not yet, but maybe some of those POJO examples in the aggregator EIP.
>> For example to supply a function as a lambda that is used for
>> aggregation. For example how would it look like if it was just a basic
>> function for String concat?
>>
>> For example this example
>>
>> public void configure() throws Exception {
>> from("direct:start")
>> .aggregate(constant(true),
>> AggregationStrategies.bean(MyBodyAppender.class, "append"))
>> .completionSize(3)
>> .to("mock:result");
>> }
>>
>>
>> Also wonder if the lambda can cope with either working with exchange
>> vs message body only. A bit like what you can do today for message
>> transformation you did.
>>
>>
>> On Tue, Nov 1, 2016 at 1:00 PM, Luca Burgazzoli <lburgazz...@gmail.com>
>> wrote:
>>> Hi Claus,
>>>
>>> do you have any simple use case to be used as reference to prototype
>>> new Java 8 DSL extensions ?
>>>
>>> ---
>>> Luca Burgazzoli
>>>
>>>
>>> On Tue, Nov 1, 2016 at 12:09 PM, Claus Ibsen <claus.ib...@gmail.com> wrote:
>>>> Hi
>>>>
>>>> I would like to see if we could experiment with continue improving the
>>>> Java DSL for Java 8 to see if we can make it more Java 8'ish for
>>>> Content Enricher and Aggregator EIP. They require using the
>>>> AggregationStrategy interface when you need to merge the 2 exchanges.
>>>> And it has a POJO binding that allows you to build custom POJO classes
>>>> without implementing this interface but following a convention. See
>>>> more at: http://camel.apache.org/aggregator2 in the bottom.
>>>>
>>>> And there may be other areas we could ponder about. But the
>>>> AggregationStrategy has always been one I would like to see can be
>>>> done simpler when you have simpler use-cases, and hence the POJOs or
>>>> the FlexibleAggregationStragegyBuilder we have in camel-core
>>>> somewhere.
>>>>
>>>> This is just a quick email to get this though out.
>>>>
>>>>
>>>>
>>>> --
>>>> 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
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
