[
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
|
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
>
>
> 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
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
