On Tue, Sep 14, 2010 at 2:29 PM, Bengt Rodehav <be...@rodehav.com> wrote:
> Yeah I remember reading about the problems with losing message headers
> somewhere on this list...
>
> To be perfectly honest I think that the number of mails on this thread
> indicates the importance of documenting these rules and how things work.
> Claus, you are most definitely the man to do it. I've got your book (haven't
> read the last updates though) and it certainly warrants a place there.
> Perhaps it should also be on the wiki somewhere.
>
We have added information about this in Camel in action,
chapter 3 when we drill down and work the Processor which exposes the
Exchange API.
> /Bengt
>
> 2010/9/14 Claus Ibsen <claus.ib...@gmail.com>
>
>> On Tue, Sep 14, 2010 at 2:16 PM, Bengt Rodehav <be...@rodehav.com> wrote:
>> > I think that was very useful information. I hadn't thought of a Processor
>> as
>> > very low level - it's definitely a level that a lot of us will use. Then
>> I
>> > guess that in some circumstances (like when coding a custom processor)
>> you
>> > need to set the out messsage if the MEP is "out capable" otherwise you
>> just
>> > set the in message. Are there more situations where this is needed?
>> >
>>
>> If the MEP is out capable you can still just change the IN message.
>> If the OUT is null, then Camel will re-use the IN (which you just
>> changed) and thus still route whatever you have changed.
>>
>> You only need to use OUT if you want to create a totally 100% new
>> message which is not related to the IN message at all.
>> And this is only needed in special cases.
>>
>> Otherwise you get the problem with: Why do I lose my message headers etc.
>>
>>
>>
>> > I think that this subject is definitely complicated enough to warrant a
>> good
>> > documentation somewhere. I think it's really important for developers to
>> > understand core concepts instead of just using boilerplate samples
>> (although
>> > they are very useful).
>> >
>> > /Bengt
>> >
>> > 2010/9/14 Claus Ibsen <claus.ib...@gmail.com>
>> >
>> >> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
>> >> <christian.muel...@gmail.com> wrote:
>> >> > Hello Claus!
>> >> >
>> >> > That's not (in my opinion) how it works currently. At present I work
>> on a
>> >> > route which looks like this:
>> >> >
>> >> > errorHandler(
>> >> > defaultErrorHandler()
>> >> > .retryAttemptedLogLevel(LoggingLevel.DEBUG)
>> >> > .retriesExhaustedLogLevel(LoggingLevel.INFO));
>> >> >
>> >> > onException(IllegalArgumentException.class)
>> >> > .handled(true)
>> >> > .maximumRedeliveries(0)
>> >> > .beanRef("myResultProvider", "failureResponse");
>> >> >
>> >> > from("cxf:bean:MyCoolService")
>> >> > .processRef("myValidator") // validates conditional rules
>> >> > .inOut("direct:mySubroute")
>> >> > .beanRef("myResultProvider", "successResponse")
>> >> >
>> >> >
>> >> > If my validator throws a IllegalArgumentException and the result
>> provider
>> >> > writes the response into the in message, the web service will return
>> >> null.
>> >> > But if I write the response into the out message, the web service will
>> >> > return it. So, I changes my bean to the following "pattern":
>> >> >
>> >>
>> >> Well that could CXF Bean component having a bug.
>> >>
>> >> If you decide to use a Processor and work on Exchange then you use the
>> >> low level Camel API and then you have to handle the IN/OUT stuff
>> >> yourself.
>> >>
>> >>
>> >>
>> >>
>> >> > if (exchange.getPattern().isOutCapable()) {
>> >> > exchange.getOut().setBody(response);
>> >> > } else {
>> >> > exchange.getIn().setBody(response);
>> >> > }
>> >> >
>> >> > And that's the same how the
>> >> org.apache.camel.processor.ConvertBodyProcessor
>> >> > works (I know you know this, but for the other guys.. :o) )
>> >> >
>> >> > public class ConvertBodyProcessor implements Processor {
>> >> > ...
>> >> > public void process(Exchange exchange) throws Exception {
>> >> > Message in = exchange.getIn();
>> >> > if (charset != null) {
>> >> > exchange.setProperty(Exchange.CHARSET_NAME, charset);
>> >> > }
>> >> > Object value = in.getMandatoryBody(type);
>> >> >
>> >> > if (exchange.getPattern().isOutCapable()) {
>> >> > Message out = exchange.getOut();
>> >> > out.copyFrom(in);
>> >> > out.setBody(value);
>> >> > } else {
>> >> > in.setBody(value);
>> >> > }
>> >> > }
>> >> > ...
>> >> > }
>> >> >
>> >> > Should our custom processors/beans/.. not work in the same way?
>> >> >
>> >> > Cheers,
>> >> > Christian
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Claus Ibsen
>> >> Apache Camel Committer
>> >>
>> >> Author of Camel in Action: http://www.manning.com/ibsen/
>> >> Open Source Integration: http://fusesource.com
>> >> Blog: http://davsclaus.blogspot.com/
>> >> Twitter: http://twitter.com/davsclaus
>> >>
>> >
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Author of Camel in Action: http://www.manning.com/ibsen/
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
