春のAOP。 インタビューからの小さな質問

先日、ここで別のインタビューに参加する機会がありました。 そこで彼らは私にそのような質問をしました。 method1（）を呼び出すと、実際には（トランザクションの観点から）何が実行されますか？

public class MyServiceImpl { @Transactional public void method1() { //do something method2(); } @Transactional (propagation=Propagation.REQUIRES_NEW) public void method2() { //do something } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まあ、私たちは皆賢く、ドキュメントを読んで、少なくともエフゲニーボリソフのスピーチのビデオを見ます。 したがって、私たちは正しい答えを知っています（正しい*は、私たちに尋ねる人の答えです）。 そして、このように聞こえるはずです。



「 Spring AOPはアノテーションを介してトランザクションをサポートするために使用されるという事実により、method1（）が呼び出されると、オブジェクトのプロキシメソッドが実際に呼び出されます。 新しいトランザクションが作成され、MyServiceImplクラスのmethod1（）呼び出しが呼び出されます。 そしてmethod1（）からmethod2（）を呼び出すと、プロキシへの呼び出しはなく、クラスのメソッドがすぐに呼び出されるため、新しいトランザクションは作成されません 。



しかし、あなたはそれがどのように起こるか知っています、あなたはすでに長い間正しい答えを知っているようです。 そして、この知識を定期的に適用してください。 そして、突然...そして突然、あなたは考えます：「 ちょっと待ってください。SpringAOPを使用すると、JDKを介して、おそらくCGLIBを使用してプロキシを作成できるからです。 また、CTWまたはLTWが接続されている可能性もあります。 そして、そのような答えは常に真実であると？ 「。



それでは、興味深いですか？ 確認する必要があります。



実際、トランザクションの作成方法には興味がありませんでしたが、Spring AOPは常にプロキシオブジェクトを作成し、これらのプロキシオブジェクトは上記の動作を行うというステートメントに興味がありました。 明らかに、JDK動的プロキシを使用してラッパーを作成する場合、このステートメントはtrueでなければなりません。 実際、この場合、オブジェクトはインターフェイスに基づいて作成されます。 そのようなオブジェクトはプロキシパターンに完全に準拠し、すべてが非常に論理的に見えます。 しかし、CGLibは異なるアプローチを取り、クラス継承を作成します。 そして、ここで、振る舞いが同一であるかどうかに疑いが既に忍び込み始めています。 バインドに外部ツールを使用することを決定すると、すべてがさらに興味深いものになります。 CTW（コンパイル時ウィービング）およびLTW（ロード時ウィービング）。



まず、Spring AOPドキュメントのいくつかの定義をここで追加します。これらの定義は、検討対象のコンテキストで最も興味深いものです（実際、他のすべての定義は、ドキュメント自体で見つけることができます（例：）

• AOPプロキシ：アスペクトコントラクトを実装するためにAOPフレームワークによって作成されたオブジェクト（メソッドの実行などをアドバイス）。 Spring Frameworkでは、AOPプロキシはJDK動的プロキシまたはCGLIBプロキシになります。
• ウィービング：アスペクトを他のアプリケーションタイプまたはオブジェクトとリンクして、アドバイスされたオブジェクトを作成します。 これは、コンパイル時（たとえば、AspectJコンパイラを使用）、ロード時、または実行時に実行できます。 Spring AOPは、他の純粋なJava AOPフレームワークと同様に、実行時にウィービングを実行します。

ここで、実験を行う最も単純なプロジェクトを作成します。 これを行うには、Spring Bootを使用します。 開発にはSTSを使用しているため、このIDEの手順を説明します。 しかし、概して、他のツールについてはすべてがほぼ同じになります。



Spring Bootプロジェクトを作成するウィザードを起動します：File> New> Spring Starter Project。 フォームに入力します。

• 名前 ：AOPTest;
• タイプ ：Maven;
• 包装 ：ジャー;
• Javaバージョン ：8;
• 言語 ：Java;
• グループ ：com.example.AOPTest;
• アーティファクト ：AOPTest;
• パッケージ ：com.example.AOPTest。

残りはあなたの好みです。 [次へ]ボタンをクリックして、もう一度入力します。

• Spring Bootバージョン ：2.0.0.M7（そして、なぜですか？これは執筆時点で入手可能な最新バージョンです）。 Spring Bootの本当に良いところは、最小限の形式で必要な依存関係と定義がすべて含まれていることです。 Springから何を使用するかを正確に示す必要があります。
• 同じステップで、使用可能な依存関係のリストで、アスペクト（フィルターを使用できます）を見つけて追加します。

完了をクリックします。 アプリケーションの準備ができました。 作成されたPOMは次のようになります。

 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.example.AOPTest</groupId> <artifactId>AOPTest</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>jar</packaging> <name>AOPTest</name> <description></description> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.0.0.M7</version> <relativePath/> <!-- lookup parent from repository --> </parent> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> <java.version>1.8</java.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-aop</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> </project>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、マイルストーンバージョンを使用しているため、コードが若干大きくなり、リポジトリへのリンクが追加されます。



アプリケーションクラスも生成されます。

 package com.example.AOPTest; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication public class AopTestApplication { public static void main(String[] args) { SpringApplication.run(AopTestApplication.class, args); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちの注釈（私が言ったように、トランザクションには興味がありませんが、この状況をどのように扱うかについては、注釈を作成します）：

 package com.example.AOPTest; import static java.lang.annotation.ElementType.METHOD; import static java.lang.annotation.RetentionPolicy.RUNTIME; import java.lang.annotation.Retention; import java.lang.annotation.Target; @Retention(RUNTIME) @Target(METHOD) public @interface Annotation1 { }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そしてアスペクト

 package com.example.AOPTest; import org.aspectj.lang.annotation.Aspect; import org.aspectj.lang.annotation.Before; import org.aspectj.lang.annotation.Pointcut; import org.springframework.stereotype.Component; @Aspect @Component public class MyAspect1 { @Pointcut("@annotation(com.example.AOPTest.Annotation1)") public void annotated() {} @Before("annotated()") public void printABit() { System.out.println("Aspect1"); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

@ Annotation1アノテーションを持つメソッドにバインドされるアスペクトを実際に作成しました。 そのようなメソッドを実行する前に、「Aspect1」というテキストがコンソールに表示されます。

クラス自体にもComponentとして注釈が付けられていることに注意してください。 これは、Springがこのクラスを見つけて、それに基づいてBeanを作成できるようにするために必要です。



これでクラスを追加できます。

 package com.example.AOPTest; import org.springframework.stereotype.Service; @Service public class MyServiceImpl { @Annotation1 public void method1() { System.out.println("method1"); method2(); } @Annotation1 public void method2() { System.out.println("method2"); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

目標、目的、ツールが決定しました。 実験を開始できます。

JDK動的プロキシとCGLibプロキシ

ドキュメントに目を向けると、そこに次のテキストがあります。

Spring AOPは、JDK動的プロキシまたはCGLIBを使用して、特定のターゲットオブジェクトのプロキシを作成します。 （選択肢がある場合は、JDK動的プロキシが推奨されます）。

プロキシされるターゲットオブジェクトが少なくとも1つのインターフェイスを実装する場合、JDK動的プロキシが使用されます。 ターゲットタイプによって実装されるすべてのインターフェイスがプロキシされます。 ターゲットオブジェクトがインターフェイスを実装しない場合、CGLIBプロキシが作成されます。

CGLIBプロキシの使用を強制する場合（たとえば、インターフェイスによって実装されたメソッドだけでなく、ターゲットオブジェクトに対して定義されたすべてのメソッドをプロキシするため）、そうすることができます。

CGLIBプロキシの使用を強制するには、<aop：config>要素のproxy-target-class属性の値をtrueに設定します

つまり、ドキュメントによると、JDKとCGLibの両方を使用してプロキシオブジェクトを作成できますが、JDKを優先する必要があります。 また、クラスに少なくとも1つのインターフェイスがある場合、使用されるのはJDK動的プロキシです（ただし、proxy-target-classフラグを明示的に設定することで変更できます）。 JDKを使用してプロキシオブジェクトを作成すると、すべてのクラスインターフェイスと新しい動作を実装するメソッドが入力に転送されます。 その結果、プロキシパターンを正確に実装するオブジェクトを取得します。 これはすべて、Beanの作成段階で行われるため、依存性注入が開始されると、実際にはこのプロキシオブジェクトが実装されます。 そして、すべての呼び出しが彼に行われます。 しかし、機能の彼の部分を完了した後、彼はソースクラスのオブジェクトに目を向けて、彼にコントロールを与えます。 このオブジェクト自体がメソッドの1つに変わる場合、プロキシなしの直接呼び出しになります。 実際、このまさに動作は正しい答えに従って期待されるものです。



これですべてがはっきりしているように見えますが、CGLibはどうですか？ 結局のところ、実際にはプロキシオブジェクトを作成するのではなく、クラスの子孫を作成します。 そして、ここで私の脳はすでに叫んでいます：やめて！ 結局のところ、ここには、OOPに関する教科書のほんの一例があります。

 public class SampleParent { public void method1() { System.out.println("SampleParent.method1"); method2(); } public void method2() { System.out.println("SampleParent.method2"); } } public class SampleChild extends SampleParent { @Override public void method2() { System.out.println("SampleChild.method2"); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、SampleChildは基本的にプロキシオブジェクトです。 そして、ここで私はすでにOOP（または私の知識）さえも疑い始めています。 結局、継承がある場合は、親の代わりにオーバーラップメソッドを呼び出す必要があり、JDKダイナミックプロキシを使用するときの動作とは異なります。



別のオプションもありますが、おそらくCGLibを使用してオブジェクトを作成する方法を誤解しました。実際、それらは「相続人」ではなく、「何らかのプロキシ」でもあります。 そして、もちろん、少なくとも何かを確認する最も簡単な方法は、簡単な例を確認することです。 それでは、別の小さなプロジェクションを作成しましょう。



今回は、Springはもう必要ありません。最も単純なmavenプロジェクトを作成し、CGLibへの依存関係をpomに追加するだけです（実際、これはすべてpomファイルのコンテンツです）。

  <dependencies> <dependency> <groupId>cglib</groupId> <artifactId>cglib</artifactId> <version>3.2.5</version> </dependency> </dependencies>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2つのSampleクラスを作成されたプロジェクトに追加します（念のため、OOPの原則は結局違反しないことを確信させるため）と、クラス自体にテストを実行するmain（）メソッドを追加します。

 package com.example.CGLIBTest; import java.lang.reflect.Method; import net.sf.cglib.proxy.Enhancer; import net.sf.cglib.proxy.MethodInterceptor; import net.sf.cglib.proxy.MethodProxy; public class CGLIBTestApp { public static void main(String[] args) { new SampleChild().method1(); System.out.println("//------------------------------------------//"); Enhancer enhancer = new Enhancer(); enhancer.setSuperclass(SampleParent.class); enhancer.setCallback(new MethodInterceptor() { public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable { if(method.getName().equals("method2")) { System.out.println("SampleProxy.method2"); return null; } else { return proxy.invokeSuper(obj, args); } } }); ((SampleParent) enhancer.create()).method1(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の行では、クラスのSampleChildオブジェクトでmethod1（）を呼び出し（先ほど言ったように、念のため...）、エンチャンサーを作成します。 Enchancerオブジェクトでは、method2 method（）の動作をオーバーライドします。 その後、実際には新しいオブジェクトが作成され、その上で既にmethod1（）を呼び出しています。 実行します。

 SampleParent.method1 SampleChild.method2 //------------------------------------------// SampleParent.method1 SampleProxy.method2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ふう...あなたは吐き出すことができます。 出力の最初の2行によると、過去20年間でPLOに変化はありません。



最後の2行は、CGLibを介して作成されたオブジェクトでは、私の理解が完全に正しいことを示しています。 これは本当に継承です。 そして、その瞬間から、この方法で作成されたオブジェクトは、JDK動的プロキシオブジェクトが強化されたのとまったく同じように機能するのではないかと疑っています。 したがって、私たちはもはや遅延することなく、実験のために作成したプロジェクトを立ち上げます。 これを行うには、アプリケーションクラスにランナーを追加する必要があり、クラスは次の形式を取ります。

 package com.example.AOPTest; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.boot.CommandLineRunner; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.context.ApplicationContext; import org.springframework.context.annotation.Bean; @SpringBootApplication public class AopTestApplication { @Autowired private MyService myService; public static void main(String[] args) { SpringApplication.run(AopTestApplication.class, args); } @Bean public CommandLineRunner commandLineRunner(ApplicationContext ctx) { return args -> { myService.method1(); }; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それでも、私はこのSpring Bootが好きです。やらなければならないことはすべて私たちのためにすでに行われています（この小さな叙情的な余談を許します）。 @SpringBootApplicationアノテーションには、Spring Bootを使用しなかった場合に記述する必要のある他の多くのアノテーションが含まれています。 デフォルトでは、このクラスに設定が含まれていることと、パケット内にビン定義が存在するかどうかをスキャンする必要があることがすでに示されています。



同時に、ここで新しいCommandLineRunner Beanを作成しています。このBeanは、実際にBean myServiceでmethod1（）メソッドを呼び出します。

 Aspect1 method1 method2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

うーん...この結論は私にとって予想外でした。 はい、Spring AOPがJDK動的プロキシを使用する場合、期待に完全に一致します。 すなわち サービスのmethod1（）を呼び出すと、アスペクトが最初に機能し、その後、制御がMyServiceImplクラスのオブジェクトに転送され、このオブジェクト内でさらに呼び出しが行われます。



しかし、クラスに単一のインターフェイスを指定しませんでした。 そして、この場合のSpring AOPはCGLibを使用することを期待していました。 たぶん、Spring自体が何らかの形でこの制限を回避し、ドキュメントに記載されているように、特に指定がない限り、JDK動的プロキシをメインオプションとして使用しようとしますか？



アプリケーションの呼び出し時に呼び出しスタックの少し上に座った後、つまり Beanを作成する段階で、実際に使用するライブラリを選択する場所を見つけました。 これは、DefaultAopProxyFactoryクラス、つまりメソッドで発生します

  @Override public AopProxy createAopProxy(AdvisedSupport config) throws AopConfigException { if (config.isOptimize() || config.isProxyTargetClass() || hasNoUserSuppliedProxyInterfaces(config)) { Class<?> targetClass = config.getTargetClass(); if (targetClass == null) { throw new AopConfigException("TargetSource cannot determine target class: " + "Either an interface or a target is required for proxy creation."); } if (targetClass.isInterface() || Proxy.isProxyClass(targetClass)) { return new JdkDynamicAopProxy(config); } return new ObjenesisCglibAopProxy(config); } else { return new JdkDynamicAopProxy(config); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このクラスのJavadocsは言う

Default AopProxyFactory implementation, creating either a CGLIB proxy or a JDK dynamic proxy.



Creates a CGLIB proxy if one the following is true for a given AdvisedSupport instance:



• the optimize flag is set

• the proxyTargetClass flag is set

• no proxy interfaces have been specified



In general, specify proxyTargetClass to enforce a CGLIB proxy, or specify one or more interfaces to use a JDK dynamic proxy.

また、クラスへのインターフェイスが表示されないようにするには、hasNoUserSuppliedProxyInterfaces（config）条件を確認するだけです。 この場合、trueを返します。 そして、結果として、CGLibを介したプロキシ作成が呼び出されます。



言い換えると、Spring AOPはCGLibを使用してBeanクラスから継承者を作成するだけでなく、この段階で本格的なプロキシオブジェクト（つまり、プロキシパターンに対応するオブジェクト）を実装します。 彼がこれをどのように正確に行うかは、誰でも自分で確認でき、このアプリケーションのデバッグ中の手順を実行できます。 私にとってより重要なことは、Springが内部で使用しているライブラリとまったく違いがないという結論でした。 いずれにせよ、彼の行動は同じです。 いずれにせよ、エンドツーエンドプログラミングの編成のために、プロキシオブジェクトが作成され、実際に実際のクラスオブジェクトのメソッドへの呼び出しが提供されます。 一方、同じクラスのメソッドから呼び出されたメソッドは、Spring AOPによってインターセプト（ブロック）できません。



これは、JDKとCGLibを介して作成されたプロキシの動作の違いを検索することで停止できます。 しかし、私の探究心は、少なくともいくつかの矛盾を見つける試みを続けました。 そして、プロキシオブジェクトがJDKを介して作成されるようにすることにしました。 理論的には、それは単純であり、多くの時間を費やすべきではありません。 ドキュメントに戻ると、この特定のオプションはデフォルトで使用する必要があることを思い出すことができますが、1つの警告があります。オブジェクトにはインターフェースが必要です。 また、ProxyTargetClassフラグをクリアする必要があります（つまり、false）。



最初の条件は、プロジェクトに適切なインターフェイスを追加することで満たされます（このコードはまだ提供しません。どのように見えるかはかなり明らかだと思います）。 2番目-対応する注釈を構成に追加することにより、つまり そのようなもの

 @SpringBootApplication @EnableAspectJAutoProxy(proxyTargetClass = false) public class AopTestApplication {
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし実際には、すべてがそれほど単純ではないことが判明しました。 両方のチェック-config.isProxyTargetClass（）およびhasNoUserSuppliedProxyInterfaces（config）はまだtrueを返しました。 これで私はまだ停止することにしました。 私は質問に対する回答を得て、また、（少なくともSpring 5を使用している場合は）ドキュメントの主張にもかかわらず、プロキシオブジェクトはCGLibを使用して作成される可能性が高いことを思い出しました。



ところで、Spring AOPにJDKを強制的に使用する方法を誰かが知っている場合は、コメントをお待ちしています。

コンパイル時の織りとAspectJ

さて、アスペクトの下でのコードの振る舞いは、どのライブラリが内部で使用されるかに依存するという仮説は失敗しました。 ただし、これはSpringがAOPに関して提供するすべての可能性ではありません。 Spring AOPが提供する最も興味深い（私の意見では）機能の1つは、AspectJコンパイラを使用する機能です。 すなわち フレームワークは、アスペクトを記述するために@AspectJアノテーションを使用する場合、ランタイムウィービングからコンパイル時ウィービングに切り替えるために変更を加える必要がないように書かれています。 さらに（Spring Bootのもう1つの利点）、必要なすべての依存関係が既に含まれています。 コンパイルを実行するプラグインのみを接続できます。



これを行うには、pom'nikに変更を加えます。 ビルドセクションは次のようになります。

 <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>aspectj-maven-plugin</artifactId> <version>1.10</version> <configuration> <complianceLevel>1.8</complianceLevel> <source>${maven.compiler.source}</source> <target>${maven.compiler.target}</target> <showWeaveInfo>true</showWeaveInfo> <verbose>true</verbose> <Xlint>ignore</Xlint> <encoding>UTF-8 </encoding> <weaveDirectories> <weaveDirectory>${project.build.directory}/classes</weaveDirectory> </weaveDirectories> <forceAjcCompile>true</forceAjcCompile> </configuration> <executions> <execution> <goals> <goal>compile</goal> <!-- <goal>test-compile</goal> --> </goals> </execution> </executions> </plugin> </plugins> </build>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このプラグインの構成パラメーターについては説明しません。テストコンパイルの目標がコメントアウトされた理由のみを説明します。 プロジェクトをビルドすると、テストの起動段階でmavenがエラーでクラッシュしました。 インターネットを介して大騒ぎして、私はこの問題が既知であり、それを解決する方法があることを見ました。 ただし、テストアプリケーションにはテストがないため、最も簡単な解決策は、呼び出しをまったく無効にすることです（同時に、コンパイルの段階でプラグインを呼び出します）。



実際、これらはすべて私たちがしなければならなかった変更です。 アプリケーションを実行できます

 Aspect1 Aspect1 method1 Aspect1 Aspect1 method2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その瞬間、私はアスペクトに対する私の誤解の完全な深さを実感しました。 すべてのコードを数回再確認しました。 どこで何を間違えたかを頭の中でスクロールしようとしました。 しかし、なぜこのような結果が得られたのか理解していませんでした（正直なところ、クラスのメソッドを呼び出す前にアスペクトコードが2回呼び出される理由は明らかではありません）。



それにもかかわらず、最終的には、プロジェクトアセンブリの段階で受信したログを見て推測し、次の4行を見つけました。

 [INFO] Join point 'method-call(void com.example.AOPTest.MyServiceImpl.method1())' in Type 'com.example.AOPTest.AopTestApplication' (AopTestApplication.java:32) advised by before advice from 'com.example.AOPTest.MyAspect1' (MyAspect1.class:19(from MyAspect1.java)) [INFO] Join point 'method-call(void com.example.AOPTest.MyServiceImpl.method2())' in Type 'com.example.AOPTest.MyServiceImpl' (MyServiceImpl.java:12) advised by before advice from 'com.example.AOPTest.MyAspect1' (MyAspect1.class:19(from MyAspect1.java)) [INFO] Join point 'method-execution(void com.example.AOPTest.MyServiceImpl.method1())' in Type 'com.example.AOPTest.MyServiceImpl' (MyServiceImpl.java:10) advised by before advice from 'com.example.AOPTest.MyAspect1' (MyAspect1.class:19(from MyAspect1.java)) [INFO] Join point 'method-execution(void com.example.AOPTest.MyServiceImpl.method2())' in Type 'com.example.AOPTest.MyServiceImpl' (MyServiceImpl.java:17) advised by before advice from 'com.example.AOPTest.MyAspect1' (MyAspect1.class:19(from MyAspect1.java))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてが所定の位置に収まりました。 コードバインディングは、メソッドが実行された場所だけでなく、それらの呼び出しの場所でも発生しました。 実際のところ、Spring AOPには、実行場所でのみコードをリンクできるという制限があります。 この点でのAspectJの可能性ははるかに広いです。 不要なアスペクトコールの削除は非常に簡単です。たとえば、このようにアスペクトコードを変更できます。

 package com.example.AOPTest; import org.aspectj.lang.annotation.Aspect; import org.aspectj.lang.annotation.Before; import org.aspectj.lang.annotation.Pointcut; import org.springframework.stereotype.Component; @Aspect @Component public class MyAspect1 { @Pointcut("execution(public * *(..))") public void publicMethod() {} @Pointcut("@annotation(com.example.AOPTest.Annotation1)") public void annotated() {} @Before("annotated() && publicMethod()") public void printABit() { System.out.println("Aspect1"); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、私たちの結論は期待される形を取ります。

 Aspect1 method1 Aspect1 method2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さて、ここで私たちの正しい答えはまだ説明が必要であると言うことができます。少なくとも、冒頭で与えられたコードの予想される動作についてインタビューで質問された場合、明確にする価値があります。「コンパイル時バインディングを使用していませんか？実際、これはクラスコードにはまったく反映されていませんが、pom’nikを提供していません。



他に何に注意したいですか。 Spring AOPのドキュメントには、すべての操作が完了しているため、手首を軽く押すと（c）実行時バインディングからコンパイル時バインディングに切り替わることが記載されています。そして、これまで見てきたように、これは事実です。両方のケースのコードは同じでした（実際、行われた作業は、同じアノテーションのハンドラーを作成するだけではありませんでしたが、私はそこで止まりません。誰でもドキュメントを読んで感心することができます）。



このすべてについて、選択したバインディングオプションによっては、動作が異なる場合があります（予期しない場合もあります）。すでに説明したケースに加えて、AspectJコンパイラーはComponentアノテーションを必要としないことに注意してください。すなわち削除すると、Spring AOPはそのようなBeanを見つけられず、アスペクトは関係しません。同時に、AspectJコンパイルに切り替えると、このアスペクトは有効になりますが、アプリケーションの動作は予測できなくなります。

ロードタイムウィービング

前の段階の結果に触発されて、私はすでに精神的に手をこすっていました。結局、コンパイル中にコードをバインドするときに、実行時にリンクするための優れた動作が得られた場合、おそらく起動時にリンクする場合と同じ結果が期待されます（そうだと思います）。このテーマに関するドキュメントをざっと見てみると、SpringのLTWはすぐに使用できることがわかりました。必要なのは、構成クラスに別のアノテーション@EnableLoadTimeWeavingを追加するだけです。

 @SpringBootApplication @EnableLoadTimeWeaving public class AopTestApplication {
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そうそう。少し前に追加したpom'nikからaspectj-maven-pluginを削除することを忘れないでください。彼はもう必要ありません。



そして今、あなたは走ることができます...いいえ、実際にはもう一つのニュアンスがあります。

汎用Javaアプリケーション

When class instrumentation is required in environments that do not support or are not supported by the existing LoadTimeWeaver implementations, a JDK agent can be the only solution. For such cases, Spring provides InstrumentationLoadTimeWeaver, which requires a Spring-specific (but very general) VM agent,org.springframework.instrument-{version}.jar (previously named spring-agent.jar).

To use it, you must start the virtual machine with the Spring agent, by supplying the following JVM options:

-javaagent:/path/to/org.springframework.instrument-{version}.jar

このドキュメントには、ライブラリの名前であるspring-instrument- {version} .jarというわずかな不正確さがあります。そして、このライブラリは既にコンピューター上にあります（Spring BootとMavenのおかげです）。私の場合、このパスは次のようになります。c：\ Users \ {MyUserName} .. M2 \ repository \ org \ springframework \ spring-instrument \ 5.0.2.RELEASE \ spring-instrument-5.0.2.RELEASE.jar。私のように、開発にSTSを使用する場合は、次の手順に従ってください。 「実行」>「実行構成」メニューを開きます...そこにSpring Boot Appがあり、その中にアプリケーションの起動構成があります。 [引数]タブを開きます。 VM arguments：フィールドに-javaagentパラメーターを追加します：c：\ Users \\ {MyUserName} \。M2 \ repository \ org \ springframework \ spring-instrument \ 5.0.2.RELEASE \ spring-instrument-5.0.2.RELEASE.jar。そして今、私たちは起動します。

 Aspect1 method1 method2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さて、再び。結果を期待したわけではありません。 LTWを接続するのはまだ簡単ではないかもしれませんが、何か他の場所を設定する必要があるかもしれません。繰り返しますが、設定が機能することを確認し、デバッグ中にアプリケーションを起動し、実行されるコードを確認する最も簡単な方法です。上記のドキュメントのスニペットは、この場合、クラスInstrumentationLoadTimeWeaverを使用する必要があることを示しています。また、Beanを作成する段階で確実に呼び出されるメソッドがあります。

 public void addTransformer(ClassFileTransformer transformer)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これがブレークポイントを置く場所です。



開始...停止... DefaultAopProxyFactory.createAopProxy（）。以前に設定したブレークポイントは、JDK対CGLibがソートされていたときに機能しました。再び開始しますが、今回は予想したとおりに停止します。間違いなく残っています。

さて、この場合、Spring AOPは先ほど見たものと同じプロキシオブジェクトをすべて作成します。唯一の違いは、バインディングが実行段階ではなく、クラスのロード段階で行われることです。このプロセスの詳細については、コードで尋ねます。

おわりに

まあ、私たちの正しい答えは、予約はあるものの、確かに正しいようです（「コンパイル時の織り方とAspectJ」の章を参照）。



動作は、選択されたプロキシメカニズム（JDKまたはCGLib）に依存しますか？フレームワークは、内部にあるものが結果に影響を与えないように書かれています。また、LTW接続でさえ、何らかの形で影響することはありません。また、調査した例のフレームワークでは、これらの違いは見られませんでした。それでも、ドキュメントには違いがあるという言及があります。 JDK動的プロキシは、パブリックメソッドのみにオーバーラップできます。 CGLibプロキシ-パブリックに加えて、保護されたメソッドおよびパッケージから見える。したがって、ポイントカットに「パブリックメソッドのみ」の制限を明示的に指定しなかった場合、予期しない動作が発生する可能性があります。疑わしい場合は、CGLibを使用してプロキシオブジェクトを生成することができます（Springの最近のバージョンでは、これは既に行われているようです）。



Spring AOPはプロキシベースのフレームワークです。これは、アスペクトの範囲内にあるビンのいずれかにプロキシオブジェクトが常に作成されることを意味します。そして、あるクラスメソッドから別のクラスメソッドへの呼び出しがSpring AOPによってインターセプトできない瞬間は、開発者の間違いや欠陥ではなく、フレームワーク実装の基礎となるパターンの機能です。一方、検討中のケースでアスペクトコードを確実に実行する必要がある場合は、この事実を考慮してコードを記述し、呼び出しがプロキシオブジェクトを通過するようにする必要があります。ドキュメントにはこれを行う方法の例がありますが、それでも推奨ソリューションではないことが直接書かれています。別のオプションは、サービスをそれ自体に「注入」することです。 Springの最近のバージョンでは、このソリューションは機能します。

 @Service public class MyServiceImpl{ @Autowired private MyServiceImpl myService; @Annotation1 public void method1() { System.out.println("method1"); myService.method2(); } @Annotation1 public void method2() { System.out.println("method2"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

確かに、このオプションはスコープが「シングルトン」に等しいビンにのみ適用できます。スコープを「プロトタイプ」に変更すると、サービスをそれ自体に注入しようとするため、アプリケーションを起動できなくなります。このようになります

 *************************** APPLICATION FAILED TO START *************************** Description: The dependencies of some of the beans in the application context form a cycle: aopTestApplication (field private com.example.AOPTest.MyServiceImpl com.example.AOPTest.AopTestApplication.myService) ┌─────┐ | myServiceImpl (field private com.example.AOPTest.MyServiceImpl com.example.AOPTest.MyServiceImpl.myService) └─────┘
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

他に注目したいのは、Spring AOPを使用する際に伴うオーバーヘッドです。プロキシオブジェクトは、アスペクトの範囲内のビンのいずれかに常に作成されることを繰り返します。さらに、ビンのインスタンスが正確に作成されます。この例では、シングルトンBeanをそれぞれ考慮し、1つのプロキシオブジェクトのみが作成されました。プロトタイプを使用します。プロキシオブジェクトの数は、展開の数に対応します。プロキシオブジェクト自体は、ターゲットオブジェクトのメソッドを呼び出しませんが、これを行うインターセプターのチェーンが含まれています。ターゲットオブジェクトの各特定のメソッドがアスペクトの影響を受けるかどうかに関係なく、その呼び出しはプロキシオブジェクトを通過します。さらに、これに加えて、アスペクトクラスの少なくとも1つのインスタンスが作成されます（この例では、インスタンスは1つだけです。しかし、これは制御できます）。

あとがき

認知的不協和の感覚は私を決して去らなかった。この例のトランザクションに関する何かはまだ間違っています。彼のコードを複製します。

 public class MyServiceImpl { @Transactional public void method1() { //do something method2(); } @Transactional (propagation=Propagation.REQUIRES_NEW) public void method2() { //do something } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いいえ、理解しているようです。そして、それはAOPだけではなく、それほど多くありません。1つのトランザクションの途中で別のトランザクションを作成する必要がある理由は明らかではありません（元々この結果を正確に取得することを意図していたという事実に基づきます）。



必要なときに誰かが実際のプロジェクトの例を挙げることができれば、コメントでこれを見てくれて感謝しています。



ここには問題のみが表示されます。