camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gert Vanthienen <gert.vanthie...@skynet.be>
Subject Re: Are nested choice processors possible?
Date Mon, 26 May 2008 07:13:50 GMT
Drew,

With the nested choice() calls, the otherwise() is now called on the 
second choice() instead of the first one.  There is a method end() that 
allows you to end a block (such as the inner choice() block), but 
unfortunately this will return a plain ProcessorType instead of a 
ChoiceType, so you would have to add a cast to get the otherwise() 
back.  Something like :
   ((ChoiceType) from("").choice()
        .when(....)
             .choice()
                  .when().body().to("")
             .end())
        .otherwise().to("");

You could also use separate methods or add a local variable to hold the 
ChoiceType when building the route to avoid the cast, but it still isn't 
a really nice solution probably.  We are currently building a Scala DSL 
which will allow you to specify these more complex routes in a more 
elegant syntax using explicit {} to demarcate the blocks.  Have a look 
at http://activemq.apache.org/camel/scala-dsl-eip.html for a sneak 
preview...

Splitting up routes with a vm: or seda: endpoint will switch to 
asynchronous messaging semantics, which might or might not be good idea 
for you.  If you just want to split the routes with synchronous 
messaging, you can use a direct: endpoint.

Regards,

Gert




Drew McAuliffe wrote:
> I seem to be having trouble with nesting "choice" in the DSL. I'm trying to
> determine what to do based on the contents of the header. In one of those
> cases, I want to make another choice. Something like this:
>
> .choice()
>   .when(header("h1").isEqualTo("val1"))
>     .choice()
>       .when(header("h2").isEqualTo("val1")).to("vm:somewhere")
>       .when(header("h2").isEqualTo("val2")).to("vm:somewhereElse")
>   .otherwise()
>     .to("vm:somewhereElseEntirely")
>
> The first "when" in the first "choice" evaluates correctly. But the
> "otherwise" route on the first "choice" doesn't seem to get called. If I
> break it up as follows, everything works:
> .choice()
>   .when(header("h1").isEqualTo("val1"))
>     .to("vm:temp")
>   .otherwise()
>     .to("vm:somewhereElseEntirely")
> ;
> from("vm:temp")
>   .choice()
>     .when(header("h2").isEqualTo("val1")).to("vm:somewhere")
>     .when(header("h2").isEqualTo("val2")).to("vm:somewhereElse")
> ;
>
> Any ideas? Are "choice"s not meant to be nested? Is using a temporary "VM"
> endpoint a good idea in this case? This was the kind of stuff I was forced
> to use in Mule that I thought I'd be able to avoid with Camel (the creation
> of multiple endpoints for managing complex routes). My preference is to only
> create endpoints where things are coming in or going out, not as
> placeholders for routing rules. Unless of course there is an advantage in
> performance or pooling or something to be gained by that, that I'm not aware
> of.
>
> Any ideas?
>   


Mime
View raw message