骆驼结束vs endChoice-不是通常的查询 [英] Camel end vs endChoice - not the usual query

问题描述

首先，是的，我进行了搜索，是的，我每次都指向相同的Apache文档. :-)我觉得有些困惑，我想我知道一个答案，所以让我列出一个我认为正确的示例，然后附上我认为正确的答案.谢谢.哦，我知道有些endChoice()行不是严格必需的，Camel会弄清楚的，但是我喜欢清楚地描绘出这些块，除非出于某些原因不使用它们.

First, yes, I have searched and, yes, I have read the same Apache document every one points to. :-) I think there is a bit of confusion and I think I know an answer, so let me lay out an example of what I thought was correct, follow it with what I think the answer is. Thanks. Oh, and I do know that some of the endChoice() lines are not strictly necessary and that Camel will figure it out, but I like the blocks to be cleanly delineated, unless there is some reason not to use them.

.choice()
    .when(X1)
        // do stuff
        .choice()
            .when(Y)
                //do more stuff
            .endChoice()  // close inner when block
        .end() // close inner choice block
    .endChoice()  // close first outer when
    .when(X2)
        // do other stuff
    .endChoice()  // close second outer when
.end() // close outer choice

因此，我最初看API时，以为end()用于关闭选择和拆分之类的东西，而endChoice()用于关闭选择选项(诸如when和else).看起来后者实际上是一个返回ChoiceDefinition的end().这使名称更好了.

So, my original look at the API, I thought that end() was for closing things like choice and split and that endChoice() was for closing choice options like when and otherwise. It looks more like the latter is actually an end() that returns a ChoiceDefinition. Which makes the name a little better.

但是，如果我取出标记为关闭内部选择块"的end()，则意味着我继续进行下一行endChoice().这样是否会关闭内部选择块?鉴于此，when(X2)仍在when(X1)块内.因此，我认为我需要用endChoice()替换end()而不是将其删除.因此结果将如下所示:

But, if I take out the end() labeled 'close inner choice block', this means I carry on to the next line, an endChoice(). Does this then close the inner choice block? Given that, the when(X2) is still within the the when(X1) block. So, I think that I need to replace the end() with an endChoice() rather than removing it. So the result would look like:

.choice()
    .when(X1)
        // do stuff
        .choice()
            .when(Y)
                //do more stuff
            .endChoice()  // close inner when block
        .endChoice() // close inner choice block
    .endChoice()  // close first outer when
    .when(X2)
        // do other stuff
    .endChoice()  // close second outer when
.end() // close outer choice

那么这是在骆驼中处理此问题的方法吗?还是我更想念一个简单的方法?谢谢您的宝贵时间.

So is this the way to handle this in Camel? Or is there a simpler way that I am just missing? Thanks for your time.

推荐答案

缩短答案: 我会这样称呼自己，这样就没有其他人可以了，答案是您做错了，应该没有嵌套的选择.

SHORT ANSWER: I will call myself on this so no one else has to, the answer is that you are doing it wrong and should not have nested choices.

长答案: 我继承了一个复杂的路由生成器，并试图对其进行清理以使其更加清晰.但是拉直并放入end()或endChoice()只会破坏事情.而且，是的，上述修复程序仍然无法解决问题.我不知道骆驼如何知道要去哪个街区.研究并试图找到好的嵌套示例最终使人们意识到，骆驼并非确实是为嵌套选择而设计的.它允许它，但是由于Java中的限制，它做得不好.因此，我尝试删除了嵌套选择.虽然这是可能的，但它意味着丑陋的冗余条件，例如:

LONG ANSWER: I inherited a complicated route builder and was trying to clean it up to make it clearer. But straightening and putting in either end() or endChoice() just broke things. And, yes, the above fix still broke things. I did not understand how Camel knew which block to go to. Research and trying to find good examples of nesting eventually drove home the fact that Camel is not really designed for nesting choices. It allows it, but due to limitations in Java, it does not do it well. So I tried removing my nested choices. While this would have been possible, it would have meant ugly redundant conditionals, like:

choice()
  .when(x and a)
    //do stuff xa
  .when(x not a)
    // do other x stuff
  .when(y and a)
    // do y stuff

只有我的水平至少会更高.进一步的思考和回顾我读过的东西带来了第二点启示.骆驼的重点是指导路线.每个选择的when块都应该只是将过程指向一条路线.它不应该在思考，处理或其他任何方式.最后，我们的小组将进行重构，以将大多数逻辑从路由构建器删除到Bean.我们将要进行的设计将非常简单:

Only mine would have had at least another level. Further thought and recalling things that I had read brought about the second bit of enlightenment. The whole point of Camel is directing routes. Each choice's when block should just be pointing the process to a route. It should not be thinking, processing, or anything. In the end, our group is going to be refactoring to remove most of the logic from the route builder to a bean. The design we will be working towards will be something simple:

   from(uri)
     .bean(class, method)  // do any processing
     .choice()
       .when(header("result").isEqualTo("A")
          .to(routeA)
       .endChoice()
       .when(header("result").isEqualTo("B")
          .to(routeB)
       .endChoice()
       .when(header("result").isEqualTo("C")
          .to(route)
       .endChoice()
      .end()

我对您的建议是避免嵌套选择.特别复杂的.您可能会使其正常工作，但是当您以后必须进行更改时，您将无法信任它.如果您发现自己想使用嵌套选择，请检查您要完成的工作，并确定它是否真正属于路由构建器.

My advice to you is to avoid nesting choices. Particularly complicated ones. You might get it to work, but you will not be able to trust it when you have to make changes later. If you find yourself tempted to use nested choices, examine what you are trying to accomplish and decide if it really belongs in a route builder.

这篇关于骆驼结束vs endChoice-不是通常的查询的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！