[DISCUSS] Note on splitter and attachments

[Hadrian Zbarcea <hz...@gmail.com>]

Changed the thread to [discuss]. I propose dropping the attachments in 
the split messages. It's kinda awkward imho to split a message into 
smaller messages but still keep the attachments. I can hardly imagine a 
scenario where the attachments are needed and I think it's more of an 
edge case.

I will create a jira for this.

Hadrian



On 10/31/2011 03:38 PM, Hadrian Zbarcea wrote:
> Hi,
>
> In one of my tests a few days back I discovered a bit of an odd thing.
> Camel is working as expected, but a bit weird.
>
> So I was processing messages with attachments all went well, but
> discovered that we don't have an expression that returns the attachments
> on a messages. There is the @Attachments annotation that uses the
> ExpressionBuilder.attachmentsExpression, but that returns the whole map,
> not just the values(). Since Map.Entry<K, V> is generic you cannot use
> an implicit TypeConverter to V, so I had to write my own expression, not
> too bad.
>
> The interesting part was that using my attachments() expression with a
> splitter, returning a Collection you can iterate through works, but the
> splitter replaces the body of the original message with one item in the
> Collection, leaving the attachments in place. I ended up having a bunch
> of messages (as many as attachments, as expected), yet each Message had
> all of the attachments still present. Not a huge deal, but if the
> attachments are larger in size it may become significant.
>
> I don't think there is a one size fits all solution, and I am not in
> favor of introducing yet another configuration in the splitter to remove
> the attachments.
>
> Thoughts?
> Hadrian

Re: [DISCUSS] Note on splitter and attachments

[Claus Ibsen <cl...@gmail.com>]

On Tue, Nov 1, 2011 at 3:30 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> Changed the thread to [discuss]. I propose dropping the attachments in the
> split messages. It's kinda awkward imho to split a message into smaller
> messages but still keep the attachments. I can hardly imagine a scenario
> where the attachments are needed and I think it's more of an edge case.
>

Yeah it should not copy the attachments. Possible look into adding an
option on the ExchangeHelper.copyXXx methods
which is used by the Splitter, to control if attachments should be
copied or not. Or something like that.


> I will create a jira for this.
>
> Hadrian
>
>
>
> On 10/31/2011 03:38 PM, Hadrian Zbarcea wrote:
>>
>> Hi,
>>
>> In one of my tests a few days back I discovered a bit of an odd thing.
>> Camel is working as expected, but a bit weird.
>>
>> So I was processing messages with attachments all went well, but
>> discovered that we don't have an expression that returns the attachments
>> on a messages. There is the @Attachments annotation that uses the
>> ExpressionBuilder.attachmentsExpression, but that returns the whole map,
>> not just the values(). Since Map.Entry<K, V> is generic you cannot use
>> an implicit TypeConverter to V, so I had to write my own expression, not
>> too bad.
>>
>> The interesting part was that using my attachments() expression with a
>> splitter, returning a Collection you can iterate through works, but the
>> splitter replaces the body of the original message with one item in the
>> Collection, leaving the attachments in place. I ended up having a bunch
>> of messages (as many as attachments, as expected), yet each Message had
>> all of the attachments still present. Not a huge deal, but if the
>> attachments are larger in size it may become significant.
>>
>> I don't think there is a one size fits all solution, and I am not in
>> favor of introducing yet another configuration in the splitter to remove
>> the attachments.
>>
>> Thoughts?
>> Hadrian
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/