1

注：Java、Spring AOP、Tomcatに精通していない限り、これは意味がありません。

問題は、Tomcat SESSIONS.serによって逆シリアル化されたときに、@ConfigurableとマークされたBeanが注入されないことです。

Spring 2.5.4、spring-tomcat-weaver-2.5.4、Tomcat6.0.14を使用するStruts1.2.9ベースの（レガシー）アプリケーションでこの動作に気づきました。

コード：

public class MyForm implements Serializable {
   private Foo myFoo; // getters and setters
}

public class Foo imlements Serializable {
   private Bar myBar; // getters setters
}

@Configurable("barTemplate")
public class Bar implements Serializable {
   @Autowired(required=true)
   private transient SessionFactory hello;
   // other transient dependencies ...
}

XMLは、BarをプロトタイプBeanとして構成します。

正しいcontext：spring-configuredおよびcontext：load-time-weaver設定が適用されます（Tomcatのコールドスタートで機能するため）。

初めて起動するときは、すべて正常に動作します。ただし、Tomcatを再起動すると、SESSIONS.serが書き込まれ、再起動するとMyFormが逆シリアル化されます。ただし、Barの依存関係は設定されていません。

しかし、Tomcatをシャットダウンし、SESSIONS.serファイルを削除して再起動すると、すべてが機能します。

変。

どんなアドバイスも大歓迎です。

4

1 に答える 1

1

春の部分はやらないのでスキップします。ただし、Springは、逆シリアル化後にそれらを再注入するのに十分スマートであると期待していることも認めなければなりません（編集： これはSpring 2.5.2で修正されたようです？）。

回避策の1つは、Tomcatのシャットダウン/起動中にセッションのシリアル化を無効にすることです。このようにして、新しいセッションから始めて、すべてが新しく構築され、注入されます。ただし、欠点は、Tomcatが再起動するたびにエンドユーザーがセッションデータを失うことです。

これを実現するには、問題のWebアプリケーションの要素に空の<Manager>要素を追加します。 pathname<Context>

<Context ...>
    <Manager pathname="" />
</Context>

これは基本的に、Tomcatにセッションマネージャをまったく使用しないように指示します。

于 2011-01-29T21:46:56.200 に答える