Yep, "always()" was how my mind translated "constant(true)", do not
know how it ended up in the mail :O

What about:

aggregate()
  .correlation()
      .body(String.class, b -> b.substring(0, 3))
  .strategy()
      .body(String.class, (existing, next) ->  next + existing))
  .completionSize(3)

---
Luca Burgazzoli


On Wed, Nov 2, 2016 at 12:07 PM, Claus Ibsen <claus.ib...@gmail.com> wrote:
> 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

Reply via email to