Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
3.0.0
-
None
-
Unknown
Description
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).