[jira] [Commented] (CAMEL-6447) endChoice() has no effect in nested choice definition

[Dale King (JIRA)]

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

Dale King commented on CAMEL-6447:
----------------------------------

I see a slightly different but probably related problem. Here is a simple route 
to test it:

{noformat}
    <route>
        <from uri="timer://myTimer?period=1&amp;repeatCount=1" />
        <setHeader headerName="test">
            <constant>1</constant>
        </setHeader>
        <choice>
            <when>
                <simple>${header.test} &gt; 0</simple>
                <choice>
                    <when>
                        <simple>${header.test} &gt; 5</simple>
                        <log message="Should not get here" />
                    </when>
                    <otherwise>
                        <log message="Should get here" />
                    </otherwise>
                </choice>
            </when>
            <otherwise>
                <log message="Why do I get here???" />
            </otherwise>
        </choice>
    </route>
{noformat}

The output is:

{noformat}
    Should get here 
    Why do I get here???
{noformat}

So it executes both otherwise clauses, which is definitely wrong. I realize 
that the nesting is not necessary in this simple example, but where I found it, 
the inner choice was within a split and could not be eliminated. The outer 
choice was to actually handle the case for when the split would have nothing to 
split.
                
> endChoice() has no effect in nested choice definition
> -----------------------------------------------------
>
>                 Key: CAMEL-6447
>                 URL: https://issues.apache.org/jira/browse/CAMEL-6447
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-core
>    Affects Versions: 2.11.0
>            Reporter: Christian Tytgat
>
> I just upgraded from 2.10.4 to 2.11.0 and noticed that nested choice 
> definitions started acting strangely. For example:
> {code:java}
>             .choice()
>                 .when(header(Exchange.EXCEPTION_CAUGHT).isNotNull())
>                     // 1
>                     
> .setBody(exceptionMessage().append(SystemUtils.LINE_SEPARATOR).append(exceptionStackTrace()))
>                     .choice()
>                         .when(header(HEADER_CONTROLLER_ID).isNotNull())
>                             // 1a
>                             .setHeader(Exchange.FILE_NAME, 
> simple(AUDIT_CONTROLLER_FAILED_FILENAME + ".error.log"))
>                             .to(ENDPOINT_AUDIT_DIR)
>                         .otherwise()
>                             // 1b
>                             .setHeader(Exchange.FILE_NAME, 
> simple(AUDIT_FAILED_FILENAME + ".error.log"))
>                             .to(ENDPOINT_AUDIT_DIR)
>                             // INSERTING .end() here solves the issue
>                         .endChoice()
>                     .log(LoggingLevel.WARN, "DLQ written: 
> ${in.header.CamelExceptionCaught}"
>                 .otherwise()
>                     // 2
>                     .log(LoggingLevel.WARN, "DLQ written" + 
> MESSAGE_LOG_FORMAT)
>                 .end()
> {code}
> I have a test that is supposed to go through 1 and 1a. However it now passes 
> through 1 and 2!
> It looks like the endChoice() in 1b has no effect and the otherwise() in 2 is 
> executed instead of 1b. Inserting and end() statement as shown seems to solve 
> the issue, but it looks suspicious.
> It's probably a regression introduced by the fix for CAMEL-5953, but I'm not 
> 100% sure. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira