Apache Camel：处理器和 Bean 具有相同的用途吗？
两者似乎都有相同的目的。是否有什么区别使得其中一种在某些情况下有用而另一种则不起作用？
It seems like both serve the same purpose. Is there any difference that makes one useful in certain situations and not the other ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
实际上，它们非常相似，但 Processor 比 Bean 受到更多限制。我通常将处理器用于仅与 Exchange 交互的简单用例。此外，内联处理器是一种很好的交互方式，无需创建单独的类。
Bean 提供了更大的灵活性，并且还支持真正的 POJO 方法。这使您可以更轻松地与现有 API 集成（只需转换输入/输出以匹配等）。
Beans 还提供了有关 Camel 路由/EIP 集成
POJO 消费/生产 允许您可以与可重用的端点进行交互方式
用作表达式/谓词（用于 POJO EIP 实现...过滤器等）
In practice, they are very similar, but a Processor is more limited than a Bean. I generally use a Processor for simple use cases that just interact with the Exchange. Also, inline processors are a great way to interact without having to create a separate class.
Beans provide more flexibility and also support a true POJO approach. This allows you to more easily integrate with existing APIs (just need to convert the inputs/outputs to match, etc).
Beans also provide great features/flexibility with regards to Camel routing/EIP integration, including...
rich set of bindings that allow you to quickly bind data from the Exchange to attributes of a bean method, etc.
POJO consuming/producing allow you to interact with endpoints in a reusable manner
used as expressions/predicates (for POJO EIP implementation...filters, etc)
我想说，归根结底是一个偏好问题。我通常选择 POJO 方法，因此我开始使用 bean 进行处理，但随着时间的推移，我慢慢转向使用处理器。
在以下情况下我感到痛苦：
我知道 Camel 2.8 通过允许 bean 中的注释 指导 Camel 如何调用 bean 的方法。我不想走这条路——把 Camel 注释放入一个不应该关心它被 Camel 调用的 bean 中是错误的。
最后，我们创建了一个无注释、与客户端无关的 bean 和一个非常薄的处理器，它从 Camel 中提取所需的所有内容并将其传递给该 bean。
只是我的 2 美分 - bean 路线确实不错 - 它也能完成这项工作（特别是在 2.8 中）
编辑
Camel 使用 POJO 进行处理已经进行了许多改进自撰写本文以来的消息 - 该答案可能不再适用。
Boils down to a matter of preference, I'd say. I generally opt for the POJO approach and so I started using beans to do my processing, but over time I've slowly moved to using Processors.
I was feeling pain in the following cases:
I know that Camel 2.8 takes out some of the pain of these cases by allowing annotations in your bean which guide Camel on how to call your bean's methods. I didn't want to go this route -- felt wrong to put Camel annotations into a bean that shouldn't care that it's being called by Camel.
In the end we created an annotation-free, client-agnostic bean and a very thin Processor that pulls everything it needs from camel and passes it to that bean.
Just my 2 cents - the bean route really isn't a bad one - it'll do the job just as well (esp in 2.8)
EDIT
Many improvements have been made to camel's use of POJOs to process messages since this was written - this answer may no longer be applicable.