On Fri, Sep 24, 2010 at 10:27 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > 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. >
I also added a couple of FAQs as well, such as https://cwiki.apache.org/confluence/display/CAMEL/Using+getIn+or+getOut+methods+on+Exchange > >> /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 > -- 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
