0

このアプリケーションには、エラー処理メカニズムがあり、エラーに対してランタイム例外をスローします。奇妙な振る舞いに気づき、これの根底にあるメカニズムを理解したい

1）状況1：ServiceActivatorからスローされた例外がMessageHandlingExceptionに変換されます

ServiceActivatorでエラーが発生すると、例外がスローされます。ErrorChannelで受け取るメッセージには、PayLoadasorg.springframework.integration.MessageHandlingExceptionと実際の例外がスローされます。 cause

2）状況2：フィルターからスローされた例外がMessageHandlingExceptionでマスクされていない

Filterでエラーが発生し、例外がスローされた場合、PayLoadは実際の例外であり、org.springframework.integration.MessageHandlingException

少し質問があります：

  • ServiceActivatorからの例外スローがFilterとは異なる動作をする理由
  • errorChannelと関連インフラストラクチャを利用しながら、Spring統合プロジェクトでのエラー処理に関する「ベストプラクティス」はありますか？

アップデート1：

フィルタは、フィルタチェーンの一部であるAbstractFileListFilterを拡張します-FileListFilterを実装するカスタムCompositeFileFilter

CompositeFileFilterはfile：inbound-channel-adapterによって使用されており、以下で宣言されているチャネルに出力を渡します。

<int:channel
  id="channelForFilesComingIn"
  datatype="java.io.File"
>
   <int:dispatcher task-executor="dispatchExecutor" />
</int:channel>

アップデート2：

私たちがやろうとしているのは、ファイルシステムからファイルを読み取って処理することです。ファイル読み取りの部分で、file:inbound-channel-adapter完全にアップロードされていないファイルや命名基準を満たしていないファイルをフィルタリングするCompositeFilterで使用します。

すべてのフィルターが通過した後、ファイルは処理のためにServiceActivatorに渡されます

上記のいずれか（フィルターチェーンまたはサービス）で、エラー状態が発生した場合は、DBおよび電子メールで報告する必要があります。これを実現するために、errorChannelによってキャッチされ、特殊なチャネルに渡されるApplicationExceptionをスローします。

4

1 に答える 1

0

明確にするためMessageHandlingExceptionに、 Message HANDLER が失敗したときに a がスローされます (ユーザー例外をラップします)。メッセージ ハンドラーは、メッセージを処理するものです。

で例外がスローされた場合、MessageSourceまだメッセージがないため、MessageHandlingException(または任意のMessagingException) は適用されません。

代わりに、ポーリングは失敗し、例外がポーラーにスローされます。

ポーリングされたエンドポイント ( MessageSource) で例外を処理する場合は、ポーラーに をErrorHandlingTaskExecutor提供する必要があります。これに を提供ErrorHandlerして、例外で必要なことを行うことができますが、まだメッセージがないため、スローされた元の例外です。によってMessageSource。

エラー チャネルに送信する場合は、 custom でそれを行う必要がありますErrorHandler。

于 2013-01-09T23:59:04.673 に答える