Hi Andy,
Thanks for your reply.
Cause 2 applies to my situation. As you described I could fix this by
preventing cobertura instrumentation. This was achieved by adding the
following configuration to the cobertura plugin:
<configuration>
<instrumentation>
<ignores>
<ignore>org.aspectj.runtime.*</ignore>
</ignores>
<excludes>
<exclude>%my package%/aspects/*.class</exclude>
<exclude>**/*$AjcClosure*</exclude>
</excludes>
</instrumentation>
</configuration>
This time 'maven site' ran without problems. Unfortunately my was
excluded from instrumentation so did not show any test coverage either.
So I decided to switch to @AspectJ and use annotations instead.
Unfortunately this time I ran into a different problem.
Compilation and site output shows proper working of the aspect. But the
unittest for the aspect fails because this time the aspect was not
applied to the corresponding helper class. Test compilation shows the
following message:
[WARNING] advice defined in <my package>.RequestProcessorMonitor has not
been applied [Xlint:adviceDidNotMatch]
My annotation based pointcut currently looks like this:
@Pointcut( "execution(public TransactionResponseType
processRequest(TransactionRequestType)) && args(transaction)" )
void callProcessRequest(TransactionRequestType transaction) {};
I also tried it with a fully qualified TransactionResponseType but that
leads to the same results.
Am I missing something here? I can't figure out why the same annotation
based aspect is applied when compiling main sources but not for test
sources. And when I switch back to using not annotations it works for
both main and test sources.
Any clues?
regards,
Minto
--
ir. ing. Minto van der Sluis
Xup BV
Mobiel: +31 (0) 626 014541
Op 14-2-2011 17:42, Andy Clement schreef:
Hi,
There can be two main causes of this problem.
1) If you have used a more recent version of the weaver to build the
code than you use as your loadtime weaver (e.g. you use the latest
AJDT to build it which includes AspectJ 1.6.11, then weave it using an
old AspectJ 1.6.7 or something). Ideally try to keep the levels in
step. I don't think you've mentioned what versions of the weaver or
AJDT you are using.
2) If another bytecode modification tool is modifying the bytecode for
the aspect between AspectJ building it and the weaver trying to use
it, it can damage the structure and cause AspectJ to have problems
trying to decode some of the attributes. You mentioned a coverage
tool and many of those work by bytecode modification rather than
source modification - I would try to ensure that the coverage tool
isn't instrumenting your aspect, if you can. If you can't do that,
one option you have is to change your aspect to annotation style
rather than code style, and build it with javac - if it is built this
way it won't contain anything the secondary bytecode modification
could be damaging.
Andy
On 12 February 2011 14:00, Minto van der sluis<mi...@xup.nl> wrote:
[INFO] [aspectj:test-compile {execution: default}]
[ERROR] ABORT
12-feb-2011 22:41:00 org.aspectj.weaver.tools.Jdk14Trace info
INFO: Dumping to<my project>\.\ajcore.20110212.224100.428.txt
------------------------------------------------------------------------
[INFO] Compiler errors:
abort ABORT -- (RuntimeException) Problem processing attributes in<my
project\aspects\RequestProcessorMonitor.class
Problem processing attributes in<my
project>\aspects\RequestProcessorMonitor.class
java.lang.RuntimeException: Problem processing attributes in<my
project>\aspects\RequestProcessorMonitor.class
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users