Re: [aspectj-users] Suspected stale cache use with WeavingURLClassLoader
Hi, Eclipse was using the AspectJ compiler when building, so all weaving was coming from the compiler and not the load-time weaver. Turning off aspectJ Capability for the project fixed the failure-to-update problem for affected classes but now I've lost all code help which comes from aspectJ capability and code depending on the aspects gives compiler errors. Specifically, the field which would not update without a Project-Clean... was: public static final int SOME_CONSTANT=80; ...changing it to, for example, 40 would not reflect in the program unless 'Clean...' was invoked in Eclipse, or if I changed a method in that class or if I turned off AspectJ support completely for the project. It's like it is failing to recognize that a class has been changed to re-compile/re-weave said class. Turning off AspectJ capability should revert you to the standard Java compiler, which does a great job on dependency analysis (so I presume changing constants works in that case?). Commenting on your questions: There is an open issue for updates to constants not causing the correct incremental compilation behaviour: https://bugs.eclipse.org/bugs/show_bug.cgi?id=295819 - maybe you are hitting this. Yes, turning off AspectJ you will lose notifications in the editor that show what was woven with what. There is an old old outstanding issue for this too: https://bugs.eclipse.org/bugs/show_bug.cgi?id=265029 which we never seem to get around to... The load-time weaver wasn't doing anything at all as far as weaving goes. This made some sense because the .aj files were not in the bin/ directory of the project however copying them to their respective place in the bin/ directory did not result in them being woven in. This would make sense if the weaver behaves like most classloaders: Doesn't actively take itinerary of the classes/aspects in a classpath, rather simply tries to load them individually when asked to... but that raises the question: How are aspects explicitly specified to the WeavingURLClassLoader? The JavaDoc shows that the WeavingURLClassLoader accepts arrays of URLs for classes and aspects. Is it safe to assume that these are following the java convention where I give URLs to directories at the base of the classpath for my files (and/or the JARs which do the same) and the aspect URLs are following that convention as well? But then if an .aj file's name had zero resemblance to any java classes, there would be no way for the load-time weaver to find it without actively scanning the classpath. (how would that work over the web without jars?) There doesn't seem to be much on this subject. My attempts to find answers in the archive have gotten me this: http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg09098.html There was this... http://osdir.com/ml/java-aop-aspectj-general/2008-04/msg00099.html ...to clarify, does that JVM option simply use the existing classpath to find the .aj files? Does it scan for them in the classpath? Ultimately, what I want to do is have an application as a standalone runnable .JAR in a =Java6 environment in an unknown operation system, where 3rd party developers could release add-ons as .JARs (containing classes and their binding aspects) which could be placed in the same directory as my application .JAR and they would automatically be found and integrated when the application loads, with no configuration files or scripts. The loadtime weaver (well, the weaver whenever it runs - compile-time, post compile-time or loadtime) loads up compiled aspects, it won't load up source files (.aj files). This means you need to compile with to .class files with ajc at some point before you use them. They can be compiled 'standalone' - they don't need to be compiled with the code they are targetting. You may see a warning about 'advice did not apply' but that doesn't stop the aspect being compiled for later use. If you are using the javaagent then an aop.xml file is used to control the loadtime weaver and specifies the names of the aspects (which can then be found on the classpath). In the WeavingURLClassloader case you need to pass in the aspectpath (as you know) which should contain the .class files for compiled aspects, which will then be applied to other classes loaded through the same loader. So: Is it safe to assume that these are following the java convention where I give URLs to directories at the base of the classpath for my files (and/or the JARs which do the same) and the aspect URLs are following that convention as well? Yes, same convention. But they must be compiled aspects, not source aspects. I'm not 100% we will scan inside of jars if they are placed on the aspectpath - I only recall using it recently with directories containing the compiled aspects. Would the agent usage be easier for you? Just add the agent option when starting the VM and ensure a configuration aop.xml file can be found, no need to manage WeavingURLClassLoaders -
Re: [aspectj-users] Suspected stale cache use with WeavingURLClassLoader
FOLLOW-UP: It is turning out that my problem is actually two problems: 1st: Eclipse was using the AspectJ compiler when building, so all weaving was coming from the compiler and not the load-time weaver. Turning off aspectJ Capability for the project fixed the failure-to-update problem for affected classes but now I've lost all code help which comes from aspectJ capability and code depending on the aspects gives compiler errors. Specifically, the field which would not update without a Project-Clean... was: public static final int SOME_CONSTANT=80; ...changing it to, for example, 40 would not reflect in the program unless 'Clean...' was invoked in Eclipse, or if I changed a method in that class or if I turned off AspectJ support completely for the project. It's like it is failing to recognize that a class has been changed to re-compile/re-weave said class. Is there a way to keep AspectJ support without the actual output classes being woven? 2nd: The load-time weaver wasn't doing anything at all as far as weaving goes. This made some sense because the .aj files were not in the bin/ directory of the project however copying them to their respective place in the bin/ directory did not result in them being woven in. This would make sense if the weaver behaves like most classloaders: Doesn't actively take itinerary of the classes/aspects in a classpath, rather simply tries to load them individually when asked to... but that raises the question: How are aspects explicitly specified to the WeavingURLClassLoader? The JavaDoc shows that the WeavingURLClassLoader accepts arrays of URLs for classes and aspects. Is it safe to assume that these are following the java convention where I give URLs to directories at the base of the classpath for my files (and/or the JARs which do the same) and the aspect URLs are following that convention as well? But then if an .aj file's name had zero resemblance to any java classes, there would be no way for the load-time weaver to find it without actively scanning the classpath. (how would that work over the web without jars?) There doesn't seem to be much on this subject. My attempts to find answers in the archive have gotten me this: http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg09098.html There was this... http://osdir.com/ml/java-aop-aspectj-general/2008-04/msg00099.html ...to clarify, does that JVM option simply use the existing classpath to find the .aj files? Does it scan for them in the classpath? Ultimately, what I want to do is have an application as a standalone runnable .JAR in a =Java6 environment in an unknown operation system, where 3rd party developers could release add-ons as .JARs (containing classes and their binding aspects) which could be placed in the same directory as my application .JAR and they would automatically be found and integrated when the application loads, with no configuration files or scripts. If no reply, I will keep combing the AJ source code and see where it goes from there. On Sat, Nov 3, 2012 at 11:41 PM, Chuck Ritola cjrit...@gmail.com wrote: Classes which are updated in certain ways (code changed, recompiled in Eclipse) which are then affected by an aspect file at load-time, do not reflect those changes. My project is in Eclipse, using a WeavingURLClassLoader at the very beginning of execution for fleshed-out reasons out of scope of the question. With only classes affected by an aspect: If a public static final *** value is changed in java, compiled, and run, that change will not be reflected from within the WeavingURLClassLoader. However If that public static final *** value is read from outside the weaver, the correct (newest) value is returned. If a method is added/removed/changed, everything for that class becomes up-to-date. This is a simple run-stop-code-compile-run setup, not an always-running server or any other exotic change-while-running setup. Rebooting does not fix the issue. Running Eclipse-Project-Clean... after every code change to those affected classes *does* fix the issue. If there is a cache location for the WeavingURLClassLoader, where is it-and is there a feature to clear it every time at program start or should I have my program manually delete the stale files? Thanks for reading. ___ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users
[aspectj-users] Suspected stale cache use with WeavingURLClassLoader
Classes which are updated in certain ways (code changed, recompiled in Eclipse) which are then affected by an aspect file at load-time, do not reflect those changes. My project is in Eclipse, using a WeavingURLClassLoader at the very beginning of execution for fleshed-out reasons out of scope of the question. With only classes affected by an aspect: If a public static final *** value is changed in java, compiled, and run, that change will not be reflected from within the WeavingURLClassLoader. However If that public static final *** value is read from outside the weaver, the correct (newest) value is returned. If a method is added/removed/changed, everything for that class becomes up-to-date. This is a simple run-stop-code-compile-run setup, not an always-running server or any other exotic change-while-running setup. Rebooting does not fix the issue. Running Eclipse-Project-Clean... after every code change to those affected classes *does* fix the issue. If there is a cache location for the WeavingURLClassLoader, where is it-and is there a feature to clear it every time at program start or should I have my program manually delete the stale files? Thanks for reading. ___ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users
