[
https://issues.apache.org/jira/browse/CAMEL-4797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221831#comment-13221831
]
Babak Vahdat commented on CAMEL-4797:
-------------------------------------
O.K now I've got the intention of this ticket but wouldn't we then provide
*too* much of flexibility? IMHO each piece of the Lego has been provided for a
specific role to be taken over in order to build up a nice Lego car and people
should better not start swapping pieces with each other. So if they want to do
CRUD on headers, attachments, etc. then they should better stick to the
corresponding DSL elements provided specifically for that purpose *after*
unmarshal.
Do I overlook something?
> DataFormat - unmarshal should allow to return Message or Exchange to make it
> more flexible
> ------------------------------------------------------------------------------------------
>
> Key: CAMEL-4797
> URL: https://issues.apache.org/jira/browse/CAMEL-4797
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Claus Ibsen
> Fix For: 2.10.0
>
>
> The API of the unmarshal on DataFormat is
> {code}
> Object unmarshal(Exchange exchange, InputStream stream) throws Exception;
> {code}
> The Object returned is by default the message body. But we should allow end
> user to return also a
> - org.apache.camel.Message
> - org.apache.camel.Exchange
> If its a Message then use the message returned.
> If its a Exchange then copy the results from the exchange to the current
> exchange (normally it would be the same instance, so its a noop operation)
> We supports this for the splitter, where people can return a List<Message> in
> the split expression etc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
