关于使用AspectJ执行策略

本文介绍了关于使用AspectJ执行策略的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我正在使用Aspectj来实施整个项目的政策.

I am using Aspectj for project-wide policy enforcement.

我现在要实现的一件事是，除了使用Guava的Preconditions.check*方法进行简单验证之外，任何设置方法中都应该没有逻辑.

One thing I am trying to implement now is that there should be no logic in any setter methods except simple validation with Guava's Preconditions.check* methods.

public pointcut withinSetter() : withincode(public void set*(*)); public pointcut inputValidation() : call(public void Preconditions.check*(*)); public pointcut setFieldValue() : set(* *); public pointcut entity() : within(com.mycompany.BaseEntity+); declare warning : entity() && withinSetter() && !setFieldValue() && !inputValidation(): "Please don't use Logic in Setters";

这可以按预期工作，对任何未设置的代码生成警告.但是，对于这样的构造，它会失败:

This works as expected, generating warnings for any non-setter code. However, it fails for constructs like this:

public void setFoo(final String newFoo) { Preconditions.checkNotNull(newFoo); // this is OK Preconditions.checkArgument( newFoo.matches("\\p{Alpha}{3}"), // this generates a warning // because String.matches() // is called "Foo must have exactly 3 characters!"); this.foo = newFoo; }

所以我要寻找的是一个允许任何代码的结构，只要它发生在Preconditions.check*调用的参数内即可.有这样的切入点吗?

So what I am looking for is a construct that would allow any code, as long as it happens inside the parameters to a Preconditions.check* call. Is there such a pointcut?

推荐答案

我知道这是一个老问题，但是我在寻找其他东西时偶然发现了它.

答案是否定的，因为在JVM字节码中没有诸如"check*调用内的逻辑"之类的东西.例如，newFoo.matches(..)在 之前被评估，结果被传递给Preconditions.checkArgument(..)，非常像这样:

The answer is no, because in JVM bytecode there is no such thing as "logic inside a check* call". For example, newFoo.matches(..) is evaluated before the result is passed to Preconditions.checkArgument(..), very much like this:

boolean match = newFoo.matches("\\p{Alpha}{3}"); Preconditions.checkArgument(match, "Foo must have exactly 3 characters!");

如果代码是这样编写的，那么您将发出警告，那么为什么不将相同的Java代码(可能导致相似或相同的字节代码)编写为嵌套调用呢? ;-)

If the code was written like this, you would issue a warning anway, so why not if the same Java code, possibly resulting in similar or identical byte code, is written as a nested call? ;-)

更新:我创建了一个小示例:

Update: I have created a little example:

public class Application { public static void main(String[] args) { String newFoo = "Scrum"; boolean match = newFoo.matches("\\p{Alpha}{3}"); checkArgument( match, "Foo must have exactly 3 characters!" ); checkArgument( newFoo.matches("\\p{Alpha}{3}"), "Foo must have exactly 3 characters!" ); } private static void checkArgument(boolean status, String errorMessage) { if (!status) System.out.println(errorMessage); } }

如果使用javap -c Application转储字节码，则会看到以下内容:

If you dump the byte code using javap -c Application you see this:

Compiled from "Application.java" public class Application extends java.lang.Object{ public Application(); Code: 0: aload_0 1: invokespecial #8; //Method java/lang/Object."<init>":()V 4: return public static void main(java.lang.String[]); Code: 0: ldc #16; //String Scrum 2: astore_1 3: aload_1 4: ldc #18; //String \p{Alpha}{3} 6: invokevirtual #20; //Method java/lang/String.matches:(Ljava/lang/String;)Z 9: istore_2 10: iload_2 11: ldc #26; //String Foo must have exactly 3 characters! 13: invokestatic #28; //Method checkArgument:(ZLjava/lang/String;)V 16: aload_1 17: ldc #18; //String \p{Alpha}{3} 19: invokevirtual #20; //Method java/lang/String.matches:(Ljava/lang/String;)Z 22: ldc #26; //String Foo must have exactly 3 characters! 24: invokestatic #28; //Method checkArgument:(ZLjava/lang/String;)V 27: return }

如您所见，转储中第3-13行和第16-24行的字节码相同，除了存储和重新加载布尔值.也许这说明了我之前说过的话.

As you can see, the byte code of lines 3-13 versus 16-24 in the dump is identical except for the storing and re-loading of the boolean value. Maybe this illustrates what I have said before.