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)