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