camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephan Siano (JIRA)" <>
Subject [jira] [Updated] (CAMEL-9880) Header Support for Attachments in Camel 2.18
Date Mon, 18 Apr 2016 14:39:25 GMT


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

> Header Support for Attachments in Camel 2.18
> --------------------------------------------
>                 Key: CAMEL-9880
>                 URL:
>             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,
> 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

View raw message