camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Camel Exchange Patters
Date Sat, 25 Sep 2010 08:09:41 GMT
On Sat, Sep 25, 2010 at 10:01 AM, Tarjei Huse <tarjei@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.ibsen@gmail.com>
>>>>>>
>>>>>>> On Tue, Sep 14, 2010 at 2:16 PM, Bengt Rodehav <bengt@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.ibsen@gmail.com>
>>>>>>>>
>>>>>>>>> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
>>>>>>>>> <christian.mueller@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

Mime
View raw message