[jira] [Comment Edited] (CAMEL-16825) can not use endChoice() in nest choice DSL

["Dirk Vanhaute (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-16825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17603787#comment-17603787 ] 

Dirk Vanhaute edited comment on CAMEL-16825 at 9/13/22 10:16 PM:
-----------------------------------------------------------------

Hi Claus,  I believe this is what you are looking for: [https://github.com/apache/camel/pull/5890]

It does what I explained here :
{quote}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.
{quote}
What I explained further is that in CAMEL-4050, endParent was created in ProcessorDefinition and overridden in WhenDefinition but not in OtherDefinition.  The reasoning might have been that after an otherwise, the choice ends, and there is no reason to return to ChoiceDefinition.  

The NestedChoiceIssueTest is also constructed in this way of thinking :

{{.to("mock:big").otherwise().to("mock:med")}}
{{.endChoice().otherwise().to("mock:low").end();}}

The endChoice in this sequence should be followed by end() to terminate the inner choice, but the boolean construction onlyWhenOrOtherwise fails to notice this because it is followed by an otherwise.  This explains why his PR failed. The inner choice got the two otherwises.

It might also be this endParent thing that makes it impossible to use endChoice in a nested choice where it is not necessarry ( see my first example for a test ).


was (Author: d.vanhaute):
Hi Claus,  I believe this is what you are looking for: [https://github.com/apache/camel/pull/5890]

It does what I explained here : 
{quote}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.
{quote}
But since the original test failed, I am not sure this is a correct analysis of what happened.

What I explained further is in CAMEL-4050, endParent was created in ProcessorDefinition and overridden in WhenDefinition but not in OtherDefinition.  It might be this whole parent thing that makes it impossible to use endChoice in a nested choice where it is not necessarry ( see my first example for a test ).

> can not use endChoice() in nest choice DSL
> ------------------------------------------
>
>                 Key: CAMEL-16825
>                 URL: https://issues.apache.org/jira/browse/CAMEL-16825
>             Project: Camel
>          Issue Type: Improvement
>          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.20.10#820010)