camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: Camel Exchange Patters
Date Tue, 14 Sep 2010 12:16:52 GMT
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 <claus.ibsen@gmail.com>

> On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
> <christian.mueller@gmail.com> wrote:
> > Hello Claus!
> >
> > That's not (in my opinion) how it works currently. At present I work on a
> > route which looks like this:
> >
> > errorHandler(
> >  defaultErrorHandler()
> >    .retryAttemptedLogLevel(LoggingLevel.DEBUG)
> >    .retriesExhaustedLogLevel(LoggingLevel.INFO));
> >
> > onException(IllegalArgumentException.class)
> >  .handled(true)
> >  .maximumRedeliveries(0)
> >  .beanRef("myResultProvider", "failureResponse");
> >
> > from("cxf:bean:MyCoolService")
> >  .processRef("myValidator") // validates conditional rules
> >  .inOut("direct:mySubroute")
> >  .beanRef("myResultProvider", "successResponse")
> >
> >
> > If my validator throws a IllegalArgumentException and the result provider
> > writes the response into the in message, the web service will return
> null.
> > But if I write the response into the out message, the web service will
> > return it. So, I changes my bean to the following "pattern":
> >
>
> Well that could CXF Bean component having a bug.
>
> If you decide to use a Processor and work on Exchange then you use the
> low level Camel API and then you have to handle the IN/OUT stuff
> yourself.
>
>
>
>
> > if (exchange.getPattern().isOutCapable()) {
> >  exchange.getOut().setBody(response);
> > } else {
> >  exchange.getIn().setBody(response);
> > }
> >
> > And that's the same how the
> org.apache.camel.processor.ConvertBodyProcessor
> > works (I know you know this, but for the other guys.. :o) )
> >
> > public class ConvertBodyProcessor implements Processor {
> > ...
> >    public void process(Exchange exchange) throws Exception {
> >        Message in = exchange.getIn();
> >        if (charset != null) {
> >            exchange.setProperty(Exchange.CHARSET_NAME, charset);
> >        }
> >        Object value = in.getMandatoryBody(type);
> >
> >        if (exchange.getPattern().isOutCapable()) {
> >            Message out = exchange.getOut();
> >            out.copyFrom(in);
> >            out.setBody(value);
> >        } else {
> >            in.setBody(value);
> >        }
> >    }
> > ...
> > }
> >
> > Should our custom processors/beans/.. not work in the same way?
> >
> > Cheers,
> > Christian
> >
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message