On Sat, Sep 25, 2010 at 10:01 AM, Tarjei Huse <tar...@scanmine.com> wrote: > On 09/24/2010 03:16 PM, Hadrian Zbarcea wrote: >> That's a bit extreme, but yes, that's the idea. More precisely, not when you >> want to change the Exchange, you cannot do that, but when you want the >> message processed by the remaining of the route to be different. >> >> One more thing to keep in mind is that there are 2 kinds of "headers", we >> call them headers and properties. The headers are on the message, and >> normally re not propagated. That means that if you produce and out, that >> will have it's own headers, and if you want headers from the original in to >> be propagated it's up to you copy them into the new message. The properties >> are on the Exchange, and they do get propagated, regardless of a Processor >> producing an out or not. That's for instance the place for security >> credentials, etc. >> >> Not to self: since a picture is worth 1000 words, we need better diagrams on >> the camel site. > Thanks for the clarification. I would love to se a pointer in the getIn > and getOut javadocs to a more detailed discussion about the differences > of the two, for example in the package file. Would that be possible? >
I created a ticket https://issues.apache.org/activemq/browse/CAMEL-3157 And the ticke provides a link to the updated javadoc I did. Feedback welcome. > Regards, > Tarjei > > >> Cheers, >> Hadrian >> >> >> On Sep 24, 2010, at 9:03 AM, Tarjei Huse wrote: >> >>> Hi, >>> On 09/24/2010 10:36 AM, Claus Ibsen wrote: >>>> 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 >>> Maybe the FAQ item could be flashed out with something like: >>> >>> getIn and getOut are not related to the messaging style used. >>> >>> You should only use getOut() when you change the exchange completely and >>> want all traces of the incomming message (headers etc) removed. >>> >>> ? >>> T >>> >>>>>> /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 >>>>> >>>> >>> >>> -- >>> Regards / Med vennlig hilsen >>> Tarjei Huse >>> Mobil: 920 63 413 >>> > > > -- > Regards / Med vennlig hilsen > Tarjei Huse > Mobil: 920 63 413 > > -- 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
