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<mi...@xup.nl> 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@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users