骡子文档指出追赶异常策略类似于Java的catch块。 但不幸的是，有效负载被消耗（消息被消耗）; 从catch块有效负载丢失（不像Java方法，其中可以从捕获/最后块访问该方法输入参数）。
这种设计的问题是，在任何情况下，（从抓战略流程）这是不可能知道的错误，并持续其使用已知的丰富有效载荷（这引起了错误？）。 这个复杂造成错误数据的审核。
假设如果存在与10个消息处理器的流动，它成为乏味识别哪个投掷错误消息处理器。
我可以看到关于有效载荷2个解决方法：
1）将入站端点后，推有效载荷流量变量的每个消息处理器（再次另一个缺点是会发生什么到入站属性和附件前？）
2）使用回退策略例外零次尝试（该事务将被回滚），和原始输入消息可以是可用的。 （缺点：它是困难的内省上为什么错误happend和其上消息处理器 - 例如：我可以具有5个或6个DB处理器）
为什么这个就变得很重要的原因是配套生产的ESB应用程序变得更加容易。
例如，从捕捉块，如果我们能管的有效载荷和异常的详细信息（链接到一个UID），那么你就可以运行日志监视工具，把它推到一个实时仪表板监控目的/发出警报。 相同的方法可以被均匀地施加到所有的应用程序/流动和Java组件等
MMC是在这方面的薄弱 - 例如，如果你想以后出现5次，以剿从批处理作业的通知，MMC不能做到这一点。
我的问题是：1）是否有关于为什么有效载荷是由不可用的原因吗？ 可能的解决方法是推动（上次已知的数据）提供给另一变量作为消息称为originalPayload或originalInboundProperties的一部分？ 异常和有效载荷输送至一个appender的（而不是解决方法）的2）任何其他直接的方式？
Ananth克里希南（WHISHWORKS.com）
