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 
Thanks Andy,

Got that part solved now :-)
Not only the return type needed to be fully qualified, but the arguments as well. With these changes 'mvn clean install' runs without problems. 

Unfortunately 'mvn site' still has a problem:

[INFO] Compiler errors:
abort ABORT -- (RuntimeException) Problem processing attributes in <my path>RequestProcessorMonitor.class Problem processing attributes in <my path>\aspects\RequestProcessorMonitor.class java.lang.RuntimeException: Problem processing attributes in <my path>\aspects\RequestProcessorMonitor.class at org.aspectj.weaver.bcel.BcelObjectType.ensureAspectJAttributesUnpacked(BcelObjectType.java:383) 
...
Caused by: org.aspectj.weaver.BCException: malformed org.aspectj.weaver.Pointcut Declaration attribute (length:296)org.aspectj.weaver.BCException: Bad type signature logObject 
when batch building BuildConfig[null] #Files=20 AopXmls=#0
when batch building BuildConfig[null] #Files=20 AopXmls=#0
        at org.aspectj.weaver.AjAttribute.read(AjAttribute.java:137)
at org.aspectj.weaver.bcel.Utility.readAjAttributes(Utility.java:101) 
...

Regards,

Minto

--
ir. ing. Minto van der Sluis
Xup BV

Mobiel: +31 (0) 626 014541


Op 15-2-2011 0:30, Andy Clement schreef:

Hi,

Yes, you will need to fully qualify all your types in your annotation
style pointcuts.  There is no difference I know of, for the kind of
pointcut you have, between annotation style and code style
representations.  Perhaps use wildcards to see if it is a type
reference that is causing you problems? (obviously it may match more,
but it may help you isolate what exactly is wrong).

Andy


On 14 February 2011 13:47, Minto van der sluis<minto@xxxxxx>  wrote:

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

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users


_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Back to the top