You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Claus Ibsen (JIRA)" <ji...@apache.org> on 2015/03/21 11:02:38 UTC

[jira] [Resolved] (CAMEL-7838) Aggregator - Using groupExchanges should store them on body mid-processing

     [ https://issues.apache.org/jira/browse/CAMEL-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen resolved CAMEL-7838.
--------------------------------
    Resolution: Won't Fix
      Assignee: Claus Ibsen

Use your own strategy if you want some kind of serialized repo of a list of pojos.



> Aggregator - Using groupExchanges should store them on body mid-processing
> --------------------------------------------------------------------------
>
>                 Key: CAMEL-7838
>                 URL: https://issues.apache.org/jira/browse/CAMEL-7838
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 2.13.2
>            Reporter: Marc Carter
>            Assignee: Claus Ibsen
>            Priority: Minor
>
> CAMEL-6744 encompassed setting the List<V> into the body {{onCompletion}} only when using anything based on {{AbstractListAggregationStrategy}}
> However any strategies based on this class cannot be used with a persistent repository because the GROUPED_EXCHANGE property appears not to be serialised so keeps being reset to the latest message only.
> (I spotted this by checking properties in the completion predicate and AGGREGATED_SIZE != GROUPED_EXCHANGE.size())
> Given this limitation, it doesn't seem sensible to only promote to the body on completion. The only reason I can think of is to limit regression to existing completionPredicates that expect the first message in {{body}} instead of {{body.get(0)}}. That said, CAMEL-6744 already introduced this change to the subsequent route.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)