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?
--
View this message in context:
http://www.nabble.com/Are-nested-choice-processors-possible--tp17445856s22882p17445856.html
Sent from the Camel - Users mailing list archive at Nabble.com.
