[jira] [Updated] (CAMEL-9880) Header Support for Attachments in Camel 2.18

["Stephan Siano (JIRA)" <ji...@apache.org>]

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

Stephan Siano updated CAMEL-9880:
---------------------------------
    Attachment: 0001-attachment-support-way-3.patch
                0001-attachment-support-way-2.patch
                0001-attachment-support-way-1.patch

> Header Support for Attachments in Camel 2.18
> --------------------------------------------
>
>                 Key: CAMEL-9880
>                 URL: https://issues.apache.org/jira/browse/CAMEL-9880
>             Project: Camel
>          Issue Type: Improvement
>    Affects Versions: 2.18.0
>            Reporter: Stephan Siano
>         Attachments: 0001-attachment-support-way-1.patch, 0001-attachment-support-way-2.patch, 0001-attachment-support-way-3.patch
>
>
> The attachment support in Camel 2.x is essentuially a Map<String,DataHandler>. However real life attachments have headers in addition to the message body (which is essentially represented by the DataHandler) 
> Remark: the DataHandler has support for the Content-Type (which is one of the headers) but has no way to contain the others.
> CAMEL-9868 is about a new overall attachment handling on Camel 3.0.
> This issue is about having attachment headers in Camel 2.x in a way that is compatible to previous version.
> I have attached POCs for three approaches how that could be implemented (neither implementation is complete, it only has header support for attachments in camel-cxf and camel-mail to show the differences between the approaches):
> Option 1: Create an Attachment interface that supports headers and a header map. Furthermore a DefaultAttachment implementation is provided that extends DataHandler and implements Attachment. As these AttachmentImpl objects are also DataHandlers they can be put into the attachment map in the Message implementations (and they are capable of transporting attachments).
> Pros:
> - the Message interface and the DefaultMessage implementation are not changed.
> - The headers are kept with the attachment (so if an attachment is removed the headers also go away)
> Cons:
> - The way this data is transported is not very transparent (ugly instanceof operations and type casts all over the coding (including tests))
> Option 2: Define a specifically named header (of type Map<String, Map<String,String>> that contains the content of all attachment headers. The access to this header is done via new methods of the MessageHelper class.
> Pros: 
> - No change in the Message interface and DefaultMessage implementation.
> - No new interface
> Cons:
> - Access via headers very complex -> MessageHelper method calls are spread all over the code (including tests).
> - Headers can get inconsistent with attachments (if an attachment is removed the corresponding headers are not automatically removed, if a new attachment with the old name is added, the headers from the old attachment will pop up).
> Option 3: Create an Attachment interface (as in Option 1). The DefaultAttachment implementation does not implement DataHandler. Therefore additional methods in the Message interface and DefaultMessage are needed. The map in the DefaultMessage implementation needs to be changed in type, the access methods to the original map grant a modifiable view on the underlying Map<String, Attachment> (so mixed access with the old and the new methods works (the old methods do not grant header access)).
> Pros:
> - Clean way of implementation, no instanceof calls and type casts necessary, no use of MessageHelper all over the code.
> - The headers are kept with the attachments(no inconsistencies)
> Cons:
> - (Compatible) extension of Message interface (implementors that do not extend the DefaultMessage class need to be extended (the RichMessage in camel-scala)).
> - Changes in DefaultMessage may have some risk of introducing new bugs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)