JaCoCo and Aspectj

[vandeve...@gmail.com]

I downloaded JaCoCo today, and got the ant + maven examples going immediately.
But when I change the pom.xml of our project in a similar way as the examples I'm in trouble, almost certainly because we use Aspectj in that project:

1) offline modus:
Here I get the following error message:
[ERROR] Failed to execute goal
org.jacoco:jacoco-maven-plugin:0.6.2.201302030002:instrument (default)
on project com.fugro.gwf.server.core: Execution default of goal org.jacoco:jacoco-maven-plugin:0.6.2.201302030002:instrument failed:
Missing or invalid stackmap frames. -> [Help 1]

2) on the fly modus:
Running com.fugro.gwf.server.core.synchronisation.Synchronise1Test
Start java.lang.instrument.IllegalClassFormatException:
Error while instrumenting class com/fugro/gwf/server/core/referencing/ReferencingAspect.
Underneath this message the stack trace once more shows:
Caused by: java.lang.IllegalStateException: Missing or invalid stackmap frames.

My questions:
1) Is there a way to get coverage information for an aspectj project in JaCoCo?
2) If not, do you know an alternative tool that can deal with aspectj projects. I tried clover, but they simply say they don't support aspectj projects. I also tried Coburtera and emma, but assumed JaCoCo is a more recent (and better supported) tool

[Marc Hoffmann]

Hi,

in any case JaCoCo requires valid classfiles as input. This implies
that class files from version 1.6 on need to contain valid stackmap
frames. If this is not the case JaCoCo will fail with exactly this
message.

Have you reported the problem to AspectJ?

Best regards,
-marc

[Erik Vande Velde]

Hello Marc,

Thanks for your reaction! I'll put your question on the Aspectj forum today.

Kind Regards,

   Erik

2013/3/5 Marc Hoffmann <hoff...@mountainminds.com>

--
You received this message because you are subscribed to a topic in the Google Groups "JaCoCo and EclEmma Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jacoco/Zb_MOFXIUn0/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to jacoco+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Henrik Horneber]

Hi,

I've successfully used JaCoCo together with AspectJ.

You need to make sure

* you use AspectJ version >= 1.7

* java source and target are also set to 1.7

Then AspectJ will generate class files JaCoCo can use.

Best regards,

Henrik

--
You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jacoco+un...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
"I find many of the machines of violence very attractive. Tanks, airplanes, warships, especially aircraft carriers."
- 14th Dalai Lama

[Erik Vande Velde]

Hi Henrik,

This did indeed solve my problem, thanks !!!

2013/3/6 Henrik Horneber <horn...@gmail.com>

[andredas...@gmail.com]

Hi,

I'm using Java 1.7, AspectJ 1.7.3 (for load-time weaving), Jacoco Maven plugin 0.6.3.201306030806 and Maven Surefire Plugin 2.15 to run the tests. In these conditions Jacoco doesn't work correctly.

If Jacoco's Java agent is set as the second Java agent (after AspectJ weaver agent), the build produces these errors:

java.lang.instrument.IllegalClassFormatException: Error while instrumenting class CLASS_NAME.
at org.jacoco.agent.rt.internal_9dd1198.CoverageTransformer.transform(CoverageTransformer.java:89)
at sun.instrument.TransformerManager.transform(TransformerManager.java:188)
...
Caused by: java.io.IOException: Error while instrumenting class CLASS_NAME.
at org.jacoco.agent.rt.internal_9dd1198.core.instr.Instrumenter.instrumentError(Instrumenter.java:147)
at org.jacoco.agent.rt.internal_9dd1198.core.instr.Instrumenter.instrument(Instrumenter.java:98)
at org.jacoco.agent.rt.internal_9dd1198.CoverageTransformer.transform(CoverageTransformer.java:87)
... 64 more

Caused by: java.lang.IllegalStateException: Missing or invalid stackmap frames.

at org.jacoco.agent.rt.internal_9dd1198.core.internal.instr.FrameTracker.assertValidFrames(FrameTracker.java:613)
at org.jacoco.agent.rt.internal_9dd1198.core.internal.instr.FrameTracker.pop(FrameTracker.java:602)
at org.jacoco.agent.rt.internal_9dd1198.core.internal.instr.FrameTracker.visitVarInsn(FrameTracker.java:386)
at org.jacoco.agent.rt.internal_9dd1198.asm.MethodVisitor.visitVarInsn(Unknown Source)
at org.jacoco.agent.rt.internal_9dd1198.asm.MethodVisitor.visitVarInsn(Unknown Source)
at org.jacoco.agent.rt.internal_9dd1198.asm.tree.VarInsnNode.accept(Unknown Source)
at org.jacoco.agent.rt.internal_9dd1198.asm.tree.InsnList.accept(Unknown Source)
at org.jacoco.agent.rt.internal_9dd1198.asm.tree.MethodNode.accept(Unknown Source)
at org.jacoco.agent.rt.internal_9dd1198.core.internal.flow.ClassProbesAdapter$1.visitEnd(ClassProbesAdapter.java:124)
at org.jacoco.agent.rt.internal_9dd1198.asm.ClassReader.b(Unknown Source)
at org.jacoco.agent.rt.internal_9dd1198.asm.ClassReader.accept(Unknown Source)
at org.jacoco.agent.rt.internal_9dd1198.asm.ClassReader.accept(Unknown Source)
at org.jacoco.agent.rt.internal_9dd1198.core.instr.Instrumenter.instrument(Instrumenter.java:78)
at org.jacoco.agent.rt.internal_9dd1198.core.instr.Instrumenter.instrument(Instrumenter.java:96)
... 65 more


if it is set as the first Java Agent (before AspectJ) it works for most classes, but fails to produce correct coverage reports for weaved classes (all the lines appear as not covered even though I have tests covering them).

I tried to use the classdumpdir solution presented here: https://github.com/jacoco/eclemma/issues/33 but I can't find a equivalent Maven configuration for the setting the check and report Jacoco goals to use the classdumpdir directory.

Does anyone have a solution for this?

Thanks,
André.

> To unsubscribe from this group and all its topics, send an email to jacoco+un...@googlegroups.com.

[Marc R. Hoffmann]

Hi Andr�,

this strange. If the JaCoCo agent really is the very first agent in the
command line it should see the class files (or JARs) from the file
system. So if the report is created based on the exact same file the
report should show coverage for all executed classes.

In the JaCoCo HTML report can you please check whether the classes in
question are listed on the sessions page (link in the top right corner).

Thanks,
-marc

> Andr�.

[André Pinto]

Hi Marc,

thanks for replying so quickly.

Right now I'm only testing a specific problematic class in order to perform faster clean install iterations while trying different approaches.

The class that I'm testing does not appear on the Sessions page when I have AspectJ weaver agent enabled. In its place there are two AjcClosure classes from AspectJ:

CLASS_NAME.AjcClosure1    8b30d747616523a0
CLASS_NAME.AjcClosure3    b62aad26ee5ff4eb
CLASS_NAME.Result [nested class with link]    27ec6335c32de676
CLASS_NAMEIntTest    c508b26e62564a2b
CLASS_NAMETest    d101cb5455c0b79d
CLASS_NAMETest.TestDelegate    89770d1905c6d466


When not using AspectJ LTW the class appears in the session page (I needed to comment the tests that used AOP for this to work so the nested class does not appear now):

CLASS_NAME [with link]    9be84e8927495ca6
CLASS_NAMEIntTest    6e56338794a364f2
CLASS_NAMETest    d101cb5455c0b79d
CLASS_NAMETest.TestDelegate    89770d1905c6d466

This is my Jacoco Maven plugin configuration:

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.6.3.201306030806</version>
    <configuration>
        <propertyName>coverageAgent</propertyName>
        <skip>false</skip>
        <excludes>
                EXCLUDES LIST
        </excludes>

        <classDumpDir>${basedir}/target/jacoco-classes</classDumpDir>
    </configuration>

    <executions>
        <execution>
            <id>prepare-agent</id>
            <goals>
                <goal>prepare-agent</goal>
            </goals>
        </execution>
        <execution>
            <id>report</id>
            <phase>prepare-package</phase>
            <goals>
                <goal>report</goal>
            </goals>
        </execution>
        <execution>
            <id>check</id>
            <goals>
                <goal>check</goal>
            </goals>
            <configuration>
                <rules>
                    RULES LIST
                </rules>
            </configuration>
        </execution>
    </executions>
</plugin>

and my Maven Surefire plugin configuration:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.15</version>

    <configuration>
        <groups>specific_test_group</groups>
        <argLine>-Xmx1024m -XX:MaxPermSize=256m ${coverageAgent} -javaagent:"${aspectj.agent.jar}"</argLine>
        <properties>
            <property>
                <name>listener</name>
                <value>SOME_TESTNG_LISTENERS</value>
            </property>
        </properties>
    </configuration>
</plugin>

Thanks,

André

On Sun, Jul 21, 2013 at 4:58 PM, Marc R. Hoffmann <hoff...@mountainminds.com> wrote:

Hi André,

André.

--
You received this message because you are subscribed to a topic in the Google Groups "JaCoCo and EclEmma Users" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/jacoco/Zb_MOFXIUn0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jacoco+unsubscribe@googlegroups.com.

[André Pinto]

I forgot to say that the problematic test that I'm running is CLASS_NAMEIntTest (Integration test that requires AOP) and that's the one that I needed to edit to remove the AOP-dependent tests (that's why its hashcode changed).

CLASS_NAMETest is a unit test that is not running right now (because I limited the running tests to the integration test). Per our implementation, unit tests don't use AOP so they are not a concern here. CLASS_NAMETest.TestDelegate is a nested class of that unit test. Both of these classes keep their hash codes because I didn't change them.

[Marc Hoffmann]

Hi André,

if AspectJ replaces classes with other differently named classes things
get tricky. As you already proposed you might try to dump these extra
classes and create a report including those classes (although the
original class probably still renders at not covered). I'm not a Maven
expert but a possible setup might look like this:

1) Backup original classes in target/classes
2) specify classDumpDir for the prepare-agent goal to dump classes to
target/classes
2) Create JaCoCo report
3) Restore target/classes from backup

See documentation of JaCoCo Maven goals:
http://www.eclemma.org/jacoco/trunk/doc/maven.html

Cheers,
-marc

>>> https://github.com/jacoco/eclemma/issues/33 [5] but I can't find a

>>> equivalent Maven configuration for the setting the check and
>>> report Jacoco goals to use the classdumpdir directory.
>>>
>>> Does anyone have a solution for this?
>>>
>>> Thanks,
>>> André.
>>>
>>> On Wednesday, March 6, 2013 8:52:36 AM UTC, Erik Vande Velde
>>> wrote:
>>>
>>>> Hi Henrik,
>>>>
>>>> This did indeed solve my problem, thanks !!!
>>>>

>>>> 2013/3/6 Henrik Horneber <horn...@gmail.com [1]>

>>>>
>>>> Hi,
>>>>
>>>> I've successfully used JaCoCo together with AspectJ.
>>>>
>>>> You need to make sure
>>>>
>>>> * you use AspectJ version >= 1.7
>>>>
>>>> * java source and target are also set to 1.7
>>>>
>>>> Then AspectJ will generate class files JaCoCo can use.
>>>>
>>>> Best regards,
>>>>
>>>> Henrik
>>>>
>>>> On Wed, Mar 6, 2013 at 8:02 AM, Erik Vande Velde
>>>> <vandeve...@gmail.com [2]> wrote:
>>>>
>>>> Hello Marc,
>>>>
>>>> Thanks for your reaction! I'll put your question on the Aspectj
>>>> forum today.
>>>>
>>>> Kind Regards,
>>>>     Erik
>>>>

>>>> 2013/3/5 Marc Hoffmann <hoff...@mountainminds.com [3]>

>> [7].

>> To unsubscribe from this group and all its topics, send an email to

>> jacoco+un...@googlegroups.com [8].

>> For more options, visit https://groups.google.com/groups/opt_out

>> [9].
>
> --
> You received this message because you are subscribed to the Google

> Groups "JaCoCo and EclEmma Users" group.

> To unsubscribe from this group and stop receiving emails from it,
> send an email to jacoco+un...@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out

> [11].
>
>
>
> Links:
> ------
> [1] mailto:horn...@gmail.com
> [2] mailto:vandeve...@gmail.com
> [3] mailto:hoff...@mountainminds.com
> [4] mailto:vandeve...@gmail.com
> [5] https://github.com/jacoco/eclemma/issues/33
> [6] mailto:andredas...@gmail.com
> [7] https://groups.google.com/d/topic/jacoco/Zb_MOFXIUn0/unsubscribe
> [8] mailto:jacoco%2Bunsu...@googlegroups.com
> [9] https://groups.google.com/groups/opt_out
> [10] mailto:hoff...@mountainminds.com
> [11] https://groups.google.com/groups/opt_out

[andredas...@gmail.com]

Hi Marc,

thanks again for your reply.

I think AspectJ doesn't change the name of the class, but actually creates those additional classes to serve as support for AOP advices. If I set a breakpoint in a method of that class, during the build I can see it is still reached and the call trace looks something like this:

METHOD_NAME_aroundBody0():76, CLASS_NAME
run():1, CLASS_NAME$AjcClosure1

... (aspect methods)

METHOD_NAME():76, CLASS_NAME
TEST_NAME

so both the AjcClosure and the actual class are present and called.

Today I've tried to use offline instrumentation and it appears to have solved the problem. I know this is not the recommended approach and that it introduces additional issues, like not being able to run a maven test-goal-only phase after a failed test goal without manually running the restore-instrumented-classes goal; but I think I will have to use it while the run time instrumentation doesn't work (or if it is actually impossible to do the same thing with run time instrumentation).

Thanks,
André.

[reinhard...@gmail.com]

Did anybody have a valid pom.xml to use jacoco within an aspectJ project?

[armstrong...@gmail.com]

On Wednesday, March 6, 2013 3:18:12 PM UTC+8, Henrik Horneber wrote:
> Hi,
>
>
> I've successfully used JaCoCo together with AspectJ.
>
>
> You need to make sure
>
> * you use AspectJ version >= 1.7
>
> * java source and target are also set to 1.7
>
>
>
> Then AspectJ will generate class files JaCoCo can use.
>
>
> Best regards,
>
> Henrik

Works for me, thanks!

[simioni...@gmail.com]

Since Java 1.7 is not an option for me, I have raised the issue on AspectJ: https://bugs.eclipse.org/bugs/show_bug.cgi?id=418367

BTW there was this comment there: "I notice you mentioning Java 1.6 where stack maps are *actually* optional, so JaCoCo strictly requiring them is a little overzealous"

[bradle...@gmail.com]

I came across this post since I was getting the same error: Missing or invalid stackmap frames. In my case, it was not aspectj, but rather jrebel. Apparently, you cannot have the jacoco and jrebel agents active at the same time.