Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Load time weaving with maven and surefire fails 
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<minto@xxxxxx>  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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Back to the top