On Fri, Jul 10, 2009 at 1:20 PM, James Strachan<james.strac...@gmail.com> wrote:
> 2009/7/10 Claus Ibsen <claus.ib...@gmail.com>:
>> Hi
>>
>> Another update on the IN vs OUT when you send in an Exchange.
>>
>> The ProducerCache that is doing the actual sending when using template
>> or sendTo etc, its basically doing all send X to endpoint.
>>
>> Well I am playing with to let it adhere to the principle Hadrian
>> pointed out. He wanted the IN to be more static.
>> And we cannot get there yet when you do routing as all the processors
>> rely on IN being able to mutate during routing.
>>
>> Anyway my grief is that when you send in an Exchange the result would
>> sometimes be stored on IN and not OUT.
>> What I want it to do always is to store the result in OUT and keep IN
>> as the original input.
>>
>> The code to do this is now a bit more complex than just before
>>
>> // copy the original input
>> Message original = exchange.getIn().copy();
>>
>> producer.process(exchange);
>>
>> // if no OUT then set current IN as result (except for
>> optional out)
>> if (!exchange.hasOut() && exchange.getPattern() !=
>> ExchangePattern.InOptionalOut) {
>> // but only if its not the same as original IN to
>> avoid duplicating it
>> // and to adhere to the fact that there was no OUT
>> result at all
>> if (original.getBody() != null &&
>> !original.getBody().equals(exchange.getIn().getBody())) {
>> exchange.setOut(exchange.getIn());
>> }
>> }
>> // and restore original in
>> exchange.setIn(original);
>>
>> return exchange;
>>
>>
>> What I need to do is to copy the original IN message as it can be
>> mutated during routing.
>
> How about we prevent mutation of the IN message? Create a Message
> facade which throws UnsupportedOperationException if you try to mutate
> it in any way. Then we can pass the same read-only Message around as
> the IN within retry loops or from step to step if no new output is
> created (e.g. in a content based router where you just move a Message
> to the right endpoint without changing it)
>
A good idea but will break a lot of logic in Camel. Most of the Camel
processors work on the IN message and set the result on either IN or
OUT. At best they set it on OUT. But then the IN is always the
original input? Or am I mistaking?
How will this work with the Pipes And Filters EIP if the IN is
immutable and always the original input?
And all the bean binding also grab the IN message when it binds to a POJO.
If people wanted the original IN message it can be stored as an
Exchange. In fact its already there on the Unit Of Work. We could just
expose it better.
Message original = exchange.getUnitOfWork().getOriginalMessage();
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
