Community
Participate
Working Groups
When I enable JMX remote management on a JVM along with AspectJ load-time weaving (LTW), our Aspect doesn't appear to get woven in. This are the JVM arguments: -Dvisualvm.display.name=JdbcTimingAspectTest -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=1024 -javaagent:/jars/aspectjweaver.jar -Dorg.aspectj.weaver.loadtime.configuration=com/trgr/cobalt/infrastructure/instrumentation/aspects/timing/jdbc/jdbcmonitor.xml Note that if I don't enable JMX remote management (by remove the -Dcom.sun.management.jmxremote.* JVM arguments), the Aspect works fine.
Note that according to this post on StackOverflow.com: http://stackoverflow.com/questions/17784939/aspectj-ltw-not-working-with-jmx-remote A workaround is to add the following to the java arguments: -Xbootclasspath/p:libs/aspectjweaver-1.7.3.jar This workaround seems like it could lead to other issues. Could someone comment on whether or not this would be the recommended workaround until a bug fix is available?
The bug seems to be coming from this modification: https://github.com/eclipse/org.aspectj/commit/8a6608f4d5d1a2aa8aa49a0a38da66a54d53c917#L0R265 When JMX is enabled, the first classloader is not the same as the "myClassLoader" (AppClassLoader). Therefore this conditions does not have the proper adaptor: if(loader.equals(myClassLoader)){ adaptor = myClassLoaderAdpator; } Adding the condition "loader.equals(myClassLoader)" would probably work. I didn't have time to test this solution.
In theory running with the weaver on the bootclasspath should be ok. The weaver may have access to weaving more types but as long as your aspects are carefully targeting what they need to weave you shouldn't weave anything else by accident.
Sebastien, I'm interested in trying your proposed solution - but what is it? > if(loader.equals(myClassLoader)){ > adaptor = myClassLoaderAdpator; > } > > Adding the condition "loader.equals(myClassLoader)" would probably work. Did you mean add that condition? It is the same as the condition already there?
(In reply to comment #4) > Sebastien, I'm interested in trying your proposed solution - but what is it? > > > if(loader.equals(myClassLoader)){ > > adaptor = myClassLoaderAdpator; > > } > > > > Adding the condition "loader.equals(myClassLoader)" would probably work. > > Did you mean add that condition? It is the same as the condition already > there? Hi Andrew, I'm suggesting updating the condition: if(myClassLoaderAdpator == null){ myClassLoaderAdpator = adaptor; } to: if(myClassLoaderAdpator == null && loader.equals(myClassLoader)){ myClassLoaderAdpator = adaptor; } Basically, the code keeps a reference of its own classloader (myClassLoader) in order to keep a reference of its own adaptor. However it keeps the wrong reference if the first loaded class loader in this class is not its own (which seems to happen when JMX is activated).
> However it keeps the wrong > reference if the first loaded class loader in this class is not its own > (which seems to happen when JMX is activated). I mean it keeps the wrong adaptor reference. When it's time to weave the classloader that is kept in reference (myClassLoader) it uses the adaptor from this condition: if(loader.equals(myClassLoader)){ adaptor = myClassLoaderAdpator; } which is not the right one. Therefore the class loader is never weaved.
A dev build is available with Sebastiens proposed change in: http://www.eclipse.org/downloads/download.php?file=/tools/aspectj/dev/aspectj-DEVELOPMENT-20130828153000.jar
(In reply to Andrew Clement from comment #7) > A dev build is available with Sebastiens proposed change in: > > http://www.eclipse.org/downloads/download.php?file=/tools/aspectj/dev/ > aspectj-DEVELOPMENT-20130828153000.jar Andy, I just verified that this build fixes the issue. With the new JAR, my Aspect gets weaved in even when remote JMX management is enabled. Thanks Andy and Sebastien for helping to fix this. What are the next steps to get this into an official AspectJ build?
changes are now committed.
in 1.7.4
