[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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.
