Discussion:
[aspectj-users] Load time weaving with maven and surefire fails
Minto van der sluis
2011-02-12 21:33:37 UTC
Permalink
Hi folks,

Following the guidelines from the link below, I am using load time
weaving in for my unit test.

[1] http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg09286.html

Unfortunately this results in the following error message :-(

[INFO] Surefire report directory: <source-path>\target\surefire-reports
java.lang.NoClassDefFoundError: null
Caused by: java.lang.ClassNotFoundException: null
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
Could not find the main class: null. Program will exit.
Exception in thread "main"

Anyone a clue?

Let me explain what I am trying to achieve. I want to increase code
overage for my utility classes (private constructor). See also:

http://stackoverflow.com/questions/4520216/how-to-add-test-coverage-to-a-private-constructor

There are 2 straight forward ways to achieve this:
1) Add a testcase and use reflection instantiate the private constructor
(described in previouse link).
2) Add a static section to my utility class and instantiate the class
there, like:
static {
new MyClass();
}

The first is rejected because I need to do this for every utility class
and the test is just for the sake of increasing coverage, not for
testing functionality. The second one I reject because it polutes my
code for the sake of code coverage.

I came up

I came up with a solution which is more appealing to me. Creating an
Aspect to achieve the same thing as solution 2. However I do not like
this Aspect to be part of my actual code. So I decided to use load time
weaving during unit testing. This way the additional coverage only shows
up on test utility classes.

How did I do this. First of all, here's the actual aspect:

package <my aspect package>.aspects;

import java.lang.reflect.Constructor;
import java.lang.reflect.Modifier;

/**
* Special aspect to increase code coverage on classes with private
* constructors.
*
* @author Minto van der Sluis
*/
public aspect PrivateConstructorCoverage {

// Joinpoint for static initialization blocks of all
classes in the
// populators package.
pointcut staticInit() : staticinitialization(<my utility
class package>.populators..*);

before(): staticInit() {
// Determine the class on which this advice is
currently working.
Class<?> clazz =
thisJoinPoint.getSignature().getDeclaringType();
Constructor<?> constructor = null;
try {
// Use reflection to get to the default constructor.
constructor = clazz.getDeclaredConstructor();
} catch( NoSuchMethodException e ) {
System.out.println( "Missing default constructor
for: " + clazz.getName() );
}

// Only instantiate the class if a private default
constructor exists.
if ( constructor != null && Modifier.isPrivate(
constructor.getModifiers() )) {
constructor.setAccessible(true);
try {
System.out.println( "Increasing coverage by
calling: new " + clazz.getSimpleName() + "()" );
constructor.newInstance();
} catch (Exception e) {
// Instantiating failed
System.out.println( "Instantiation failed due
to: " + e.getMessage() );
}
}
}
}

This aspect is included in 'src/test/java'. For the sake of load time
weaving I added the following aop.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE aspectj PUBLIC "//AspectJ/"
"http://www.eclipse.org/aspectj/dtd/aspectj.dtd">
<aspectj>
<weaver options="-verbose">
<include within="<my package>.populators..*"/>
<exclude within="<my package>.populators..*Test"/>
</weaver>

<aspects>
<aspect name="<my aspect package>.PrivateConstructorCoverage"/>
</aspects>
</aspectj>

I also made a small change to the surefire configuration (see [1]).
Instead of pointing to a locally installed version of the aspectjweaver
(${basedir}/../lib/). I changed the surefire configuration to point to
the one in my local maven repository. To make sure aspectjweaver is
actually in my local repository, I added a dependency to it in my pom
file with scope provided.

<argLine>-javaagent:${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar
${debug}</argLine>

Unfortunately due to non disclosure I had to erease a few references to
my currect project. In these places I used the following placeholders:
<my package>
<my aspect package>

Does anyone know why surefire won't start?

Regards,

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

Mobiel: +31 (0) 626 014541
Minto van der sluis
2011-02-12 22:00:00 UTC
Permalink
Hi all,

I figured it out. But got a different error when running 'mvn site' :-(

Using 'mvn -X test' reveiled where the 'null' came from. It came from
'${debug}' in the surefire argline configuration. Removing it from the
configuration made my test work again.

However running 'mvn site' to see the results in coverage reports
resulted in the following output:

...
[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]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[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
at
org.aspectj.weaver.bcel.BcelObjectType.ensureAspectJAttributesUnpacked(BcelObjectType.java:383)
at
org.aspectj.weaver.bcel.BcelObjectType.<init>(BcelObjectType.java:160)
at
org.aspectj.weaver.bcel.BcelWorld.buildBcelDelegate(BcelWorld.java:394)
...
Caused by: java.lang.ClassCastException:
org.aspectj.apache.bcel.classfile.ConstantString cannot be cast to
org.aspectj.apache.bcel.classfile.ConstantUtf8
at
org.aspectj.apache.bcel.classfile.ConstantPool.getConstantUtf8(ConstantPool.java:223)
at
org.aspectj.weaver.bcel.BcelConstantPoolReader.readUtf8(BcelConstantPoolReader.java:31)
at
org.aspectj.weaver.VersionedDataInputStream.readUtf8(VersionedDataInputStream.java:61)
at
org.aspectj.weaver.VersionedDataInputStream.readSignatureAsUnresolvedType(VersionedDataInputStream.java:81)

...

The strange thing this is that the error happens on a completely
different aspect and it does not show up when using 'mvn clean install'.

Any ideas what is causing this?

Regards,

misl

BTW, I am an AOP newby. So any improvements are welcome.
Post by Minto van der sluis
Hi folks,
Following the guidelines from the link below, I am using load time
weaving in for my unit test.
[1] http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg09286.html
Unfortunately this results in the following error message :-(
[INFO] Surefire report directory: <source-path>\target\surefire-reports
java.lang.NoClassDefFoundError: null
Caused by: java.lang.ClassNotFoundException: null
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
Could not find the main class: null. Program will exit.
Exception in thread "main"
Anyone a clue?
Let me explain what I am trying to achieve. I want to increase code
http://stackoverflow.com/questions/4520216/how-to-add-test-coverage-to-a-private-constructor
1) Add a testcase and use reflection instantiate the private
constructor (described in previouse link).
2) Add a static section to my utility class and instantiate the class
static {
new MyClass();
}
The first is rejected because I need to do this for every utility
class and the test is just for the sake of increasing coverage, not
for testing functionality. The second one I reject because it polutes
my code for the sake of code coverage.
I came up
I came up with a solution which is more appealing to me. Creating an
Aspect to achieve the same thing as solution 2. However I do not like
this Aspect to be part of my actual code. So I decided to use load
time weaving during unit testing. This way the additional coverage
only shows up on test utility classes.
package <my aspect package>.aspects;
import java.lang.reflect.Constructor;
import java.lang.reflect.Modifier;
/**
* Special aspect to increase code coverage on classes with private
* constructors.
*
*/
public aspect PrivateConstructorCoverage {
// Joinpoint for static initialization blocks of all
classes in the
// populators package.
pointcut staticInit() : staticinitialization(<my utility
class package>.populators..*);
before(): staticInit() {
// Determine the class on which this advice is
currently working.
Class<?> clazz =
thisJoinPoint.getSignature().getDeclaringType();
Constructor<?> constructor = null;
try {
// Use reflection to get to the default constructor.
constructor = clazz.getDeclaredConstructor();
} catch( NoSuchMethodException e ) {
System.out.println( "Missing default constructor
for: " + clazz.getName() );
}
// Only instantiate the class if a private default
constructor exists.
if ( constructor != null && Modifier.isPrivate(
constructor.getModifiers() )) {
constructor.setAccessible(true);
try {
System.out.println( "Increasing coverage by
calling: new " + clazz.getSimpleName() + "()" );
constructor.newInstance();
} catch (Exception e) {
// Instantiating failed
System.out.println( "Instantiation failed due
to: " + e.getMessage() );
}
}
}
}
This aspect is included in 'src/test/java'. For the sake of load time
weaving I added the following aop.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE aspectj PUBLIC "//AspectJ/"
"http://www.eclipse.org/aspectj/dtd/aspectj.dtd">
<aspectj>
<weaver options="-verbose">
<include within="<my package>.populators..*"/>
<exclude within="<my package>.populators..*Test"/>
</weaver>
<aspects>
<aspect name="<my aspect package>.PrivateConstructorCoverage"/>
</aspects>
</aspectj>
I also made a small change to the surefire configuration (see [1]).
Instead of pointing to a locally installed version of the
aspectjweaver (${basedir}/../lib/). I changed the surefire
configuration to point to the one in my local maven repository. To
make sure aspectjweaver is actually in my local repository, I added a
dependency to it in my pom file with scope provided.
<argLine>-javaagent:${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar
${debug}</argLine>
Unfortunately due to non disclosure I had to erease a few references
<my package>
<my aspect package>
Does anyone know why surefire won't start?
Regards,
misl
--
ir. ing. Minto van der Sluis
Xup BV

Mobiel: +31 (0) 626 014541
Andy Clement
2011-02-14 16:42:32 UTC
Permalink
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
   [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
------------------------------------------------------------------------
   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
Minto van der sluis
2011-02-14 21:47:12 UTC
Permalink
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
Post by Andy Clement
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
Post by Minto van der sluis
[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
------------------------------------------------------------------------
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
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Andy Clement
2011-02-14 23:30:11 UTC
Permalink
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
Post by Minto van der sluis
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
<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
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
[WARNING] advice defined in <my package>.RequestProcessorMonitor has not
been applied [Xlint:adviceDidNotMatch]
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
Post by Andy Clement
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
   [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
------------------------------------------------------------------------
   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
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Minto van der sluis
2011-02-15 06:42:50 UTC
Permalink
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
Post by Andy Clement
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
Post by Minto van der sluis
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
<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
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
[WARNING] advice defined in<my package>.RequestProcessorMonitor has not
been applied [Xlint:adviceDidNotMatch]
@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
Post by Andy Clement
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
Post by Minto van der sluis
[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
------------------------------------------------------------------------
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
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Andy Clement
2011-02-15 16:10:58 UTC
Permalink
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
Post by Minto van der sluis
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.
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
Post by Andy Clement
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
Post by Minto van der sluis
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
<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
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
[WARNING] advice defined in<my package>.RequestProcessorMonitor has not
been applied [Xlint:adviceDidNotMatch]
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
Post by Andy Clement
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
   [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
------------------------------------------------------------------------
   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
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Minto van der sluis
2011-02-15 22:17:16 UTC
Permalink
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
Post by Andy Clement
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
Post by Minto van der sluis
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.
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
Andy Clement
2011-02-16 15:57:46 UTC
Permalink
   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
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
   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
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
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
Post by Minto van der sluis
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.
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
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Loading...