Re: [aspectj-users] Suspected stale cache use with WeavingURLClassLoader

[Andy Clement <andrew.clement@xxxxxxxxx>]

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 -
http://www.eclipse.org/aspectj/doc/next/devguide/ltw-configuration.html

Hope some of that helps,

cheers,
Andy



> On Sat, Nov 3, 2012 at 11:41 PM, Chuck Ritola <cjritola@xxxxxxxxx> 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@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>