[jira] [Resolved] (CAMEL-4603) Messages after a split() should not keep attachments

["Hadrian Zbarcea (Resolved) (JIRA)" <ji...@apache.org>]

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

Hadrian Zbarcea resolved CAMEL-4603.
------------------------------------

       Resolution: Fixed
    Fix Version/s: 2.10.0
    
> Messages after a split() should not keep attachments
> ----------------------------------------------------
>
>                 Key: CAMEL-4603
>                 URL: https://issues.apache.org/jira/browse/CAMEL-4603
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 2.8.2
>            Reporter: Hadrian Zbarcea
>            Assignee: Hadrian Zbarcea
>             Fix For: 2.9.1, 2.10.0
>
>
> Camel does not implement 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.
> In my sandbox I implemented an attachments() expression to use with the splitter, returning a Collection you can iterate through. The splitter replaces the body of the original message with the items in the Collection, leaving the attachments in place.  
> 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. It would be good, I think to add a builder method that returns the values() on the attachments Map, not the entries. The key may be lost, but depending on the attachment, the Content-Type (for mail attachments for instance) may have a copy of the key.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira