You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by solimo <ro...@budzko.eu> on 2013/07/08 19:01:59 UTC
Enricher - coping strategy
Hello!
After few route implementations which use enricher I've found it quite
inconvenient to copy whole exchange. The concept is quite brilliant, but
could anyone explain why, instead of implementing some
ExchangeCreateStrategt (like AggregationStrategy for aggregation), the whole
exchange is being copied? I can see two drawbacks here:
1. When a message is quite heavy we will suffer (although it can be
workarounded by implementing own Message and overriding copy method).
2. Usually, we do not need whole in message (to process in enricher target),
so it's quite pointless to copy it as a whole and then transform (or select
part of it) to format which is required.
So far, we've ended with own implementation of Enricher which requires
additional bean reference of processor which copies exchange (in our case,
it is used to select interesting data and fill new exchange with appropriate
data format) in desired way.
Any way, I'm really curious why enricher has been implemented in such a way
by Camel Team. Any reason? Maybe I miss something important :)!
Robert Budźko
--
View this message in context: http://camel.465427.n5.nabble.com/Enricher-coping-strategy-tp5735290.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Enricher - coping strategy
Posted by Claus Ibsen <cl...@gmail.com>.
What kind of message body types do you have?
The copy is a shallow copy so it shouldn't be expensive.
On Wed, Jul 10, 2013 at 10:42 AM, solimo <ro...@budzko.eu> wrote:
> Hi!
>
>
> Claus Ibsen-2 wrote
>> This is working as designed.
>>
>> When using the enricher EIPs then the idea is that having the original
>> message and the new message to combine these into a original message
>> that is enriched with information from the new message.
>
> I see. Any idea how would you handle "expensive" message which we want to
> enrich :) ? Do not user enricher :)? Store expensive part in property?
> Reimplement message copy method? Tbh, those ideas sounds fishy to me.
>
> Robert
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Enricher-coping-strategy-tp5735290p5735415.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: Enricher - coping strategy
Posted by solimo <ro...@budzko.eu>.
Hi!
Claus Ibsen-2 wrote
> This is working as designed.
>
> When using the enricher EIPs then the idea is that having the original
> message and the new message to combine these into a original message
> that is enriched with information from the new message.
I see. Any idea how would you handle "expensive" message which we want to
enrich :) ? Do not user enricher :)? Store expensive part in property?
Reimplement message copy method? Tbh, those ideas sounds fishy to me.
Robert
--
View this message in context: http://camel.465427.n5.nabble.com/Enricher-coping-strategy-tp5735290p5735415.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Enricher - coping strategy
Posted by Claus Ibsen <cl...@gmail.com>.
This is working as designed.
When using the enricher EIPs then the idea is that having the original
message and the new message to combine these into a original message
that is enriched with information from the new message.
On Mon, Jul 8, 2013 at 7:01 PM, solimo <ro...@budzko.eu> wrote:
> Hello!
>
> After few route implementations which use enricher I've found it quite
> inconvenient to copy whole exchange. The concept is quite brilliant, but
> could anyone explain why, instead of implementing some
> ExchangeCreateStrategt (like AggregationStrategy for aggregation), the whole
> exchange is being copied? I can see two drawbacks here:
>
> 1. When a message is quite heavy we will suffer (although it can be
> workarounded by implementing own Message and overriding copy method).
> 2. Usually, we do not need whole in message (to process in enricher target),
> so it's quite pointless to copy it as a whole and then transform (or select
> part of it) to format which is required.
>
> So far, we've ended with own implementation of Enricher which requires
> additional bean reference of processor which copies exchange (in our case,
> it is used to select interesting data and fill new exchange with appropriate
> data format) in desired way.
>
> Any way, I'm really curious why enricher has been implemented in such a way
> by Camel Team. Any reason? Maybe I miss something important :)!
>
> Robert Budźko
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Enricher-coping-strategy-tp5735290.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: Enricher - coping strategy
Posted by solimo <ro...@budzko.eu>.
Willem.Jiang wrote
> The enricher is just a common EIP implementation, we don't care much about
> the implementation of message.
That's right, so implementation of exchange creation should be injectable.
Willem.Jiang wrote
> I think we can enhance the enrich DSL by providing the plugin parameter to
> prepare the exchange for enricher target, but it real depends on how the
> enricher wants to reuse the message.
>
> Just my 2 cents.
And I can see that you agree :) with me in this matter. Additional DSL param
can be passed - default implementation would invoke old message copy.
How does it work in Camel community? Should I post the idea somewhere or
maybe created jira issue, propose patch?
Robert Budźko
--
View this message in context: http://camel.465427.n5.nabble.com/Enricher-coping-strategy-tp5735290p5735340.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Enricher - coping strategy
Posted by Willem jiang <wi...@gmail.com>.
The enricher is just a common EIP implementation, we don't care much about the implementation of message.
I just went though the code, it could be more easy if you can override the default copy method of the heavy message.
I think we can enhance the enrich DSL by providing the plugin parameter to prepare the exchange for enricher target, but it real depends on how the enricher wants to reuse the message.
Just my 2 cents.
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Tuesday, July 9, 2013 at 1:01 AM, solimo wrote:
> Hello!
>
> After few route implementations which use enricher I've found it quite
> inconvenient to copy whole exchange. The concept is quite brilliant, but
> could anyone explain why, instead of implementing some
> ExchangeCreateStrategt (like AggregationStrategy for aggregation), the whole
> exchange is being copied? I can see two drawbacks here:
>
> 1. When a message is quite heavy we will suffer (although it can be
> workarounded by implementing own Message and overriding copy method).
> 2. Usually, we do not need whole in message (to process in enricher target),
> so it's quite pointless to copy it as a whole and then transform (or select
> part of it) to format which is required.
>
> So far, we've ended with own implementation of Enricher which requires
> additional bean reference of processor which copies exchange (in our case,
> it is used to select interesting data and fill new exchange with appropriate
> data format) in desired way.
>
> Any way, I'm really curious why enricher has been implemented in such a way
> by Camel Team. Any reason? Maybe I miss something important :)!
>
> Robert Budźko
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Enricher-coping-strategy-tp5735290.html
> Sent from the Camel - Users mailing list archive at Nabble.com (http://Nabble.com).