Re: [aspectj-users] Load time weaving with maven and surefire fails

[Andy Clement <andrew.clement@xxxxxxxxx>]

>    main: compile time weaving of Aspect A (defined in main)
>    test: compile time weaving of Aspect A on test sources and load time weaving of Aspect B on the main sources.

And I presume the cobertura step runs just after the compile time
weave? So that when running in a maven compile, the secondary compile
that unpacks aspect A to weave it against the test sources will fail
to unpack it properly.

The options are quite limited it seems: don't cobertura instrument
Aspect A on the first compile.  If you need to instrument that type,
do it when the after the tests are built and ensure the ltw doesn't
try to unpack it when weaving aspect B through the use of overweaving.
 Sorry I don't have anything easier.

cheers
Andy


On 15 February 2011 14:17, Minto van der sluis <minto@xxxxxx> wrote:
> Hi Andy,
>
> The final error in both situations is the same, but the cause by is
> different ('Bad type signature' versus '... cannot be cast to ...' the
> previous time). However the actual cause might indeed be the same.
>
> I am quite sure this is not caused by AspectJ version incompatibility. First
> because I use the same version everywhere ( declared a aspectj.version
> property in my pom ). Second then probably the 'clean install' build would
> have failed as well. So you are probably right about cobertura
> instrumentation.
>
> Let met further explain my situation. Like most maven project I have 2 sets
> of sources in the same project 'main' and 'test'. Aspects are used in the
> following way:
>
>    main: compile time weaving of Aspect A (defined in main)
>    test: compile time weaving of Aspect A on test sources and load time
> weaving of Aspect B on the main sources.
>
> Looking more closely at the actual log I see that the error happened during
> 'aspectj:test-compile'. It looks like its got nothing to do with load time
> weaving, but is caused by compile time weaving using a cobertura
> instrumented aspect. Excluding aspect A from cobertura instrumentation
> solves the problem. However this leaves me with the following question:
>
> How to get code coverage for tested annotation based aspects?
>
> Regards,
>
> Minto
>
> --
> ir. ing. Minto van der Sluis
> Xup BV
>
> Mobiel: +31 (0) 626 014541
>
> Op 15-2-2011 17:10, Andy Clement schreef:
>>
>> So this is a different aspect?  The error looks the same: if something
>> has messed with the bytecode in-between it being compiled and being
>> seen by a weaver, this will happen.  I presume it will be corbertura
>> instrumentation again?  So looks like you need to tackle the issue of
>> either doing all your aspect compilation/weaving before or after
>> cobertura, but not some on either side of the cobertura step, or
>> ensuring cobertura doesn't attempt to modify your aspects.
>>
>> Or, as I initially said, it could be a mismatch in AspectJ versions -
>> but from what we've discussed it looks like it is the cobertura step
>> that is causing you headaches when combined with a late weaving step.
>>
>> Actually now I think about it, you *might* get further using the
>> overweaving option.  The default option for a secondary weave is
>> called reweaving, where for any woven type we revert to the original
>> bytecode then apply all the old aspects and new aspects together.  The
>> alternative mode if overweaving where we just apply the new aspects on
>> top of what was already there - this mode will probably avoid
>> attempting to deserialize(load) the old aspects.  Overweaving is
>> turned on via this Xset option: -Xset:overWeaving=true (in the aop.xml
>> for your ltw config)
>>
>> Andy
>>
>> On 14 February 2011 22:42, Minto van der sluis<minto@xxxxxx>  wrote:
>>>
>>> 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
>>>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>