2012-02-23 9 views
2

AspectJでLTWをセットアップし、かなり早くて成功しました。ここでの設定は次のとおりです。 beans.xmlの:アップキャスト時にAspectJとSpring LTWが動作しません

<context:annotation-config /> 
<aop:aspectj-autoproxy /> 
<context:spring-configured /> 
<context:load-time-weaver /> 
<context:component-scan base-package="com.test.service" /> 

私のクラスにautowiredされるサービス:

@Service 
public class MyService { 
} 

親クラス:

public class Bar { 
} 

設定可能なクラス、そのautowiresサービスとバーを拡張します。

public class Foo { 
    private Bar bar; 
    public void setBar(Bar bar) { 
     this.bar = bar; 
    } 
} 

そして、成功したテストケース:

@Configurable 
public class BarExtended extends Bar{ 
    @Autowired 
    private MyService service; 
    public MyService getWeavedInObject(){ 
     return service; 
    } 
} 

そして、ちょうど親クラスのバーにreferanceを持っているクラス

。 BarExtendedのインスタンスを作成し、LTWが動作しているかどうかをチェックします。 Fooクラスは何もしません。

@Test 
public void simple(){ 
    Foo foo = new Foo(); 
    BarExtended barExtended = new BarExtended(); 
    assertNotNull("LTW didn't work.", barExtended.getWeavedInObject()); 
} 

このテストは緑色で実行されます。しかし、テストに失敗した後:

私はちょうどクラスBarExtendedがFooに設定されている行を挿入します。ダウンキャストは、AspjectJが機能しないようにします。私はBarExtendedクラスを使用するのFooクラスを変更する場合

ところで、(そう何のアップキャストは必要ありません):

public class Foo { 
    private BarExtended bar; 
    public void setBar(BarExtended bar) { 
     this.bar = bar; 
    } 
} 

上記のテストは動作します。構成可能なオブジェクトがアップキャストされているとき、なぜAspjectJがとても奇妙に振る舞うのか誰にも考えられていますか?

編集:Follwingも失敗:

@Test 
public void simple() { 
    Foo foo = new Foo(); 
    BarExtended barExtended = new BarExtended(); 
    Bar bar = (Bar) new BarExtended(); 
    foo.setBar(bar); 
    assertNotNull("LTW didn't work.", barExtended.getWeavedInObject()); 
} 

異なるBarExtendedオブジェクトがfooに設定され、第一barExtendedオブジェクトはAspectJのでは無視されます。 しかしBarExtendedをインスタンス化するためにリフレクションを使用して作品:

@Test 
public void simple() throws InstantiationException, IllegalAccessException{ 
    Foo foo = new Foo(); 
    Bar barExtended = (Bar) BarExtended.class.newInstance(); 
    foo.setBar(barExtended); 
    assertNotNull("LTW didn't work.", ((BarExtended)barExtended).getWeavedInObject()); 
} 

奇妙に、それはないですか?

どうもありがとう

よろしく、

アンドレアス

+0

どのバージョンのJava、AspectJをお使いですか? – Ralph

+0

Java 1.6、aspectj 1.6.12、およびSpring 3.1.0.RELEASEを使用します。 – noCodeFound

+0

血まみれの地獄、私もこの問題が発生しています。私はJIRAでこの問題を再現可能なテストケースとともに提起しました:https://jira.spring.io/browse/SPR-12901 – bertie

答えて

1

私はLTWが設定されていたと思った過去にトラブルがあったが、それは私がおよそかなりわからない理由のためではなかったです。だから私は今あなたの設定ファイルに以下の変更を加え、それがすべて動作するかどうかを見るために私の設定で100%明示的になっています。

<context:load-time-weaver aspectj-weaving="on" /> 

あなたはLTWが本当に実行しているそれを必要としない、あなたの設定から<aop:aspectj-autoproxy />を削除します。

JUnitテストを実行するときに、vm引数を渡して、JUnitにLTWエージェントがどこにあるかを伝えますか?そうでない場合は、LTWを実行していません。ここで

は、ドキュメントが名前 「loadTimeWeaver」と豆のように利用できる、このアプリケーションコンテキストのための春LoadTimeWeaverをアクティブについて<context:load-time-weaver />

を言うことです。 LoadTimeWeaverAwareインターフェイスを実装するBeanは、自動的に LoadTimeWeaverリファレンスを受け取ります。たとえば、SpringのJPAブートストラップのサポートです。デフォルトのウィーバーは自動的に です。 Spring 2.5以降:SpringのReflectiveLoadTimeWeaver(たとえば、 TomcatInstrumentableClassLoader)でサポートされているSunのGlassFish、OracleのOC4J、SpringのVMエージェントおよび ClassLoaderを検出します。 AspectJのロードタイムウィービングの起動は、単純な フラグ( 'aspectj-weaving'属性)を介して指定され、AspectJクラストランスフォーマーはSpringの LoadTimeWeaverによって登録されます。 "META-INF/aop.xml"リソースがクラスパスに 存在する場合、AspectJ製織はデフォルトで有効になります。これは、Spring Beanファクトリの外部でインスタンス化された 管理されていないクラス(通常、@Configurableアノテーションを使用して アノテートされたクラス)に依存性注入を適用するための現在のアプリケーションコンテキストをアクティブにします。これは、AnnotationBeanConfigurerAspectが クラスパス(つまりspring-aspects.jar)にある場合にのみ発生し、デフォルトで「スプリング設定」を有効に有効にします。 load-time weavingサポートをブートストラップする代わりに、コードベースの に関する情報については、 org.springframework.context.annotation.EnableLoadTimeWeavingのJavadocを参照してください。 <context:load-time-weaver />を入れ要約でそう

はloadTimeWeaverのIDでBeanを定義し、AspectJのがオンにする必要があるかどうかを判断するためにaop.xmlのような特別なファイルを探してクラスパスをスキャンについては本当にのようです。 aspectJが確実にオンになっていることを確かめるためには、何らかの理由でaspectJをオンにできない場合には、ちょうどあなたが望むものである起動時に失敗するように、実際にaspectj-weaving="on"を設定する必要があります。私のWebアプリケーションでは、私はWebアプリケーションの起動時にaspectJが動作していることを確認するテストを行い、そうでなければそれは不平を言う。

+1

長い答えをありがとう。 explizitを設定すると、aspetj-weaving = "on"は役に立ちませんでした。私もaop.xmlと一緒に遊んだ。成功しなかった。それは本当に騒がしい問題であるようだ。 – noCodeFound

1

私は、JUnitセットアップで、標準的なバネ計測器の設定で同じ問題を経験しました。 WebSphereLoadTimeWeaverを使用してWebSphereコンテナ内で同じコードを実行しても、何の問題もありません。

私のopenJPAコードは、ビルド時間が短縮されています。 私の@Configurableと他のいくつかの側面はロード時に行われます。

私の推測では、openjpaの継承戦略の強化はLTWと後で矛盾するため、@Configuarableとの組み合わせでいくつかのヌルポインタの問題が発生することがあります。

JUNIT例

AbstactWhatEver X =新しいコンクリート()。 // @Configurableは動作しています

AbstactWhatEver x = new Concrete(); x.callAnyMethod(); // openjpaでLTWの問題を抽象化します。したがって、@Configurableは動作しません。

上記の両方はWEBSPHERE ENVでの作業です。

この問題を解決しましたか?

+0

申し訳ありませんが、私はそれを解決しませんでした。 – noCodeFound

関連する問題