2

私はSpringとWeb開発全般に非常に慣れていないので、質問が混乱したり不完全な場合はご容赦ください...

私は現在、いくつかの一般的に使用されるデータを保持する「requestContext」と呼ぶ Bean がある Spring プロジェクトに取り組んでいます。この Bean はリクエスト スコープであり、サーブレット フィルタ (GenericFilterBean の子) によって設定されるように見えます。

HandlerInterceptor の preHandle メソッドで、この Bean が保持する情報に別の Bean (UserBean を呼び出します) からアクセスしようとしています。UserBean では、以下のように @AutoWired を使用して Bean にアクセスします。

@Autowired
private RequestContext requestContext;

次に、UserBeans メソッドの 1 つで、必要なデータにアクセスしようとします。問題は、リクエスト コンテキストにすべて null 値が含まれていることです。フィルターに慣れていないため、ライフサイクルの問題があるのではないかと思いましたが、いくつかのブレークポイントを使用すると、handlerInterceptor の前にフィルターが実行されていることがわかり、リクエスト コンテキスト データが設定されていることがわかります。その場合、少なくともインターセプターの preHandle メソッドでアクセスできると予想されますが、他の方法ではそうではありません。

アプリケーションの残りの部分 (フィルター、ハンドラー インターセプターを含む) はすべて既存の/既知の動作コードであるため、その Bean を使用しようとする時点までセットアップの問題はないと思います。私の期待、またはアクセスしようとしている方法に問題があります。

更新: 実際に requestContext を使用するクラスの例を 1 つ見つけました。これは別のフィルターです (ただし、フィルターを直接実装するのではなく、GenericFilterBean を拡張します)。このフィルター呼び出し

SpringBeanAutowiringSupport.processInjectionBasedOnCurrentContext(this)

その init() メソッドで。requestContext にアクセスしようとする直前にこの呼び出しを行うと、期待する値でインスタンス化されることに気付きました (また、デフォルトのコンストラクターで実行すると機能しないことにも注意してください)。私の場合、これは正しい解決策ではないことがわかりましたが、これが問題に光を当てることを願っています.

SpringBeanAutowiringSupport を読んで理解を深めようとしています。私が正しく理解していれば、これはの Bean が現在 WebApplicationContext にアクセスできないことを示しているため、この呼び出しが行われるまで Autowiring はデフォルトで機能しません (呼び出しが行われると、後続の要求は機能しないようです)。必要です)。これは、Bean の構成方法に問題があることを示していますか (IoC に正しく登録されていませんか?) 繰り返しますが、Spring に関する知識が不足していることをお許しください。IoC などのことについてはまだあまり知りません...

4

1 に答える 1

1

さて、ElderMael は何かに夢中になっているようで、私の質問は次の質問で答えられることになります: Spring HandlerInterceptors はどのようにインスタンス化されますか?

インターセプターとそれが使用する Bean のスコープを定義していない場合、それらはシングルトンであり、requestContext の 1 つのインスタンスで作成されます。リクエストごとに後続のインスタンスが作成されるとき、古い元のインスタンスがまだ残っています。processInjectionBasedOnCurrentContext メソッドを追加することは、オートワイヤリングを再度処理し、新しく作成されたインスタンスを見つけることだと思います。それを解決する理想的な方法を考える必要がありますが、HandlerInterceptor は状態を保持する必要がないため、おそらくそれと関連する Bean も同様にリクエスト スコープにすることができると思います。

于 2014-10-08T00:54:05.537 に答える