You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Christian Müller <ch...@gmail.com> on 2010/09/11 16:03:37 UTC
Camel Exchange Patters
Hello list!
I read Claus, Jonathan and Hadrians book Camel in Action and I studied the
Camel site [1]. I also hat a short conversation with Ade from Progress about
the exchange pattern, but still I have the feeling I doesn't understand all
aspects. May be you can help me to understand it correct. Here are my
questions:
- In the book and the Camel site only the exchange patterns InOut and InOnly
are mentioned but org.apache.camel.ExchangePattern defines the following
exchange patterns: InOnly, RobustInOnly, InOut, InOptionalOut, OutOnly,
RobustOutOnly, OutIn, OutOptionalIn. Should we only use InOut and InOnly?
- If I understood Ade correct, after each processing on a
component/processor the message goes throught the pipieline before it
receives the next component/processor. In the case of an InOut exchange, the
pipeline will copy the out message body, headers and attachments into the in
message. So that in the next component/processor can access these data from
the in message again. If I use the InOnly exchange pattern, the
component/processor will write the response into the in message and the
pipeline has nothing to copy. From the end user perspective it looks like it
doesn't matter, whether to use the InOnly or InOut exchange pattern.
- The only one component I know which handle InOnly and InOut "really"
defferently is the jms-component. It will only send a reply message if the
exchange pattern InOut is used.
- If I use a InOnly exchange for the following routes, I takes also more
than 5 seconds until my templeate.send() method returns. I would expect that
the call returns after the exchange was placed into the next sub route
(after a few milliseconds). My key point here is not to improve the
performance. Only to understand the exchange pattern correct, how the work
and how they are used in the right way...
from("direct:start")
.to("direct:sub");
from("direct:sub")
.process(*new* Processor() {
@Override
*public* *void* process(Exchange exchange) *
throws* Exception {
Thread.*sleep*(5000);
}
})
.to("mock:result");
- Do you have recommendations when to use InOnly and InOut?
- If we write our own processor which modifies the in message, should they
write the modified body into the out message, if the exchnage is out capable
(and also copy all header and attachments we need for further processing)?
Or should we always modify the in message because it requires less action?
- The same question for our own type converters. I know the type converter
is implemented in this way, that it will return the new (converted) object.
But our type converters also have to modify the message header. Should they
also check whether the exchange is out capable and than modify the out (if
out capable) or in (if not out capable) message? Is this the way camel
handels the converted object from the type converter?
[1] http://camel.apache.org/exchange-pattern.html
Thanks in advance for your help and taking time for my questions,
Christian
Re: Camel Exchange Patters
Posted by Bengt Rodehav <be...@rodehav.com>.
I think you pose excellent questions. Being quite a newbie on Camel (but
already hooked), I've looked at a lot of examples as a recipe to solve my
tasks. However, I really lack a more thorough description of how the
Exchange (and the in and out messages) are handled when walking through a
route. Is the In message passed to the next processor or is it the out
message and when should I change what?
I would really recommend to add a chapter (or a few paragraphs) to Camel in
Action explaining how the messages change when the pass from processor to
processor in a route. The description needs to address the supported MEP's
and provide guidelines for developing processors and type converters.
It would be nice to gain a little more theoretical understanding in this
subject instead of only practical solutions to problems at hand. Maybe this
is documented somewhere already? A link would then be much appreciated.
/Bengt
2010/9/11 Christian Müller <ch...@gmail.com>
> Hello list!
>
> I read Claus, Jonathan and Hadrians book Camel in Action and I studied the
> Camel site [1]. I also hat a short conversation with Ade from Progress
> about
> the exchange pattern, but still I have the feeling I doesn't understand all
> aspects. May be you can help me to understand it correct. Here are my
> questions:
> - In the book and the Camel site only the exchange patterns InOut and
> InOnly
> are mentioned but org.apache.camel.ExchangePattern defines the following
> exchange patterns: InOnly, RobustInOnly, InOut, InOptionalOut, OutOnly,
> RobustOutOnly, OutIn, OutOptionalIn. Should we only use InOut and InOnly?
> - If I understood Ade correct, after each processing on a
> component/processor the message goes throught the pipieline before it
> receives the next component/processor. In the case of an InOut exchange,
> the
> pipeline will copy the out message body, headers and attachments into the
> in
> message. So that in the next component/processor can access these data from
> the in message again. If I use the InOnly exchange pattern, the
> component/processor will write the response into the in message and the
> pipeline has nothing to copy. From the end user perspective it looks like
> it
> doesn't matter, whether to use the InOnly or InOut exchange pattern.
> - The only one component I know which handle InOnly and InOut "really"
> defferently is the jms-component. It will only send a reply message if the
> exchange pattern InOut is used.
> - If I use a InOnly exchange for the following routes, I takes also more
> than 5 seconds until my templeate.send() method returns. I would expect
> that
> the call returns after the exchange was placed into the next sub route
> (after a few milliseconds). My key point here is not to improve the
> performance. Only to understand the exchange pattern correct, how the work
> and how they are used in the right way...
>
> from("direct:start")
>
> .to("direct:sub");
>
>
>
> from("direct:sub")
>
> .process(*new* Processor() {
>
> @Override
>
> *public* *void* process(Exchange exchange) *
> throws* Exception {
>
> Thread.*sleep*(5000);
>
> }
>
> })
> .to("mock:result");
>
>
> - Do you have recommendations when to use InOnly and InOut?
> - If we write our own processor which modifies the in message, should they
> write the modified body into the out message, if the exchnage is out
> capable
> (and also copy all header and attachments we need for further processing)?
> Or should we always modify the in message because it requires less action?
> - The same question for our own type converters. I know the type converter
> is implemented in this way, that it will return the new (converted) object.
> But our type converters also have to modify the message header. Should they
> also check whether the exchange is out capable and than modify the out (if
> out capable) or in (if not out capable) message? Is this the way camel
> handels the converted object from the type converter?
>
> [1] http://camel.apache.org/exchange-pattern.html
>
> Thanks in advance for your help and taking time for my questions,
> Christian
>
Re: Camel Exchange Patters
Posted by Bengt Rodehav <be...@rodehav.com>.
OK, thanks.
/Bengt
2010/9/14 Claus Ibsen <cl...@gmail.com>
> On Tue, Sep 14, 2010 at 9:02 AM, Bengt Rodehav <be...@rodehav.com> wrote:
> > Thanks Willem and Claus,
> >
> > I guess we should only bother with in messages then and forget about the
> out
> > message if we want a simple rule.
> >
> > I thought that the rationale for having both in- and out messages was
> that
> > the original in message would be kept unaltered while the out message
> would
> > gradually be transformed when passing through the pipeline. I assume now
> > that you only have access to the message as it was transformed by the
> > previous processor in the chain. The original message is not available -
> or
> > is it?
> >
>
> No its not avail, unless you fetch if from the UnitOfWork. There is a
> feature on the error handler to use the original message when moving a
> message to the dead letter channel. Which leverages the UnitOfWork to
> fetch it.
>
> In Camel 3.0 we have plans to rework how this works internally
> reducing the copying done by the pipeline and make it easier to access
> the original message and/or even previous states.
>
>
>
> > /Bengt
> >
> > 2010/9/14 Willem Jiang <wi...@gmail.com>
> >
> >> On 9/11/10 10:03 PM, Christian Müller wrote:
> >>
> >>> Hello list!
> >>>
> >>> I read Claus, Jonathan and Hadrians book Camel in Action and I studied
> the
> >>> Camel site [1]. I also hat a short conversation with Ade from Progress
> >>> about
> >>> the exchange pattern, but still I have the feeling I doesn't understand
> >>> all
> >>> aspects. May be you can help me to understand it correct. Here are my
> >>> questions:
> >>> - In the book and the Camel site only the exchange patterns InOut and
> >>> InOnly
> >>> are mentioned but org.apache.camel.ExchangePattern defines the
> following
> >>> exchange patterns: InOnly, RobustInOnly, InOut, InOptionalOut, OutOnly,
> >>> RobustOutOnly, OutIn, OutOptionalIn. Should we only use InOut and
> InOnly?
> >>> - If I understood Ade correct, after each processing on a
> >>> component/processor the message goes throught the pipieline before it
> >>> receives the next component/processor. In the case of an InOut
> exchange,
> >>> the
> >>> pipeline will copy the out message body, headers and attachments into
> the
> >>> in
> >>> message. So that in the next component/processor can access these data
> >>> from
> >>> the in message again. If I use the InOnly exchange pattern, the
> >>> component/processor will write the response into the in message and the
> >>> pipeline has nothing to copy.
> >>>
> >> The pipeline always uses a new copy of exchange which will create a new
> >> inMessage copy as you described, if you are using InOnly exchange
> pattern,
> >> pipeline still create a new Exchange and copy the in message from the
> first
> >> exchange.
> >>
> >> The InOnly and InOut exchange patterns always take effect in the
> component
> >> side, current DefaultExchange will not check the exchange pattern and
> will
> >> create a new out message which copy from the exchange in message when
> you
> >> call the Exchange.getOutMessage().
> >>
> >>
> >>
> >> > From the end user perspective it looks like it
> >>
> >>> doesn't matter, whether to use the InOnly or InOut exchange pattern.
> >>> - The only one component I know which handle InOnly and InOut "really"
> >>> defferently is the jms-component. It will only send a reply message if
> the
> >>> exchange pattern InOut is used.
> >>> - If I use a InOnly exchange for the following routes, I takes also
> more
> >>> than 5 seconds until my templeate.send() method returns. I would expect
> >>> that
> >>> the call returns after the exchange was placed into the next sub route
> >>> (after a few milliseconds). My key point here is not to improve the
> >>> performance. Only to understand the exchange pattern correct, how the
> work
> >>> and how they are used in the right way...
> >>>
> >>> from("direct:start")
> >>>
> >>> .to("direct:sub");
> >>>
> >>>
> >>>
> >>> from("direct:sub")
> >>>
> >>> .process(*new* Processor() {
> >>>
> >>> @Override
> >>>
> >>> *public* *void* process(Exchange exchange)
> *
> >>> throws* Exception {
> >>>
> >>> Thread.*sleep*(5000);
> >>>
> >>> }
> >>>
> >>> })
> >>> .to("mock:result");
> >>>
> >>>
> >>> - Do you have recommendations when to use InOnly and InOut?
> >>>
> >> There are some description about InOnly and InOut message echange
> pattern
> >> in the Camel in Action chapter 10, as the sync and async invocation. You
> may
> >> take a look.
> >>
> >>
> >> - If we write our own processor which modifies the in message, should
> they
> >>> write the modified body into the out message, if the exchnage is out
> >>> capable
> >>> (and also copy all header and attachments we need for further
> processing)?
> >>> Or should we always modify the in message because it requires less
> action?
> >>>
> >> You can modify the in message directly, or do some change on the out
> >> message and the pipeline will pick up the right modified message for
> you.
> >> The DefaultExchange will create a new out message based on the in
> message if
> >> you call the Exchange.getOutMessage(), so you don't need to copy the all
> the
> >> headers and attachments yourself.
> >>
> >>
> >> - The same question for our own type converters. I know the type
> converter
> >>> is implemented in this way, that it will return the new (converted)
> >>> object.
> >>> But our type converters also have to modify the message header. Should
> >>> they
> >>> also check whether the exchange is out capable and than modify the out
> (if
> >>> out capable) or in (if not out capable) message? Is this the way camel
> >>> handels the converted object from the type converter?
> >>>
> >>
> >> I think you just need to make the change on the in message, if you want
> to
> >> avoid the addition copying (camel will copy the out message from the in
> >> message if you make the change on the out message of the exchange).
> >>
> >>
> >>> [1] http://camel.apache.org/exchange-pattern.html
> >>>
> >>> Thanks in advance for your help and taking time for my questions,
> >>> Christian
> >>>
> >>>
> >> Willem
> >>
> >
>
>
>
> --
> 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
>
Re: Camel Exchange Patters
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Sep 14, 2010 at 9:02 AM, Bengt Rodehav <be...@rodehav.com> wrote:
> Thanks Willem and Claus,
>
> I guess we should only bother with in messages then and forget about the out
> message if we want a simple rule.
>
> I thought that the rationale for having both in- and out messages was that
> the original in message would be kept unaltered while the out message would
> gradually be transformed when passing through the pipeline. I assume now
> that you only have access to the message as it was transformed by the
> previous processor in the chain. The original message is not available - or
> is it?
>
No its not avail, unless you fetch if from the UnitOfWork. There is a
feature on the error handler to use the original message when moving a
message to the dead letter channel. Which leverages the UnitOfWork to
fetch it.
In Camel 3.0 we have plans to rework how this works internally
reducing the copying done by the pipeline and make it easier to access
the original message and/or even previous states.
> /Bengt
>
> 2010/9/14 Willem Jiang <wi...@gmail.com>
>
>> On 9/11/10 10:03 PM, Christian Müller wrote:
>>
>>> Hello list!
>>>
>>> I read Claus, Jonathan and Hadrians book Camel in Action and I studied the
>>> Camel site [1]. I also hat a short conversation with Ade from Progress
>>> about
>>> the exchange pattern, but still I have the feeling I doesn't understand
>>> all
>>> aspects. May be you can help me to understand it correct. Here are my
>>> questions:
>>> - In the book and the Camel site only the exchange patterns InOut and
>>> InOnly
>>> are mentioned but org.apache.camel.ExchangePattern defines the following
>>> exchange patterns: InOnly, RobustInOnly, InOut, InOptionalOut, OutOnly,
>>> RobustOutOnly, OutIn, OutOptionalIn. Should we only use InOut and InOnly?
>>> - If I understood Ade correct, after each processing on a
>>> component/processor the message goes throught the pipieline before it
>>> receives the next component/processor. In the case of an InOut exchange,
>>> the
>>> pipeline will copy the out message body, headers and attachments into the
>>> in
>>> message. So that in the next component/processor can access these data
>>> from
>>> the in message again. If I use the InOnly exchange pattern, the
>>> component/processor will write the response into the in message and the
>>> pipeline has nothing to copy.
>>>
>> The pipeline always uses a new copy of exchange which will create a new
>> inMessage copy as you described, if you are using InOnly exchange pattern,
>> pipeline still create a new Exchange and copy the in message from the first
>> exchange.
>>
>> The InOnly and InOut exchange patterns always take effect in the component
>> side, current DefaultExchange will not check the exchange pattern and will
>> create a new out message which copy from the exchange in message when you
>> call the Exchange.getOutMessage().
>>
>>
>>
>> > From the end user perspective it looks like it
>>
>>> doesn't matter, whether to use the InOnly or InOut exchange pattern.
>>> - The only one component I know which handle InOnly and InOut "really"
>>> defferently is the jms-component. It will only send a reply message if the
>>> exchange pattern InOut is used.
>>> - If I use a InOnly exchange for the following routes, I takes also more
>>> than 5 seconds until my templeate.send() method returns. I would expect
>>> that
>>> the call returns after the exchange was placed into the next sub route
>>> (after a few milliseconds). My key point here is not to improve the
>>> performance. Only to understand the exchange pattern correct, how the work
>>> and how they are used in the right way...
>>>
>>> from("direct:start")
>>>
>>> .to("direct:sub");
>>>
>>>
>>>
>>> from("direct:sub")
>>>
>>> .process(*new* Processor() {
>>>
>>> @Override
>>>
>>> *public* *void* process(Exchange exchange) *
>>> throws* Exception {
>>>
>>> Thread.*sleep*(5000);
>>>
>>> }
>>>
>>> })
>>> .to("mock:result");
>>>
>>>
>>> - Do you have recommendations when to use InOnly and InOut?
>>>
>> There are some description about InOnly and InOut message echange pattern
>> in the Camel in Action chapter 10, as the sync and async invocation. You may
>> take a look.
>>
>>
>> - If we write our own processor which modifies the in message, should they
>>> write the modified body into the out message, if the exchnage is out
>>> capable
>>> (and also copy all header and attachments we need for further processing)?
>>> Or should we always modify the in message because it requires less action?
>>>
>> You can modify the in message directly, or do some change on the out
>> message and the pipeline will pick up the right modified message for you.
>> The DefaultExchange will create a new out message based on the in message if
>> you call the Exchange.getOutMessage(), so you don't need to copy the all the
>> headers and attachments yourself.
>>
>>
>> - The same question for our own type converters. I know the type converter
>>> is implemented in this way, that it will return the new (converted)
>>> object.
>>> But our type converters also have to modify the message header. Should
>>> they
>>> also check whether the exchange is out capable and than modify the out (if
>>> out capable) or in (if not out capable) message? Is this the way camel
>>> handels the converted object from the type converter?
>>>
>>
>> I think you just need to make the change on the in message, if you want to
>> avoid the addition copying (camel will copy the out message from the in
>> message if you make the change on the out message of the exchange).
>>
>>
>>> [1] http://camel.apache.org/exchange-pattern.html
>>>
>>> Thanks in advance for your help and taking time for my questions,
>>> Christian
>>>
>>>
>> Willem
>>
>
--
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
Re: Camel Exchange Patters
Posted by Bengt Rodehav <be...@rodehav.com>.
Thanks Willem and Claus,
I guess we should only bother with in messages then and forget about the out
message if we want a simple rule.
I thought that the rationale for having both in- and out messages was that
the original in message would be kept unaltered while the out message would
gradually be transformed when passing through the pipeline. I assume now
that you only have access to the message as it was transformed by the
previous processor in the chain. The original message is not available - or
is it?
/Bengt
2010/9/14 Willem Jiang <wi...@gmail.com>
> On 9/11/10 10:03 PM, Christian Müller wrote:
>
>> Hello list!
>>
>> I read Claus, Jonathan and Hadrians book Camel in Action and I studied the
>> Camel site [1]. I also hat a short conversation with Ade from Progress
>> about
>> the exchange pattern, but still I have the feeling I doesn't understand
>> all
>> aspects. May be you can help me to understand it correct. Here are my
>> questions:
>> - In the book and the Camel site only the exchange patterns InOut and
>> InOnly
>> are mentioned but org.apache.camel.ExchangePattern defines the following
>> exchange patterns: InOnly, RobustInOnly, InOut, InOptionalOut, OutOnly,
>> RobustOutOnly, OutIn, OutOptionalIn. Should we only use InOut and InOnly?
>> - If I understood Ade correct, after each processing on a
>> component/processor the message goes throught the pipieline before it
>> receives the next component/processor. In the case of an InOut exchange,
>> the
>> pipeline will copy the out message body, headers and attachments into the
>> in
>> message. So that in the next component/processor can access these data
>> from
>> the in message again. If I use the InOnly exchange pattern, the
>> component/processor will write the response into the in message and the
>> pipeline has nothing to copy.
>>
> The pipeline always uses a new copy of exchange which will create a new
> inMessage copy as you described, if you are using InOnly exchange pattern,
> pipeline still create a new Exchange and copy the in message from the first
> exchange.
>
> The InOnly and InOut exchange patterns always take effect in the component
> side, current DefaultExchange will not check the exchange pattern and will
> create a new out message which copy from the exchange in message when you
> call the Exchange.getOutMessage().
>
>
>
> > From the end user perspective it looks like it
>
>> doesn't matter, whether to use the InOnly or InOut exchange pattern.
>> - The only one component I know which handle InOnly and InOut "really"
>> defferently is the jms-component. It will only send a reply message if the
>> exchange pattern InOut is used.
>> - If I use a InOnly exchange for the following routes, I takes also more
>> than 5 seconds until my templeate.send() method returns. I would expect
>> that
>> the call returns after the exchange was placed into the next sub route
>> (after a few milliseconds). My key point here is not to improve the
>> performance. Only to understand the exchange pattern correct, how the work
>> and how they are used in the right way...
>>
>> from("direct:start")
>>
>> .to("direct:sub");
>>
>>
>>
>> from("direct:sub")
>>
>> .process(*new* Processor() {
>>
>> @Override
>>
>> *public* *void* process(Exchange exchange) *
>> throws* Exception {
>>
>> Thread.*sleep*(5000);
>>
>> }
>>
>> })
>> .to("mock:result");
>>
>>
>> - Do you have recommendations when to use InOnly and InOut?
>>
> There are some description about InOnly and InOut message echange pattern
> in the Camel in Action chapter 10, as the sync and async invocation. You may
> take a look.
>
>
> - If we write our own processor which modifies the in message, should they
>> write the modified body into the out message, if the exchnage is out
>> capable
>> (and also copy all header and attachments we need for further processing)?
>> Or should we always modify the in message because it requires less action?
>>
> You can modify the in message directly, or do some change on the out
> message and the pipeline will pick up the right modified message for you.
> The DefaultExchange will create a new out message based on the in message if
> you call the Exchange.getOutMessage(), so you don't need to copy the all the
> headers and attachments yourself.
>
>
> - The same question for our own type converters. I know the type converter
>> is implemented in this way, that it will return the new (converted)
>> object.
>> But our type converters also have to modify the message header. Should
>> they
>> also check whether the exchange is out capable and than modify the out (if
>> out capable) or in (if not out capable) message? Is this the way camel
>> handels the converted object from the type converter?
>>
>
> I think you just need to make the change on the in message, if you want to
> avoid the addition copying (camel will copy the out message from the in
> message if you make the change on the out message of the exchange).
>
>
>> [1] http://camel.apache.org/exchange-pattern.html
>>
>> Thanks in advance for your help and taking time for my questions,
>> Christian
>>
>>
> Willem
>
Re: Camel Exchange Patters
Posted by Willem Jiang <wi...@gmail.com>.
On 9/11/10 10:03 PM, Christian Müller wrote:
> Hello list!
>
> I read Claus, Jonathan and Hadrians book Camel in Action and I studied the
> Camel site [1]. I also hat a short conversation with Ade from Progress about
> the exchange pattern, but still I have the feeling I doesn't understand all
> aspects. May be you can help me to understand it correct. Here are my
> questions:
> - In the book and the Camel site only the exchange patterns InOut and InOnly
> are mentioned but org.apache.camel.ExchangePattern defines the following
> exchange patterns: InOnly, RobustInOnly, InOut, InOptionalOut, OutOnly,
> RobustOutOnly, OutIn, OutOptionalIn. Should we only use InOut and InOnly?
> - If I understood Ade correct, after each processing on a
> component/processor the message goes throught the pipieline before it
> receives the next component/processor. In the case of an InOut exchange, the
> pipeline will copy the out message body, headers and attachments into the in
> message. So that in the next component/processor can access these data from
> the in message again. If I use the InOnly exchange pattern, the
> component/processor will write the response into the in message and the
> pipeline has nothing to copy.
The pipeline always uses a new copy of exchange which will create a new
inMessage copy as you described, if you are using InOnly exchange
pattern, pipeline still create a new Exchange and copy the in message
from the first exchange.
The InOnly and InOut exchange patterns always take effect in the
component side, current DefaultExchange will not check the exchange
pattern and will create a new out message which copy from the exchange
in message when you call the Exchange.getOutMessage().
> From the end user perspective it looks like it
> doesn't matter, whether to use the InOnly or InOut exchange pattern.
> - The only one component I know which handle InOnly and InOut "really"
> defferently is the jms-component. It will only send a reply message if the
> exchange pattern InOut is used.
> - If I use a InOnly exchange for the following routes, I takes also more
> than 5 seconds until my templeate.send() method returns. I would expect that
> the call returns after the exchange was placed into the next sub route
> (after a few milliseconds). My key point here is not to improve the
> performance. Only to understand the exchange pattern correct, how the work
> and how they are used in the right way...
>
> from("direct:start")
>
> .to("direct:sub");
>
>
>
> from("direct:sub")
>
> .process(*new* Processor() {
>
> @Override
>
> *public* *void* process(Exchange exchange) *
> throws* Exception {
>
> Thread.*sleep*(5000);
>
> }
>
> })
> .to("mock:result");
>
>
> - Do you have recommendations when to use InOnly and InOut?
There are some description about InOnly and InOut message echange
pattern in the Camel in Action chapter 10, as the sync and async
invocation. You may take a look.
> - If we write our own processor which modifies the in message, should they
> write the modified body into the out message, if the exchnage is out capable
> (and also copy all header and attachments we need for further processing)?
> Or should we always modify the in message because it requires less action?
You can modify the in message directly, or do some change on the out
message and the pipeline will pick up the right modified message for
you. The DefaultExchange will create a new out message based on the in
message if you call the Exchange.getOutMessage(), so you don't need to
copy the all the headers and attachments yourself.
> - The same question for our own type converters. I know the type converter
> is implemented in this way, that it will return the new (converted) object.
> But our type converters also have to modify the message header. Should they
> also check whether the exchange is out capable and than modify the out (if
> out capable) or in (if not out capable) message? Is this the way camel
> handels the converted object from the type converter?
I think you just need to make the change on the in message, if you want
to avoid the addition copying (camel will copy the out message from the
in message if you make the change on the out message of the exchange).
>
> [1] http://camel.apache.org/exchange-pattern.html
>
> Thanks in advance for your help and taking time for my questions,
> Christian
>
Willem
Re: can't tranform Body to DOM
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Sep 24, 2010 at 9:10 PM, Donald Whytock <dw...@gmail.com> wrote:
> Would
>
> org.w3c.dom.Document doc = ex.getIn(org.w3c.dom.Document.class);
>
> work any better?
>
It's the same. By passing in the class type you tell Camel to convert
the message body to that class type (if needed to do so).
> Don
>
> On Fri, Sep 24, 2010 at 9:33 AM, <pa...@orange-ftgroup.com> wrote:
>>
>>
>>> -----Message d'origine-----
>>> De : Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>> Envoyé : vendredi 24 septembre 2010 15:23
>>> À : users@camel.apache.org
>>> Objet : Re: can't tranform Body to DOM
>>>
>>> On Fri, Sep 24, 2010 at 3:17 PM, <pa...@orange-ftgroup.com>
>>> wrote:
>>> > I just noticed that my BodyType is set to byte[].
>>> > Maybe it explains why the conversion to Dom produces a null?
>>>
>>> What version of Camel are you using?
>>>
>>
>> I'm using version 2.2.0.fuse-02-0 (Fuse 4.2)
>>
>> I'm a bit concerned about String <-> DOM conversion along Camel routes.
>> Most of the time I need parsed XML (because I need XPath and XSLT) but this XML gets enriched by a web service that returns XML as a plain String.
>> I feel I'm not controlling when and where the message Body gets converted (this is my first project with Camel).
>>
>> Currently I'm more in a feasibility/prototyping stage but I'm expecting some refactoring in the near future, when I know how to use Camel properly ;-) to make sure performances are not too degradated by unnecessary type conversions.
>>
>>
>> *********************************
>> This message and any attachments (the "message") are confidential and intended solely for the addressees.
>> Any unauthorised use or dissemination is prohibited.
>> Messages are susceptible to alteration.
>> France Telecom Group shall not be liable for the message if altered, changed or falsified.
>> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
>> ********************************
>>
>>
>
--
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
Re: can't tranform Body to DOM
Posted by Donald Whytock <dw...@gmail.com>.
Would
org.w3c.dom.Document doc = ex.getIn(org.w3c.dom.Document.class);
work any better?
Don
On Fri, Sep 24, 2010 at 9:33 AM, <pa...@orange-ftgroup.com> wrote:
>
>
>> -----Message d'origine-----
>> De : Claus Ibsen [mailto:claus.ibsen@gmail.com]
>> Envoyé : vendredi 24 septembre 2010 15:23
>> À : users@camel.apache.org
>> Objet : Re: can't tranform Body to DOM
>>
>> On Fri, Sep 24, 2010 at 3:17 PM, <pa...@orange-ftgroup.com>
>> wrote:
>> > I just noticed that my BodyType is set to byte[].
>> > Maybe it explains why the conversion to Dom produces a null?
>>
>> What version of Camel are you using?
>>
>
> I'm using version 2.2.0.fuse-02-0 (Fuse 4.2)
>
> I'm a bit concerned about String <-> DOM conversion along Camel routes.
> Most of the time I need parsed XML (because I need XPath and XSLT) but this XML gets enriched by a web service that returns XML as a plain String.
> I feel I'm not controlling when and where the message Body gets converted (this is my first project with Camel).
>
> Currently I'm more in a feasibility/prototyping stage but I'm expecting some refactoring in the near future, when I know how to use Camel properly ;-) to make sure performances are not too degradated by unnecessary type conversions.
>
>
> *********************************
> This message and any attachments (the "message") are confidential and intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration.
> France Telecom Group shall not be liable for the message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
> ********************************
>
>
Re: can't tranform Body to DOM
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Sep 24, 2010 at 3:33 PM, <pa...@orange-ftgroup.com> wrote:
>
>
>> -----Message d'origine-----
>> De : Claus Ibsen [mailto:claus.ibsen@gmail.com]
>> Envoyé : vendredi 24 septembre 2010 15:23
>> À : users@camel.apache.org
>> Objet : Re: can't tranform Body to DOM
>>
>> On Fri, Sep 24, 2010 at 3:17 PM, <pa...@orange-ftgroup.com>
>> wrote:
>> > I just noticed that my BodyType is set to byte[].
>> > Maybe it explains why the conversion to Dom produces a null?
>>
>> What version of Camel are you using?
>>
>
> I'm using version 2.2.0.fuse-02-0 (Fuse 4.2)
>
> I'm a bit concerned about String <-> DOM conversion along Camel routes.
> Most of the time I need parsed XML (because I need XPath and XSLT) but this XML gets enriched by a web service that returns XML as a plain String.
> I feel I'm not controlling when and where the message Body gets converted (this is my first project with Camel).
>
Well Camel only converts when really needed, or if you ask it to do
so, such as from the Processor where you asked it to convert to a DOM.
The XPath expression/predicate in Camel can work with the input
message as source types, eg InputSource (I think the XML class name
is). That means
it can work on the message in the optimal way it sees fit.
> Currently I'm more in a feasibility/prototyping stage but I'm expecting some refactoring in the near future, when I know how to use Camel properly ;-) to make sure performances are not too degradated by unnecessary type conversions.
>
Yeah type convertions of big xml payloads can cause performance. So mind here.
>
> *********************************
> This message and any attachments (the "message") are confidential and intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration.
> France Telecom Group shall not be liable for the message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
> ********************************
>
>
--
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
RE: can't tranform Body to DOM
Posted by pa...@orange-ftgroup.com.
> -----Message d'origine-----
> De : Claus Ibsen [mailto:claus.ibsen@gmail.com]
> Envoyé : vendredi 24 septembre 2010 15:23
> À : users@camel.apache.org
> Objet : Re: can't tranform Body to DOM
>
> On Fri, Sep 24, 2010 at 3:17 PM, <pa...@orange-ftgroup.com>
> wrote:
> > I just noticed that my BodyType is set to byte[].
> > Maybe it explains why the conversion to Dom produces a null?
>
> What version of Camel are you using?
>
I'm using version 2.2.0.fuse-02-0 (Fuse 4.2)
I'm a bit concerned about String <-> DOM conversion along Camel routes.
Most of the time I need parsed XML (because I need XPath and XSLT) but this XML gets enriched by a web service that returns XML as a plain String.
I feel I'm not controlling when and where the message Body gets converted (this is my first project with Camel).
Currently I'm more in a feasibility/prototyping stage but I'm expecting some refactoring in the near future, when I know how to use Camel properly ;-) to make sure performances are not too degradated by unnecessary type conversions.
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************
Re: can't tranform Body to DOM
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Sep 24, 2010 at 3:17 PM, <pa...@orange-ftgroup.com> wrote:
> I just noticed that my BodyType is set to byte[].
> Maybe it explains why the conversion to Dom produces a null?
What version of Camel are you using?
I would assume we had a byte[] -> Dom converter out of the box. But
maybe I am mistaking.
And we recently added some more XML related converters in 2.5.
> My messages are XML files dropped in a scanned folder and then picked-up by a route that forwards them into a JMS Topic where they are picked-up by my main route.
>
>> -----Message d'origine-----
>> De : Claus Ibsen [mailto:claus.ibsen@gmail.com]
>> Envoyé : vendredi 24 septembre 2010 14:55
>> À : users@camel.apache.org
>> Objet : Re: can't tranform Body to DOM
>>
>> On Fri, Sep 24, 2010 at 2:48 PM, <pa...@orange-ftgroup.com>
>> wrote:
>> > Hi,
>> > I receive JMS messages which are actually XML documents.
>> > In a processor I'm trying to get them as a DOM document since I need
>> to process them in a certain way.
>> > I'm doing this:
>> > org.w3c.dom.Document doc =
>> ex.getIn().getBody(org.w3c.dom.Document.class);
>> >
>> > And it does not seem to work (doc is always null). I don't get any
>> error message.
>> > I have xpath() statements in my route, which are being correctly
>> evaluated.
>> > I also have xslt transform endpoints which are working as expected.
>> > But here I need to replace an attribute value and I'd like to do
>> without xslt.
>> >
>>
>> use getMandatoryBody if you want Camel to barf if it could not convert
>> it.
>>
>>
>>
>> > Patrice
>> >
>> >
>> > *********************************
>> > This message and any attachments (the "message") are confidential and
>> intended solely for the addressees.
>> > Any unauthorised use or dissemination is prohibited.
>> > Messages are susceptible to alteration.
>> > France Telecom Group shall not be liable for the message if altered,
>> changed or falsified.
>> > If you are not the intended addressee of this message, please cancel
>> it immediately and inform the sender.
>> > ********************************
>> >
>> >
>>
>>
>>
>> --
>> 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
>
> *********************************
> This message and any attachments (the "message") are confidential and intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration.
> France Telecom Group shall not be liable for the message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
> ********************************
>
>
--
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
RE: can't tranform Body to DOM
Posted by pa...@orange-ftgroup.com.
I just noticed that my BodyType is set to byte[].
Maybe it explains why the conversion to Dom produces a null?
My messages are XML files dropped in a scanned folder and then picked-up by a route that forwards them into a JMS Topic where they are picked-up by my main route.
> -----Message d'origine-----
> De : Claus Ibsen [mailto:claus.ibsen@gmail.com]
> Envoyé : vendredi 24 septembre 2010 14:55
> À : users@camel.apache.org
> Objet : Re: can't tranform Body to DOM
>
> On Fri, Sep 24, 2010 at 2:48 PM, <pa...@orange-ftgroup.com>
> wrote:
> > Hi,
> > I receive JMS messages which are actually XML documents.
> > In a processor I'm trying to get them as a DOM document since I need
> to process them in a certain way.
> > I'm doing this:
> > org.w3c.dom.Document doc =
> ex.getIn().getBody(org.w3c.dom.Document.class);
> >
> > And it does not seem to work (doc is always null). I don't get any
> error message.
> > I have xpath() statements in my route, which are being correctly
> evaluated.
> > I also have xslt transform endpoints which are working as expected.
> > But here I need to replace an attribute value and I'd like to do
> without xslt.
> >
>
> use getMandatoryBody if you want Camel to barf if it could not convert
> it.
>
>
>
> > Patrice
> >
> >
> > *********************************
> > This message and any attachments (the "message") are confidential and
> intended solely for the addressees.
> > Any unauthorised use or dissemination is prohibited.
> > Messages are susceptible to alteration.
> > France Telecom Group shall not be liable for the message if altered,
> changed or falsified.
> > If you are not the intended addressee of this message, please cancel
> it immediately and inform the sender.
> > ********************************
> >
> >
>
>
>
> --
> 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
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************
RE: can't tranform Body to DOM
Posted by pa...@orange-ftgroup.com.
>
> use getMandatoryBody if you want Camel to barf if it could not convert
> it.
>
I actually want Camel to convert it :-)
I did a quick & dirty workaround by parsing the Body to JDOM myself, until I understand why Camel type conversion does not seem to work.
I'll search the doc for this getMandatoryBody thing. Maybe I'll get the reason why it won't parse it then.
Thanks,
Patrice.
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************
Re: can't tranform Body to DOM
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Sep 24, 2010 at 2:48 PM, <pa...@orange-ftgroup.com> wrote:
> Hi,
> I receive JMS messages which are actually XML documents.
> In a processor I'm trying to get them as a DOM document since I need to process them in a certain way.
> I'm doing this:
> org.w3c.dom.Document doc = ex.getIn().getBody(org.w3c.dom.Document.class);
>
> And it does not seem to work (doc is always null). I don't get any error message.
> I have xpath() statements in my route, which are being correctly evaluated.
> I also have xslt transform endpoints which are working as expected.
> But here I need to replace an attribute value and I'd like to do without xslt.
>
use getMandatoryBody if you want Camel to barf if it could not convert it.
> Patrice
>
>
> *********************************
> This message and any attachments (the "message") are confidential and intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration.
> France Telecom Group shall not be liable for the message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
> ********************************
>
>
--
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
can't tranform Body to DOM
Posted by pa...@orange-ftgroup.com.
Hi,
I receive JMS messages which are actually XML documents.
In a processor I'm trying to get them as a DOM document since I need to process them in a certain way.
I'm doing this:
org.w3c.dom.Document doc = ex.getIn().getBody(org.w3c.dom.Document.class);
And it does not seem to work (doc is always null). I don't get any error message.
I have xpath() statements in my route, which are being correctly evaluated.
I also have xslt transform endpoints which are working as expected.
But here I need to replace an attribute value and I'd like to do without xslt.
Patrice
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************
Re: Camel Exchange Patters
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Sep 24, 2010 at 1:55 PM, Daniel Bevenius
<da...@gmail.com> wrote:
>>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 just took a look but could not find such information in chapter 3. But
> perhaps this version of the book has yet to be released?
>
Yeah the chapters are in copy editing and a new MEAP will be released
when all this work is done.
> Thanks,
>
> /Daniel
>
> 2010/9/24 Bengt Rodehav <be...@rodehav.com>
>
>> Perfect!
>>
>> /Bengt
>>
>> 2010/9/24 Claus Ibsen <cl...@gmail.com>
>>
>> > On Fri, Sep 24, 2010 at 10:27 AM, Claus Ibsen <cl...@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 <cl...@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 <cl...@gmail.com>
>> > >>> >
>> > >>> >> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
>> > >>> >> <ch...@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
>> >
>>
>
--
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
Re: Camel Exchange Patters
Posted by Daniel Bevenius <da...@gmail.com>.
>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 just took a look but could not find such information in chapter 3. But
perhaps this version of the book has yet to be released?
Thanks,
/Daniel
2010/9/24 Bengt Rodehav <be...@rodehav.com>
> Perfect!
>
> /Bengt
>
> 2010/9/24 Claus Ibsen <cl...@gmail.com>
>
> > On Fri, Sep 24, 2010 at 10:27 AM, Claus Ibsen <cl...@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 <cl...@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 <cl...@gmail.com>
> > >>> >
> > >>> >> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
> > >>> >> <ch...@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
> >
>
Re: Camel Exchange Patters
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Sep 24, 2010 at 4:08 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> But see, that's the thing, the model and api is not based on jbi, and we should correct that in the wiki as well. Web services use the same model. So it's really not jbi not even wsdl, but the same model, that's mostly related to the integration space than a spec in particular.
>
I think I should emphasize that I am talking about the confusing when
to use the getIn or getOut method on the Exchange. That part of the
API came from Apache ServiceMix when Camel was created. Other
frameworks, which are in the integration space as you put it, do not
have such methods. They simply have a single method named getMessage
(or something similar).
If you look in the WS API which comes out of the box with the JDK 1.6
onwards. You will not find the notion of a getIn or getOut methods to
retrieve a Message.
http://download.oracle.com/javase/6/docs/api/javax/xml/ws/package-summary.html
At least I could not find it when looking and I dont recall having
used it when using WS from the JDK.
Of couse messaging has the concept of the MEPs. It may be named
something else such as: one-way, fire-and-forget, request-reply,
request-response or as in the EIP book: event message and request
reply pattern. That part of the Exchange API is good.
Albeit the ExchangePattern enum used the WSDL standard names such as:
InOnly, InOut and then many others which are hardly know and used by
end users.
http://camel.apache.org/maven/camel-2.2.0/camel-core/apidocs/org/apache/camel/ExchangePattern.html
> I personally think jbi is pretty much dead, yet it does not affect Camel even a tiny bit. There are many other innovations Camel brings such as the independence on xml payloads, eips and a bunch of other goodies.
>
Yeah here we agree about the JBI being on the downslope and it will
become another dying spec.
> Please continue to express your personal views, we highly value them, and I encourage everybody in the community to do so. However, if you are not proposing a change (you seem to think that's better to leave it as is), why make the comment? If you however want to bring it up again, especially with camel 3.0 on the horizon, please be blunt about it and start the discussion again. Otherwise it's just a useless statement, that would bring more confusion to users than help anything. Or make such statement on the dev@ list rather than user@ (which is what I should have too).
>
Hadrian let's not go down this path, it may just be mistaken and
perceived as personal.
No I am not starting a debat about API changes for Camel 3.0. We have
debated this before and I think its best to keep the development cycle
of Camel 3 short and keep the API compatible with 2.x so people can
have a smooth transition. In fact we should start a thread about the
Camel 3.0 on the @dev forum shortly.
Therefore if we can improve the javadoc documentation and FAQ entries
then that would be good. Here is a JIRA ticket about this work
https://issues.apache.org/activemq/browse/CAMEL-3157
> My $0.02,
> Hadrian
>
>
>
> On Sep 24, 2010, at 9:30 AM, Claus Ibsen wrote:
>
>> On Fri, Sep 24, 2010 at 3:22 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>>> Let's not get there (again). The community agreed already at least twice that this api is a good abstraction of what we try to do. As any abstraction it has to be properly documented. If it's not clear enough, that's where I would focus.
>>>
>>
>> I can't recall we agreed this twice or more (since you say at least).
>> There was a heated debate about the API. And yes I think we should
>> leave it as it.
>>
>> On the other hand I am entitled to express my personal view on the API.
>> And it may be interesting for people in the community to hear from a
>> committer who was worked 30+ months on Camel, his though of the
>> Exchange API.
>>
>> There has been many Camel users who got started with Camel that got
>> confused / very confused about the API.
>> So its definitely not good, despite its nature back from the JBI specification.
>>
>> Competing integration frameworks such as Mule and Spring Integration
>> has a simpler Exchange API in this area.
>>
>> And the future of JBI is also dubios. So you may questions where if
>> someone creates a new integration framework, whether
>> he/she will go down the path of JBI and chose to have a getIn and
>> getOut methods on his/her's "Exchange" type.
>>
>>
>>
>>
>>> Hadrian
>>>
>>> On Sep 24, 2010, at 8:53 AM, Claus Ibsen wrote:
>>>
>>>> On Fri, Sep 24, 2010 at 2:51 PM, <pa...@orange-ftgroup.com> wrote:
>>>>>> "But the Camel routing engine will automatic handle using IN if there
>>>>>> is no OUT message."
>>>>>
>>>>> So this is the magic behind! :-)
>>>>> I don't remember reading this anywhere previously and I was wondering how data was flowing from in to out messages.
>>>>>
>>>>>>
>>>>>> Working on IN is just much easier to explain and use for end users.
>>>>>
>>>>> Honestly it was confusing to me.
>>>>> Writing something to an "in" message to make it go "out" was really confusing to me.
>>>>>
>>>>
>>>> Yeah the API is not optimal there. We have debated this many times on
>>>> the dev forums.
>>>>
>>>> I personally would remove the IN and OUT and only keen one message.
>>>> getMessage()
>>>>
>>>> But the current API is kinda stuck due it been there since 1.0 and the
>>>> old legacy from JBI and whatnot.
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> *********************************
>>>>> This message and any attachments (the "message") are confidential and intended solely for the addressees.
>>>>> Any unauthorised use or dissemination is prohibited.
>>>>> Messages are susceptible to alteration.
>>>>> France Telecom Group shall not be liable for the message if altered, changed or falsified.
>>>>> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
>>>>> ********************************
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
Re: Camel Exchange Patters
Posted by Hadrian Zbarcea <hz...@gmail.com>.
But see, that's the thing, the model and api is not based on jbi, and we should correct that in the wiki as well. Web services use the same model. So it's really not jbi not even wsdl, but the same model, that's mostly related to the integration space than a spec in particular.
I personally think jbi is pretty much dead, yet it does not affect Camel even a tiny bit. There are many other innovations Camel brings such as the independence on xml payloads, eips and a bunch of other goodies.
Please continue to express your personal views, we highly value them, and I encourage everybody in the community to do so. However, if you are not proposing a change (you seem to think that's better to leave it as is), why make the comment? If you however want to bring it up again, especially with camel 3.0 on the horizon, please be blunt about it and start the discussion again. Otherwise it's just a useless statement, that would bring more confusion to users than help anything. Or make such statement on the dev@ list rather than user@ (which is what I should have too).
My $0.02,
Hadrian
On Sep 24, 2010, at 9:30 AM, Claus Ibsen wrote:
> On Fri, Sep 24, 2010 at 3:22 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>> Let's not get there (again). The community agreed already at least twice that this api is a good abstraction of what we try to do. As any abstraction it has to be properly documented. If it's not clear enough, that's where I would focus.
>>
>
> I can't recall we agreed this twice or more (since you say at least).
> There was a heated debate about the API. And yes I think we should
> leave it as it.
>
> On the other hand I am entitled to express my personal view on the API.
> And it may be interesting for people in the community to hear from a
> committer who was worked 30+ months on Camel, his though of the
> Exchange API.
>
> There has been many Camel users who got started with Camel that got
> confused / very confused about the API.
> So its definitely not good, despite its nature back from the JBI specification.
>
> Competing integration frameworks such as Mule and Spring Integration
> has a simpler Exchange API in this area.
>
> And the future of JBI is also dubios. So you may questions where if
> someone creates a new integration framework, whether
> he/she will go down the path of JBI and chose to have a getIn and
> getOut methods on his/her's "Exchange" type.
>
>
>
>
>> Hadrian
>>
>> On Sep 24, 2010, at 8:53 AM, Claus Ibsen wrote:
>>
>>> On Fri, Sep 24, 2010 at 2:51 PM, <pa...@orange-ftgroup.com> wrote:
>>>>> "But the Camel routing engine will automatic handle using IN if there
>>>>> is no OUT message."
>>>>
>>>> So this is the magic behind! :-)
>>>> I don't remember reading this anywhere previously and I was wondering how data was flowing from in to out messages.
>>>>
>>>>>
>>>>> Working on IN is just much easier to explain and use for end users.
>>>>
>>>> Honestly it was confusing to me.
>>>> Writing something to an "in" message to make it go "out" was really confusing to me.
>>>>
>>>
>>> Yeah the API is not optimal there. We have debated this many times on
>>> the dev forums.
>>>
>>> I personally would remove the IN and OUT and only keen one message.
>>> getMessage()
>>>
>>> But the current API is kinda stuck due it been there since 1.0 and the
>>> old legacy from JBI and whatnot.
>>>
>>>
>>>
>>>>
>>>>
>>>> *********************************
>>>> This message and any attachments (the "message") are confidential and intended solely for the addressees.
>>>> Any unauthorised use or dissemination is prohibited.
>>>> Messages are susceptible to alteration.
>>>> France Telecom Group shall not be liable for the message if altered, changed or falsified.
>>>> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
>>>> ********************************
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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
Re: Camel Exchange Patters
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Sep 24, 2010 at 3:22 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> Let's not get there (again). The community agreed already at least twice that this api is a good abstraction of what we try to do. As any abstraction it has to be properly documented. If it's not clear enough, that's where I would focus.
>
I can't recall we agreed this twice or more (since you say at least).
There was a heated debate about the API. And yes I think we should
leave it as it.
On the other hand I am entitled to express my personal view on the API.
And it may be interesting for people in the community to hear from a
committer who was worked 30+ months on Camel, his though of the
Exchange API.
There has been many Camel users who got started with Camel that got
confused / very confused about the API.
So its definitely not good, despite its nature back from the JBI specification.
Competing integration frameworks such as Mule and Spring Integration
has a simpler Exchange API in this area.
And the future of JBI is also dubios. So you may questions where if
someone creates a new integration framework, whether
he/she will go down the path of JBI and chose to have a getIn and
getOut methods on his/her's "Exchange" type.
> Hadrian
>
> On Sep 24, 2010, at 8:53 AM, Claus Ibsen wrote:
>
>> On Fri, Sep 24, 2010 at 2:51 PM, <pa...@orange-ftgroup.com> wrote:
>>>> "But the Camel routing engine will automatic handle using IN if there
>>>> is no OUT message."
>>>
>>> So this is the magic behind! :-)
>>> I don't remember reading this anywhere previously and I was wondering how data was flowing from in to out messages.
>>>
>>>>
>>>> Working on IN is just much easier to explain and use for end users.
>>>
>>> Honestly it was confusing to me.
>>> Writing something to an "in" message to make it go "out" was really confusing to me.
>>>
>>
>> Yeah the API is not optimal there. We have debated this many times on
>> the dev forums.
>>
>> I personally would remove the IN and OUT and only keen one message.
>> getMessage()
>>
>> But the current API is kinda stuck due it been there since 1.0 and the
>> old legacy from JBI and whatnot.
>>
>>
>>
>>>
>>>
>>> *********************************
>>> This message and any attachments (the "message") are confidential and intended solely for the addressees.
>>> Any unauthorised use or dissemination is prohibited.
>>> Messages are susceptible to alteration.
>>> France Telecom Group shall not be liable for the message if altered, changed or falsified.
>>> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
>>> ********************************
>>>
>>>
>>
>>
>>
>> --
>> 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
Re: Camel Exchange Patters
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Let's not get there (again). The community agreed already at least twice that this api is a good abstraction of what we try to do. As any abstraction it has to be properly documented. If it's not clear enough, that's where I would focus.
Hadrian
On Sep 24, 2010, at 8:53 AM, Claus Ibsen wrote:
> On Fri, Sep 24, 2010 at 2:51 PM, <pa...@orange-ftgroup.com> wrote:
>>> "But the Camel routing engine will automatic handle using IN if there
>>> is no OUT message."
>>
>> So this is the magic behind! :-)
>> I don't remember reading this anywhere previously and I was wondering how data was flowing from in to out messages.
>>
>>>
>>> Working on IN is just much easier to explain and use for end users.
>>
>> Honestly it was confusing to me.
>> Writing something to an "in" message to make it go "out" was really confusing to me.
>>
>
> Yeah the API is not optimal there. We have debated this many times on
> the dev forums.
>
> I personally would remove the IN and OUT and only keen one message.
> getMessage()
>
> But the current API is kinda stuck due it been there since 1.0 and the
> old legacy from JBI and whatnot.
>
>
>
>>
>>
>> *********************************
>> This message and any attachments (the "message") are confidential and intended solely for the addressees.
>> Any unauthorised use or dissemination is prohibited.
>> Messages are susceptible to alteration.
>> France Telecom Group shall not be liable for the message if altered, changed or falsified.
>> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
>> ********************************
>>
>>
>
>
>
> --
> 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
Re: Camel Exchange Patters
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Sep 24, 2010 at 2:51 PM, <pa...@orange-ftgroup.com> wrote:
>> "But the Camel routing engine will automatic handle using IN if there
>> is no OUT message."
>
> So this is the magic behind! :-)
> I don't remember reading this anywhere previously and I was wondering how data was flowing from in to out messages.
>
>>
>> Working on IN is just much easier to explain and use for end users.
>
> Honestly it was confusing to me.
> Writing something to an "in" message to make it go "out" was really confusing to me.
>
Yeah the API is not optimal there. We have debated this many times on
the dev forums.
I personally would remove the IN and OUT and only keen one message.
getMessage()
But the current API is kinda stuck due it been there since 1.0 and the
old legacy from JBI and whatnot.
>
>
> *********************************
> This message and any attachments (the "message") are confidential and intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration.
> France Telecom Group shall not be liable for the message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
> ********************************
>
>
--
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
RE: Camel Exchange Patters
Posted by pa...@orange-ftgroup.com.
> "But the Camel routing engine will automatic handle using IN if there
> is no OUT message."
So this is the magic behind! :-)
I don't remember reading this anywhere previously and I was wondering how data was flowing from in to out messages.
>
> Working on IN is just much easier to explain and use for end users.
Honestly it was confusing to me.
Writing something to an "in" message to make it go "out" was really confusing to me.
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************
Re: Camel Exchange Patters
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Let me try to clarify this a bit, because there are 2 or 3 things mixed up in this thread.
Because "Working on IN is just much easier to explain and use for end users" doesn't necessarily mean that that is what you should do. And the "use" part is debatable anyway.
Every node on the route is a Processor. A route is nothing else but a chain (when executed, tree when constructed) of specialized Processors. An Exchange, that contains an in, out and exception moves along the Processor chain and sends the out of the previous Processor (if any) as in for the next Processor. If the previous Processor did not produce an out, than the previous in is used.
The MEP refers to 2 things, depending on the context. From outside the route, the question is should the camel route return a response or not? Which means: is the MEP in or in-out? Depending on the component the answer to this question is pretty clear, rarely we have to setExchangePattern explicitly. Now from the Processor perspective, should a Processor return a response or not? Or, in translation, is the Processor in or in-out. That's totally up to the developer of the processor, she knows what the MEP should be for the processor. There is almost no correlation between the route mep and processor mep, in the sense that you can have in-only processors in an in-out route and vice-versa.
As an example, you can have your jms endpoint set up as a consumer (in the from() that starts the route) and that could be in-only or in-out btw, but on the route you could use a log processor, that does not create an out, just logs the in, leaving it unchanged, or you can call on a choice processor, that again does not alter the in, just evaluates expression to make decisions down the road, or you can call on a web-service (via camel-cxf) that may produce an out, that will replace the in on the Exchange when moving to the next processor.
I think this should clarify things, but I can take it further if needed.
Cheers,
Hadrian
On Sep 24, 2010, at 8:46 AM, Claus Ibsen wrote:
> On Fri, Sep 24, 2010 at 2:44 PM, <pa...@orange-ftgroup.com> wrote:
>> Hello,
>> I'm not sure I understand why I shouldn't be using getOut().
>> Here is what I do at the end of my processor (that is transforming the message Body):
>>
>> // propagate headers
>> ex.getOut().setHeaders(ex.getIn().getHeaders());
>>
>> Am I wrong?
>
> No not really because you take matter in your own hand and propagate
> the headers.
> But the Camel routing engine will automatic handle using IN if there
> is no OUT message.
>
> Working on IN is just much easier to explain and use for end users.
> And there is less message creation, copying headers, and whatnot if
> you dont use OUT messages.
>
>
>>
>> I saw a couple of Processor samples that were only dealing with getIn() but I don't quite understand how and when the "in" message becomes an "out" message and I noticed that if I was propagating my headers by copying them from the "in" message to the "out" one I was no longer losing them.
>>
>> I'm looking forward to the latest MEAP version of Camel In Action since it seems I got it wrong somewhere.
>>
>>> -----Message d'origine-----
>>> De : bengt.rodehav@gmail.com [mailto:bengt.rodehav@gmail.com] De la
>>> part de Bengt Rodehav
>>> Envoyé : vendredi 24 septembre 2010 12:47
>>> À : users@camel.apache.org
>>> Objet : Re: Camel Exchange Patters
>>>
>>> Perfect!
>>>
>>> /Bengt
>>>
>>> 2010/9/24 Claus Ibsen <cl...@gmail.com>
>>>
>>>> On Fri, Sep 24, 2010 at 10:27 AM, Claus Ibsen <cl...@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 <cl...@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 <cl...@gmail.com>
>>>>>>>>
>>>>>>>>> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
>>>>>>>>> <ch...@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
>>>>
>>
>> *********************************
>> This message and any attachments (the "message") are confidential and intended solely for the addressees.
>> Any unauthorised use or dissemination is prohibited.
>> Messages are susceptible to alteration.
>> France Telecom Group shall not be liable for the message if altered, changed or falsified.
>> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
>> ********************************
>>
>>
>
>
>
> --
> 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
Re: Camel Exchange Patters
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Sep 24, 2010 at 2:44 PM, <pa...@orange-ftgroup.com> wrote:
> Hello,
> I'm not sure I understand why I shouldn't be using getOut().
> Here is what I do at the end of my processor (that is transforming the message Body):
>
> // propagate headers
> ex.getOut().setHeaders(ex.getIn().getHeaders());
>
> Am I wrong?
No not really because you take matter in your own hand and propagate
the headers.
But the Camel routing engine will automatic handle using IN if there
is no OUT message.
Working on IN is just much easier to explain and use for end users.
And there is less message creation, copying headers, and whatnot if
you dont use OUT messages.
>
> I saw a couple of Processor samples that were only dealing with getIn() but I don't quite understand how and when the "in" message becomes an "out" message and I noticed that if I was propagating my headers by copying them from the "in" message to the "out" one I was no longer losing them.
>
> I'm looking forward to the latest MEAP version of Camel In Action since it seems I got it wrong somewhere.
>
>> -----Message d'origine-----
>> De : bengt.rodehav@gmail.com [mailto:bengt.rodehav@gmail.com] De la
>> part de Bengt Rodehav
>> Envoyé : vendredi 24 septembre 2010 12:47
>> À : users@camel.apache.org
>> Objet : Re: Camel Exchange Patters
>>
>> Perfect!
>>
>> /Bengt
>>
>> 2010/9/24 Claus Ibsen <cl...@gmail.com>
>>
>> > On Fri, Sep 24, 2010 at 10:27 AM, Claus Ibsen <cl...@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 <cl...@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 <cl...@gmail.com>
>> > >>> >
>> > >>> >> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
>> > >>> >> <ch...@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
>> >
>
> *********************************
> This message and any attachments (the "message") are confidential and intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration.
> France Telecom Group shall not be liable for the message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
> ********************************
>
>
--
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
RE: Camel Exchange Patters
Posted by pa...@orange-ftgroup.com.
Hello,
I'm not sure I understand why I shouldn't be using getOut().
Here is what I do at the end of my processor (that is transforming the message Body):
// propagate headers
ex.getOut().setHeaders(ex.getIn().getHeaders());
Am I wrong?
I saw a couple of Processor samples that were only dealing with getIn() but I don't quite understand how and when the "in" message becomes an "out" message and I noticed that if I was propagating my headers by copying them from the "in" message to the "out" one I was no longer losing them.
I'm looking forward to the latest MEAP version of Camel In Action since it seems I got it wrong somewhere.
> -----Message d'origine-----
> De : bengt.rodehav@gmail.com [mailto:bengt.rodehav@gmail.com] De la
> part de Bengt Rodehav
> Envoyé : vendredi 24 septembre 2010 12:47
> À : users@camel.apache.org
> Objet : Re: Camel Exchange Patters
>
> Perfect!
>
> /Bengt
>
> 2010/9/24 Claus Ibsen <cl...@gmail.com>
>
> > On Fri, Sep 24, 2010 at 10:27 AM, Claus Ibsen <cl...@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 <cl...@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 <cl...@gmail.com>
> > >>> >
> > >>> >> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
> > >>> >> <ch...@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
> >
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************
Re: Camel Exchange Patters
Posted by Bengt Rodehav <be...@rodehav.com>.
Perfect!
/Bengt
2010/9/24 Claus Ibsen <cl...@gmail.com>
> On Fri, Sep 24, 2010 at 10:27 AM, Claus Ibsen <cl...@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 <cl...@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 <cl...@gmail.com>
> >>> >
> >>> >> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
> >>> >> <ch...@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
>
Re: Camel Exchange Patters
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Sep 25, 2010 at 10:01 AM, Tarjei Huse <ta...@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 <cl...@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 <cl...@gmail.com>
>>>>>>>>
>>>>>>>>> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
>>>>>>>>> <ch...@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
Re: Camel Exchange Patters
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Sep 25, 2010 at 10:01 AM, Tarjei Huse <ta...@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 <cl...@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 <cl...@gmail.com>
>>>>>>>>
>>>>>>>>> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
>>>>>>>>> <ch...@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
Re: Camel Exchange Patters
Posted by Tarjei Huse <ta...@scanmine.com>.
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?
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 <cl...@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 <cl...@gmail.com>
>>>>>>>
>>>>>>>> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
>>>>>>>> <ch...@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
Re: Camel Exchange Patters
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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.
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 <cl...@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 <cl...@gmail.com>
>>>>>>
>>>>>>> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
>>>>>>> <ch...@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
>
Re: Camel Exchange Patters
Posted by Tarjei Huse <ta...@scanmine.com>.
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 <cl...@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 <cl...@gmail.com>
>>>>>
>>>>>> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
>>>>>> <ch...@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
Re: Camel Exchange Patters
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Sep 24, 2010 at 10:27 AM, Claus Ibsen <cl...@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 <cl...@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 <cl...@gmail.com>
>>> >
>>> >> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
>>> >> <ch...@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
Re: Camel Exchange Patters
Posted by Claus Ibsen <cl...@gmail.com>.
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 <cl...@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 <cl...@gmail.com>
>> >
>> >> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
>> >> <ch...@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
Re: Camel Exchange Patters
Posted by Bengt Rodehav <be...@rodehav.com>.
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.
/Bengt
2010/9/14 Claus Ibsen <cl...@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 <cl...@gmail.com>
> >
> >> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
> >> <ch...@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
>
Re: Camel Exchange Patters
Posted by Claus Ibsen <cl...@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 <cl...@gmail.com>
>
>> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
>> <ch...@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
Re: Camel Exchange Patters
Posted by Bengt Rodehav <be...@rodehav.com>.
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?
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 <cl...@gmail.com>
> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
> <ch...@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
>
Re: Camel Exchange Patters
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
<ch...@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
Re: Camel Exchange Patters
Posted by Christian Müller <ch...@gmail.com>.
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":
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
Re: Camel Exchange Patters
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
All the MEPs is inherited from the JBI world. In reality there is only
2 which matters
- InOnly (fire and forget)
- InOut (request reply)
The MEP is just a "flag" on the Exchange.
In reality end users of Camel should really just forget about the OUT
message. Its also inherited from the JBI-world.
Its just much easier to always just change/alter the IN message.
The pipeline (pipes and filters EIP) is the default EIP pattern which
is applied in Camel routes when you do
from(X)
to(A)
to(B)
to(C)
So what happens is that A receives the output from X. The output is
automatically copied by Camel as it detects if the Exchange has an OUT
message, if not it re-uses the IN message. Likewise B receives the
output from A, which again is either the OUT message or re-used IN
message, and so forth.
========================
End users of Camel should really just forget about the OUT message.
Its there for advanced use cases and to work with the JBI-world.
========================
We had discussions before whether or not to remove the OUT message,
but it has always been part of Camel since 1.0 and due to the
JBI-world, and we decided to keep it as is.
On Mon, Sep 13, 2010 at 11:03 AM, Christian Mueller
<ch...@gmail.com> wrote:
>
> Hello Ashwin, hello Bengt!
>
> Thanks for your responses and the 2 cents :o)
> Is it not confusing to provide exchange pattern in Camel which are not
> supported (or differ from the spec), isn't?
>
> However, I think Ashwin you have more experience with Camel than I. Can you
> (or somebody else) recommend whether a processor/type converter/... should
> write the response into the in or out message? Or should this depend on the
> exchange pattern (write the response into the out message if the exchange
> out capable otherwise into the in message)? Or should the processor/...
> throw an exception, if it receives an exchange which is not out capable and
> the processors responsibility is to change the message?
> My understanding of In-Only was a fire and forgot (I don't expect a
> response).
>
> And I totally agree with Bengt, that this should be documented in the WIKI
> (also how the pipeline works and the messages are copied from out to in) or
> in the Camel in Action book.
>
> Cheers,
> Christian
> --
> View this message in context: http://camel.465427.n5.nabble.com/Camel-Exchange-Patters-tp2836060p2837443.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
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
Re: Camel Exchange Patters
Posted by Christian Mueller <ch...@gmail.com>.
Hello Ashwin, hello Bengt!
Thanks for your responses and the 2 cents :o)
Is it not confusing to provide exchange pattern in Camel which are not
supported (or differ from the spec), isn't?
However, I think Ashwin you have more experience with Camel than I. Can you
(or somebody else) recommend whether a processor/type converter/... should
write the response into the in or out message? Or should this depend on the
exchange pattern (write the response into the out message if the exchange
out capable otherwise into the in message)? Or should the processor/...
throw an exception, if it receives an exchange which is not out capable and
the processors responsibility is to change the message?
My understanding of In-Only was a fire and forgot (I don't expect a
response).
And I totally agree with Bengt, that this should be documented in the WIKI
(also how the pipeline works and the messages are copied from out to in) or
in the Camel in Action book.
Cheers,
Christian
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-Exchange-Patters-tp2836060p2837443.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel Exchange Patters
Posted by Ashwin Karpe <ak...@fusesource.com>.
Hi,
My 2 cents worth on this topic.
The exchange patterns in Camel are originally defined in the W3C WSDL 2.0
spec http://www.w3.org/TR/2004/WD-wsdl20-patterns-20040326/
http://www.w3.org/TR/2004/WD-wsdl20-patterns-20040326/
>From a camel perspective, the Robust In-Only is of limited applicability
since the consumer endpoint is expected to send an acknowledgement but the
processing is still In-Only. Internal to the route a RobustIn-only has no
meaning since the response is sent by the last route endpoint directly to
the consumer and does not go back through the processors encountered on the
way.
In-Optional out is more nuanced and again needs to be something that affects
the producer endpoint (client) and consumer endpoint (service) since both
have to be able to properly address the handshake. Moreover connection
timeouts and the window in which a response may be received needs to
addressed. Internal to the route it is no different than the In-Out.
Hence internal to the route In-Only and In-Out exchanges are sufficient
address all possibilities with the exchange pattern specifying a flag that
provides more context to the consumer and producer endpoints when a message
leaves or enters a camel route.
Hope this helps.
Cheers,
Ashwin...
-----
---------------------------------------------------------
Ashwin Karpe
Apache Camel Committer & Sr Principal Consultant
FUSESource (a Progress Software Corporation subsidiary)
http://fusesource.com http://fusesource.com
Blog: http://opensourceknowledge.blogspot.com
http://opensourceknowledge.blogspot.com
---------------------------------------------------------
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-Exchange-Patters-tp2836060p2836790.html
Sent from the Camel - Users mailing list archive at Nabble.com.