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?
>
Camel in Action chapter 1 covers the Camel concepts and also the
Message / Exchange and those details you look for.
The chapter is free.
It's already updated in the javadoc, see for example getOut method
/**
* Returns the outbound message, lazily creating one if one has not already
* been associated with this exchange.
* <p/>
* <br/><b>Important:</b> If you want to change the current
message, then use {...@link #getIn()} instead as it will
* ensure headers etc. is kept and propagated when routing
continues. Bottom line end users should rarely use
* this method.
* <p/>
* <br/>If you want to test whether an OUT message have been set
or not, use the {...@link #hasOut()} method.
*
* @return the response
* @see #getIn()
*/
> 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
