問題タブ [compile-time-weaving]

静的ウィービングと動的ウィービングのパフォーマンスの向上を示すベンチマークまたは大規模なテストを見つけることができません。誰かがこれについて何か経験がありますか?

Maven/Spring (3.2.11.RELEASE) プロジェクトでアスペクト シービングを使用しようとしています。プラグイン用にこれを構成しました …</p>

これが私のアスペクトの依存関係です…</p>

しかし、「mvn clean install」を実行すると、これらの警告が表示されます…</p>

これらの警告が消えるように依存関係を適切に解決するにはどうすればよいですか?

編集: これは、春の WEB-INF/dispatcher-servlet.xml ファイルで設定した構成です。プライベートメソッド @Transactional を作ろうとしています...

私は現在、ポートレットとサーブレットの両方としてアクセスされるアプリケーションに取り組んでいます (少なくとも一部はそうです)。また、プロトタイプ スコープで依存関係を Bean に注入するためにコンパイル時ウィービングを使用しています。たとえば、ここで説明されているように、「新規」またはより一般的には Hibernate を介して作成された Bean です: http://www.chrissearle.org/ノード/285 これは今のところ正常に動作していますが、サーブレットとポートレットで異なる方法で呼び出す必要があるサーバー API を使用しています。そこで、アプリケーション内のサービス用のインターフェースを作成し、そのインターフェースに対して 2 つの実装 (1 つはサーブレット用、もう 1 つはポートレット用) を作成して、それぞれがサーバー API を異なる方法で使用できるようにしました。各実装は、対応するサーブレット/ポートレット アプリケーション コンテキストでのみ構成されます。サーブレットが最初に使用される場合、これは正常に機能し、サーブレットのサービス実装が注入されて使用されます。ただし、ポートレットが使用されると、ポートレットとサーブレットの両方に対して、ポートレットのサービス実装のみが注入されて使用されます。

サーブレットとポートレットのコンテナは別のものだと思っていました。これはエラーですか、Spring でサポートされていませんか、またはこれを修正または回避する方法はありますか? アプリケーションはまだ Spring 3.1.1 を使用していますが、現在のバージョン 4.1.1 は同じ動作を示しています。

私の設定は次のようになります（大幅に簡略化されています）：

インターフェース: MyService:

MyService-ポートレットの実装:

MyService-サーブレットの実装:

サーブレットとポートレットで使用する Bean:

Portlet-Controller と Servlet-Controller を呼び出します。

サーブレット-アプリケーション-context.xml:

portet-application-context.xml:

関連する pom.xml の依存関係

コンパイル時ウィービング構成:

サーブレット、ポートレット、サーブレットをこの順序で呼び出した場合のログ出力:

2014 年 11 月 27 日更新: 問題の概要を示すテスト ケースを作成しました。

https://github.com/ChrZae/servlet-portlet-spring-container-issue

コンパイル時のウィービングを介して AspectJ で Spring を使用して、コンテナーによって管理されていないオブジェクトに @Configurable スプリング アノテーションを使用しています。

@Configurable-annotated オブジェクトの例を次に示します。

このオブジェクトに注入するコンポーネント:

コンテキストが作成された後に TestConfigurable を作成すると、そこに TestComponent が正常に注入されますが、 @PostConstruct-annotated メソッドからそうしている場合、自動配線は行われません。

@PostConstruct を持つコンポーネント:

私が実行しているアプリケーション:

このアプリケーションが生成する出力は次のとおりです。

@PostConstruct メソッド内で作成された @Configurable オブジェクトに依存関係を注入する回避策はありますか? @Component アノテーションが付けられたすべての Bean はすでにコンテキスト内にあり、@PostConstruct が呼び出された時点でそれらの自動配線がすでに行われています。ここで Spring が自動配線を行わないのはなぜですか? ...

問題の解決に役立つ場合は、他の構成ファイル (context および pom.xml) を投稿できます。

更新 1: 問題の原因が見つかったようです。@Configurable でアノテーションが付けられたオブジェクトは、BeanFactoryAware を実装する AnnotationBeanConfigurerAspect によって初期化されます。このアスペクトは、BeanFactory を使用して Bean を初期化します。BeanFactory が AnnotationBeanConfigurerAspect に設定される前に、TestPostConstruct オブジェクトの @PostConstruct メソッドが実行されているようです。ロガーがデバッグに設定されている場合、次のメッセージがコンソールに出力されます。 "

回避策があるかどうかという質問は、まだ私にとって未解決です...

私はSpring AOPの初心者です。

アプリケーションが例外をスローしている間、アプリケーションのすべてのメソッドに対してアスペクト アドバイスを作成しました (Grails で試しました)。

ExceptionService.groovy

resources.groovy

ここでは、アプリケーション内で発生するすべての例外に対して正常に機能してallActionAdvice()います。しかし、それは機能していませんlog.error(logErrorActionAdvice())。

Googleで調査したところ、問題はAOPとウィービングなどのサードパーティの依存関係にあることがわかりました。そのため、アスペクト ウィービング (コンパイル時ウィービング) を行う必要があります。しかし、良い例は見つかりませんでした。

アスペクトのコンパイル時ウィービングを使用するには、Grails アプリケーションについて何を変更する必要がありますか?それとも他に何かする必要がありますか?

私が取り組んでいるプロジェクトは、次のような構造になっていDAOsます。

と

と

これまで、プロジェクトはコンパイル時ウィービングを使用<context:load-time-weaver/>していましたが、構成が変更され、 -javaagent:/opt/tomcat7-1/lib/spring-instrument.jar.

この変更が適用されたため、JpaBaseとGenericDaoの@Transactional注釈は織り込まれなくなりました。サービス クラスがオブジェクトのpersistメソッドを呼び出すたびに、トランザクションは開始されません。PersonDao

注目すべき:

• これは、コンパイル時のウィービングを使用するときに、過去に機能していました。
• で定義されているすべてのメソッドはPersonDao正しく織り込まれていますが、継承されたもの (例: persist(Object entity)) は織り込まれていません。

コンパイル時ウィービングとロード時ウィービングは同じことを行うことになっていますが、異なる時点で行われます。織り方が変わったのはなぜですか？

どういうわけかアプリケーションコンテキストを認識している私のスプリングブートアプリ用のカスタム JPA-EntityListener を書き込もうとしています。それを達成する方法を見つけるためにドキュメントを読んでいるときに、spring-data に同梱されている AuditingEntityListener と、Spring で管理されていないオブジェクトの構成を可能にするこのリスナーでも使用される @Configurable アノテーションに出くわしました。そのため、自分のリスナーで使用しようとしましたが、注釈が認識されませんでした。私はすでにこのトピックに関するドキュメントと多くの投稿を読みましたが、それらのいくつかはかなり古くなっているようです. それが私がここで尋ねている理由です：

いずれにしても、LoadTimeWeaving に spring-instrument.jar を指定する必要がありますか? 春のドキュメントには、他の方法があり、アプリケーションコンテキストで（クラスローダーごとに）構成することも可能であると書かれています。しかし、コマンドラインでエージェントを指定せずに @EnableLoadTimeWeaving でアプリを起動すると、エラーが発生します。

@EnableLoadTimeWeaving も @EnableSpringConfigured も指定されていないアプリケーションでも、起動時に AuditingEntityListener が認識されるのはなぜでしょうか。配布されている spring-jars が既に CTW でコンパイルされているためですか?

CompileTimeWeaving も試しましたが、ロンボクと競合しました。2011年からその解決策/回避策を見つけましたが、うまくいきませんでした。それを行う方法はありますか？

LTW と CTW の長所と短所は何ですか?カスタムの ApplicationContext 対応 JPAEntityListener を実装する最良の方法は何ですか?