[
https://issues.apache.org/jira/browse/CAMEL-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9880:
-------------------------------
Component/s: camel-core
> 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
> Components: camel-core
> Affects Versions: 2.18.0
> Reporter: Stephan Siano
> Assignee: Stephan Siano
> Fix For: 2.18.0
>
> 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)
