Community
Participate
Working Groups
Whenever I define a pointcut that uses the @target(com.sample.MyAnnotation), a VerifyError gets thrown when the class is loaded. This is via compile-time weaving, not load-time. The error doesn't get thrown if I convert the pointcut to use a target() instead of @target(). Stacktrace includes the message "Illegal type in constant pool". The class in question was part of the inpath -- so not sure if that's relevant or not. I'm compiling and executing on Sun's JDK 1.5.0_06. Currently, doing weaving using AspectJ "development build", but also got error on 1.5.3 and 1.5.4 (not sure of exact versions, e.g. RC1 or not, just downloaded from website). after(RequestContext context, DataBinder binder) returning : @target(MyAnnotation) && execution(void FormAction.doBind(RequestContext, DataBinder)) && args(context, binder) { .... }
I am trying to recreate this, but having trouble. Any idea what might be different between my scenario and yours? ----8<----- A.java package a.b.c; import java.lang.annotation.*; import org.aspectj.lang.annotation.*; @Retention(RetentionPolicy.RUNTIME) public @interface A {} ----8<----- ----8<----- Code.java package e; import java.lang.annotation.*; import org.aspectj.lang.annotation.*; public class Code { @a.b.c.A public void m() {} public static void main(String []argv) { new Code().m(); } } ----8<----- ----8<----- X.java package e; import java.lang.annotation.*; import org.aspectj.lang.annotation.*; import a.b.c.A; aspect X { after() returning: @target(a.b.c.A) && execution(* m(..)) { } } ----8<----- Compile the annotation and aspect: > ajc -d bin1 A.java X.java -1.5 /Users/aclement/bugs/X.java:8 [warning] advice defined in e.X has not been applied [Xlint:adviceDidNotMatch] Compile the Code applying the aspect from the inpath: > ajc Code.java -d bin2 -inpath bin1 -1.5 -showWeaveInfo Join point 'method-execution(void e.Code.m())' in Type 'e.Code' (Code.java:9) advised by afterReturning advice from 'e.X' (X.java:8) [with runtime test] Run it: > java e.Code and it runs OK. I am willing to believe there is a problem here because I've had similar ones in the past - sometimes to do with a type not correctly maintaining its package prefix when put into the constant pool for the class (that's why I tried my test source files in different packages).
Not heard back about the difference between my testcode and the failing scenario. Given that this was raised in January and we've had around 100 fixes go in since then (including numerous annotation style fixes) - I'm closing this, please reopen if it is still an issue for you.
