Found the answer. Note that this is only for LTW (Load Time Weaving)
There are primarily 4 key components from a weaving perspective:
The target classes that you want to weave: All those that you want to Aspect on should be in the classpath. For a typical application, they will be in your applications WEB-INF/lib or WEB-INF/classes, so let them be there. No changes here.
AOP.xml: This is used by the weaver to discover the Aspect and Weaver configuration. This should also be available in the classpath. You can put this in a JAR in /lib folder, so that its configuration is available for all applications (EARs and WARs).
The Aspect class(es): If using annotations for Aspect class, then "it also needs to be weaved". AspectJ weaver adds some special methods (like aspectOf) to this class. Hence it must be available in the classpath. This can be part of the same JAR as for (2). If you've already compiled this using ajc (the aspectJ compiler), then it can be put in the bootclasspath also (but giving no real advantage over the lib folder).
Note: Since this class needs to be woven, it must be present in the tag in the AOP.xml, other than the list of classes/packages you want to Aspect on
The weaver itself (which is in aspectjweaver.jar): This should be available via java agent, so add the following line to the /bin/setDomainEnv.cmd
SET JAVA_OPTIONS=%JAVA_OPTIONS% -javaagent:%ASPECT_HOME%\lib\aspectjweaver.jar If using setDomainEnv.sh, you will need to do an EXPORT JAVA_OPTIONS also.
So, for LTW there is really no need of
- fiddling with the bootclasspath (as I was),
- aspectjrt.jar in any of the classpaths