[
https://issues.apache.org/jira/browse/CAMEL-16825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17391682#comment-17391682
]
Dirk Vanhaute commented on CAMEL-16825:
---------------------------------------
Ok, I See where I was wrong, the ChoiceDefinition.addClause clears the block
before adding a when or otherwise, thus WhenDefinition and OtherwiseDefinition
are indeed on top of ChoiceDefinition.
It is a special construction. It is a child of choice, and
ChoiceDefinition.when creates the new WhenDefinition or OtherwiseDefinition,
but returns the current ChoiceDefinition instead.
Thus, indeed, I agree, endChoice should test first on being on level
ChoiceDefinition and, if so, decide we're fine, not end the choice, but just
return itself.
But then, what follows has two strange things:
WhenDefinition has an endParent method to cope with the in-between focus of
that level, but OtherDefinition does not have or inherit that method. Thus
nesting in "when" brings back ChoiceDefinition, but nesting in "otherwise"
leaves you unexpectedly in the otherwise level.
The second thing is that ProcessorDefinition.endChoice first part, check for
nested blocks, only checks for WhenDefinition, and not for OtherwiseDefinition,
and it does not call "end", so blocks are not popped.
If we remove that, the endChoice does an "end", ending whatever OutputNode we
were in. ( after having a safety check for WhenDefinition and OtherDefinition
),
So it appears to me, it should just be removed, and the OtherDefinition should
get an endParent identical to the one in WhenDefinition.
The only problem would be, that it would work just like end in any other place
outside endChoice. So perhaps, it should fail it end does not return
ChoiceDefinition.
> can not use endChoice() in nest choice DSL
> ------------------------------------------
>
> Key: CAMEL-16825
> URL: https://issues.apache.org/jira/browse/CAMEL-16825
> Project: Camel
> Issue Type: Wish
> Components: camel-core, eip
> Affects Versions: 3.6.0, 3.11.0
> Reporter: tang honggang
> Priority: Minor
> Fix For: 3.x
>
>
> I want to use nest choice DSL to finish some job, but it doesn't work well in
> my test case. When I use endChoice() in the inner choice clause, it return
> back to the outer choice definition actually.
> And this is the test case:
> ProcessorDefinition<?> end = from("timer:foo?period=5000&synchronous=true")
> .transform(simple("${random(1000)}"))
> .choice()
> .when(simple("${body} > 500"))
> .log("High number ${body}")
> .choice()
> .when(simple("${body} > 750"))
> .log("High number >750 ${body}")
> .endChoice()
> .otherwise()
> .log("High number <750 ${body}")
> .endChoice()
> .endChoice()
> .otherwise()
> .log("Low number ${body}")
> .endChoice();
>
> Though in this case, I can fix the problem by not use endChoice(), I see the
> code of endChoice(). I found that change the sequence of the two judgement
> below can fix my problem, but I am not sure the influence. So I hope you can
> give me an answer, thx!
> // are we nested choice?
> ProcessorDefinition<?> def = this;
> if (def.getParent() instanceof WhenDefinition) {
> return (ChoiceDefinition) def.getParent().getParent();
> }
> // are we already a choice?
> if (def instanceof ChoiceDefinition) {
> return (ChoiceDefinition) def;
> }
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
