Re: Enricher - coping strategy
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
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 rob...@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: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
Re: Enricher - coping strategy
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
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 rob...@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: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
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
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).
