Shulou(Shulou.com)06/03 Report--

This article will explain in detail the differences between @ within and @ target in Spring. The editor thinks it is very practical, so I share it with you for reference. I hope you can get something after reading this article.

When @ within is used in a project, there are some problems that can be solved using @ target, but some new problems arise, so this article explores some of the differences between using @ within and @ target in spring.

Background

There is a function of dynamically switching data sources in the project, which is implemented in aspects and based on annotations, but the methods of the parent class can switch data sources. If a class directly inherits this class and calls this subclass, this subclass cannot switch data sources unless the subclass overrides the methods of the parent class.

Simulation project example

Annotation definition: @ Target ({ElementType.METHOD, ElementType.TYPE}) @ Retention (RetentionPolicy.RUNTIME) @ Inherited@Documentedpublic @ interface MyAnnotation {String value () default "me";} aspect definition: @ Order (- 1) @ Aspect@Componentpublic class MyAspect {@ Before ("@ within (myAnnotation)") public void switchDataSource (JoinPoint point, MyAnnotation myAnnotation) {System.out.println ("before, myAnnotation.value:" + myAnnotation.value ()) }} parent Bean:@MyAnnotation ("father") public class Father {public void hello () {System.out.println ("father.hello ()");} public void hello2 () {System.out.println ("father.hello2 ()");}} subclass Bean:@MyAnnotation ("son") public class Son extends Father {@ Override public void hello () {System.out.println ("son.hello ()") }} configuration class: @ Configuration@EnableAspectJAutoProxy (exposeProxy = true) public class Config {@ Bean public Father father () {return new Father ();} @ Bean public Son son () {return new Son ();} Test class: public class Main {public static void main (String [] args) {AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext (Config.class, MyAspect.class) Father father = context.getBean ("father", Father.class); father.hello (); father.hello2 (); Son son = context.getBean (Son.class); son.hello (); son.hello2 ();}}

We define an @ Before notification. The method parameters have point and myAnnotation, and the method outputs the value of myAnnotation.value.

Here is the output:

Before, myAnnotation.value: father

Father.hello ()

Before, myAnnotation.value: father

Father.hello2 ()

Before, myAnnotation.value: son

Son.hello ()

Before, myAnnotation.value: father

Father.hello2 ()

From the above output, we can see that the Son class overrides the hello method, the output value of myAnnotation.value is that the son,hello2 method is not overridden, and the output value of myAnnotation.value is father

Depending on the requirement, we definitely want to call all the methods of the Son class and want the output value of myAnnotation.value to be son, so we need to override all the public methods of the parent class

Is there any way to achieve the same effect without rewriting these methods? the answer is yes.

Look at the difference between using @ within and @ target

Let's annotate and remove annotations on the parent and subclasses respectively. Let's take a look at the corresponding results.

@ within

There are no comments for the parent class and comments for the subclass:

Father.hello () father.hello2 () before, myAnnotation.value: sonson.hello () father.hello2 ()

The parent class has annotations, and the subclasses have no comments:

Before, myAnnotation.value: fatherfather.hello () before, myAnnotation.value: fatherfather.hello2 () before, myAnnotation.value: fatherson.hello () before, myAnnotation.value: fatherfather.hello2 ()

The parent class has annotations and the subclasses have annotations (actually the result of the above example):

Before, myAnnotation.value: fatherfather.hello () before, myAnnotation.value: fatherfather.hello2 () before, myAnnotation.value: sonson.hello () before, myAnnotation.value: fatherfather.hello2 ()

@ target

Change the section code to the following:

Order (- 1) @ Aspect@Componentpublic class MyAspect {@ Before ("@ target (myAnnotation)") public void switchDataSource (JoinPoint point, MyAnnotation myAnnotation) {System.out.println ("before, myAnnotation.value:" + myAnnotation.value ());}}

Let's take a look at the test results:

There are no comments for the parent class and comments for the subclass:

Father.hello () father.hello2 () before, myAnnotation.value: sonson.hello () before, myAnnotation.value: sonfather.hello2 ()

The parent class has annotations, and the subclasses have no comments:

Before, myAnnotation.value: fatherfather.hello () before, myAnnotation.value: fatherfather.hello2 () son.hello () father.hello2

The parent class has annotations, and the subclasses have annotations

Before, myAnnotation.value: fatherfather.hello () before, myAnnotation.value: fatherfather.hello2 () before, myAnnotation.value: sonson.hello () before, myAnnotation.value: sonfather.hello2 ()

We sum up a set of rules from the above:

The myAnnotation parameter of the @ within:@Before notification method refers to the comment on the class in which the method is called, that is, the class on which the method is defined

The myAnnotation parameter of the @ target:@Before notification method refers to the comments on the class to which the method is called when it is run

Finally, let's summarize the difference between @ within and @ target's actual annotations if both parent and subclasses are marked with annotations.

@ within@target

Parent class method parent class annotation parent class annotation subclass does not override method parent class annotation subclass rewrite method subclass annotation subclass annotation

@ target looks reasonable

From the above analysis, we can see that its practical @ target is more in line with the result we want. Add a comment on a class, and when you intercept, you will get the annotation above the class, which has nothing to do with the parent class at all.

But at this time, we will encounter a problem, that is, unrelated classes will be born from the proxy class.

Examples are as follows:

Public class NormalBean {public void hello () {}} @ Configuration@EnableAspectJAutoProxy (exposeProxy = true) public class Config {@ Bean public Father father () {return new Father ();} @ Bean public Son son () {return new Son ();} @ Bean public NormalBean normalBean () {return new NormalBean () }} public class Main {public static void main (String [] args) {AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext (Config.class, MyAspect.class); Father father = context.getBean ("father", Father.class); father.hello (); father.hello2 (); Son son = context.getBean (Son.class); son.hello (); son.hello2 () NormalBean normalBean = context.getBean (NormalBean.class); System.out.println (normalBean.getClass ());}}

Output:

Class cn.eagleli.spring.aop.demo.NormalBean$$EnhancerBySpringCGLIB$$eebc2a39

You can see that NormalBean didn't do anything himself, but was represented.

Let's change @ target to @ within:

Class cn.eagleli.spring.aop.demo.NormalBean

You can see that when using @ within, irrelevant classes are not proxied

Let's see why.

Take a look at the wrapIfNecessary method breakpoint in the AbstractAutoProxyCreator class to see what happens:

@ within

@ target

From the picture above, we can understand why @ target generates proxy classes.

Let's take a closer look:

@ within will go as follows:

Public class ExactAnnotationTypePattern extends AnnotationTypePattern {@ Override public FuzzyBoolean matches (AnnotatedElement annotated, ResolvedType [] parameterAnnotations) {/ /. }}

I didn't study it in depth, which roughly means that as long as this class or its ancestors have this annotation, that is, the match is successful.

@ target will go as follows:

Public class ThisOrTargetAnnotationPointcut extends NameBindingPointcut {@ Override protected FuzzyBoolean matchInternal (Shadow shadow) {if (! couldMatch (shadow)) {return FuzzyBoolean.NO;} ResolvedType toMatchAgainst = (isThis? Shadow.getThisType (): shadow.getTargetType (). AlwaysTrue (shadow.getIWorld ()); annotationTypePattern.resolve (shadow.getIWorld ()); if (annotationTypePattern.matchesRuntimeType (toMatchAgainst). AlwaysTrue ()) {return FuzzyBoolean.YES;} else {/ / a subtype may match at runtime return FuzzyBoolean.MAYBE } public class AspectJExpressionPointcut extends AbstractExpressionPointcut implements ClassFilter, IntroductionAwareMethodMatcher, BeanFactoryAware {@ Override public boolean matches (Method method, Class targetClass, boolean hasIntroductions) {obtainPointcut_Expression (); ShadowMatch shadowMatch = getTargetShadowMatch (method, targetClass) / / Special handling for this, target, @ this, @ target, @ annotation / / in Spring-we can optimize since we know we have exactly this class, / / and there will never be matching subclass at runtime. If (shadowMatch.alwaysMatches ()) {return true;} else if (shadowMatch.neverMatches ()) {return false } else {/ / the maybe case if (hasIntroductions) {return true } / / A match test returned maybe-if there are any subtype sensitive variables / / involved in the test (this, target, at_this, at_target, at_annotation) then / / we say this is nota match as in Spring there will never be a different / / runtime subtype. RuntimeTestWalker walker = getRuntimeTestWalker (shadowMatch); return (! walker.testsSubtypeSensitiveVars () | | walker.testTargetInstanceOfResidue (targetClass)); / / true}} will be returned here

I didn't study it deeply, which roughly means that if there is a match, it will return YES, otherwise it will return MAYBE. The matching logic is the same as @ within

So all unrelated classes will be the result of a MAYBE, which will cause unrelated classes to eventually generate proxy classes.

Inform why the values of the annotation parameters in the method are not the same

After debugging, it is finally obtained here:

Public final class ReflectionVar extends Var {static final int THIS_VAR = 0; static final int TARGET_VAR = 1; static final int ARGS_VAR = 2; static final int AT_THIS_VAR = 3; static final int AT_TARGET_VAR = 4; static final int AT_ARGS_VAR = 5; static final int AT_WITHIN_VAR = 6; static final int AT_WITHINCODE_VAR = 7 Static final int AT_ANNOTATION_VAR = 8 Public Object getBindingAtJoinPoint (Object thisObject, Object targetObject, Object [] args, Member subject, Member withinCode Class withinType) {switch (this.varType) {case THIS_VAR: return thisObject Case TARGET_VAR: return targetObject; case ARGS_VAR: if (this.argsIndex > (args.length-1)) return null; return args [argsIndex] Case AT_THIS_VAR: if (annotationFinder! = null) {return annotationFinder.getAnnotation (getType (), thisObject);} else return null Case AT_TARGET_VAR: if (annotationFinder! = null) {return annotationFinder.getAnnotation (getType (), targetObject);} else return null; case AT_ARGS_VAR: if (this.argsIndex > (args.length-1)) return null If (annotationFinder! = null) {return annotationFinder.getAnnotation (getType (), args [argsIndex]);} else return null Case AT_WITHIN_VAR: if (annotationFinder! = null) {return annotationFinder.getAnnotationFromClass (getType (), withinType);} else return null Case AT_WITHINCODE_VAR: if (annotationFinder! = null) {return annotationFinder.getAnnotationFromMember (getType (), withinCode);} else return null Case AT_ANNOTATION_VAR: if (annotationFinder! = null) {return annotationFinder.getAnnotationFromMember (getType (), subject);} else return null;} return null;}}

@ within:

Case AT_WITHIN_VAR: if (annotationFinder! = null) {return annotationFinder.getAnnotationFromClass (getType (), withinType);} else return null

WithinType traced it as follows:

Public class PointcutExpressionImpl implements PointcutExpression {private ShadowMatch matchesExecution (Member aMember) {Shadow s = ReflectionShadow.makeExecutionShadow (world, aMember, this.matchContext); ShadowMatchImpl sm = getShadowMatch (s); sm.setSubject (aMember); sm.setWithinCode (null); sm.setWithinType (aMember.getDeclaringClass ()); / / withinType return sm is set here }} public abstract class AopUtils {public static boolean canApply (Pointcut pc, Class targetClass, boolean hasIntroductions) {Assert.notNull (pc, "Pointcut must not be null"); if (! pc.getClassFilter (). Matches (targetClass)) {return false;} MethodMatcher methodMatcher = pc.getMethodMatcher () If (methodMatcher = = MethodMatcher.TRUE) {/ / No need to iterate the methods if we're matching any method anyway... Return true;} IntroductionAwareMethodMatcher introductionAwareMethodMatcher = null; if (methodMatcher instanceof IntroductionAwareMethodMatcher) {introductionAwareMethodMatcher = (IntroductionAwareMethodMatcher) methodMatcher;} Set

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.