Community
Participate
Working Groups
When I compile my pertypewithin aspect into a jar and then build another project with it on the classpath & aspectpath, I find that the woven project has references to private around advice methods in it. Here's the stack trace I'm seeing: java.lang.IllegalAccessError: tried to access method glassbox.util.logging.api.L ogManagement.ajc$around$glassbox_util_logging_api_LogManagement$9$ff3f21f8_aroun dBody17$advice(Lglassbox/util/logging/api/LogManagement;Ljava/lang/String;Lorg/a spectj/runtime/internal/AroundClosure;Lorg/aspectj/lang/JoinPoint;Lglassbox/util /logging/api/LogManagement$HandleUninitialized;Lorg/aspectj/runtime/internal/Aro undClosure;Lorg/aspectj/lang/JoinPoint;)Ljava/lang/Object; from class glassbox.c onfig.GlassboxInitializationImpl at glassbox.config.GlassboxInitializationImpl.logInfo_aroundBody1$advice (GlassboxInitializationImpl.java:101) at glassbox.config.GlassboxInitializationImpl.startUp(GlassboxInitializa tionImpl.java:39) at glassbox.config.GlassboxInitializer.ajc$before$glassbox_config_Glassb oxInitializer$1$e7e1d0be_aroundBody2(GlassboxInitializer.aj:28) I tested this out using the standard 1.5.0 build AspectJ compiler & ant task inside ant. I'm attaching the separately compiled output from the 2 offending classes, which shows the issue with javap -c -private: LogManagement.class (from the library aspect) GlassboxInitializationImpl.class (from the jar being build separately with classpath & aspectpath entries) I can sometimes see the problem with 2 simple projects in AJDT intermittently, but it seems to be unstable, as if some other random factor in the build changes the result (so it's been quite hard to create a simpler version of the problem!).
Created attachment 33448 [details] Woven file that references private method
Created attachment 33449 [details] The pertypewithin aspect The basic idiom of this aspect is the following: public aspect LogManagement pertypewithin(LogOwner+) { declare parents: ... implements LogOwner; after() returning: staticinitialization(*) { managedClass = thisJoinPointStaticPart.getSignature().getDeclaringType(); initialize(); } private void initialize() { if (factory != null) { logger = getLogger(managedClass); ... } public void LogOwner.logInfo(String message) { } void around(String message) : call(void LogOwner.logInfo(String)) && args(message) { logger.info(message); } }
From javap -private -c -l GlassboxInitializationImpl ... 35: invokestatic #171; //Method glassbox/util/logging/api/LogManagement.a jc$around$glassbox_util_logging_api_LogManagement$9$ff3f21f8_aroundBody17$advice :(Lglassbox/util/logging/api/LogManagement;Ljava/lang/String;Lorg/aspectj/runtim e/internal/AroundClosure;Lorg/aspectj/lang/JoinPoint;Lglassbox/util/logging/api/ LogManagement$HandleUninitialized;Lorg/aspectj/runtime/internal/AroundClosure;Lo rg/aspectj/lang/JoinPoint;)Ljava/lang/Object; From javap -private -c -l LogManagement ... private static final java.lang.Object ajc$around$glassbox_util_logging_api_LogMa nagement$9$ff3f21f8_aroundBody17$advice(glassbox.util.logging.api.LogManagement, java.lang.String, org.aspectj.runtime.internal.AroundClosure, org.aspectj.lang. JoinPoint, glassbox.util.logging.api.LogManagement$HandleUninitialized, org.aspe ctj.runtime.internal.AroundClosure, org.aspectj.lang.JoinPoint); Code: 0: aload 5 2: astore 8 4: aload_0 5: aload_1 6: aload_2 7: aload_3 8: invokestatic #453; //Method ajc$around$glassbox_util_logging_api_LogM anagement$9$ff3f21f8_aroundBody16:(Lglassbox/util/logging/api/LogManagement;Ljav a/lang/String;Lorg/aspectj/runtime/internal/AroundClosure;Lorg/aspectj/lang/Join Point;)V 11: aconst_null 12: areturn 13: pop ...
If I build with -Xnoline end-to-end, this error goes away (thanks for suggesting I test that Andy!). The code that is being generated in this case is so ugly/inefficient that I'm looking more closely to see if there's a reasonable alternative to the approach I've been using to access the field from the pertypewithin aspect... which hopefully will also work around this issue.
Ron ... I get an error very similar to this if I mess about with the typemap strategy for looking after types. Was this bug seen on 1.5.0 final - on HEAD or on a patched HEAD?
Each one. I was able to reproduce it with 1.5.0 final.
take a look if time...
interestingly this is exactly the problem I saw when mixing annotation style and code style aspects in a hierarchy. I suspect this might be fixed now because of what I did for the other bug.
suspected fixed after making those other changes.
