Stephan Siano created CAMEL-9868:
------------------------------------
Summary: Rework Attachment Support in Camel Message and related
Interfaces
Key: CAMEL-9868
URL: https://issues.apache.org/jira/browse/CAMEL-9868
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 3.0.0
Reporter: Stephan Siano
The attachment support in the current (2.x) Camel Message interface is not
optimal for two reasons:
1. having attachments in the plain Message interface implies that each
component supports attachments (which is not the case as only few selected
components like camel-mail and camel-cxf support attachments)
2. the current interface is essentuially a Map<String,DataHandler>. However
real live 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.
An (incompatible) better aproach (for Camel 3.0) could look as described below:
1. the attachment support is removed from the Message interface and from the
default Message implementation.
2. A new Interface (e.g. AttachmentCapable) is provided in the API for
attachment support (plus another Interface representing the Attachment itself
that contains the DataHandler and the headers)
3. There should probably be a default message implementation supporting
attachments (like DefaultAttachmentMessageImple) which extends
DefaultMessageImpl and implements AttachmentCapable
4. Components that support attachments like camel-mail (or camel-cxf) can
either use that default implementation (as camel-cxf does) or provide their own
message implementation that implements AttachmentCapable. This message needs to
be instantiated by consumer endpoints (and attachment capable producer
endpoints that provide an InOut communication pattern (e.g. camel-cxf for
request reply web services that return an attachment).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
