Compile-time weaving support for aspects

[jefftap]

Hi, I am attempting to make use of TimedAspect via AspectJ compile-time weaving using the aspectj-maven-plugin. When the aspect code is executed, it throws one of the two errors, depending on what is being executed:

java.lang.NoSuchMethodError: io.micrometer.core.aop.TimedAspect.aspectOf()Lio/micrometer/core/aop/TimedAspect

java.lang.NoSuchMethodException: io.micrometer.core.aop.TimedAspect.aspectOf()

This usually indicates that the AspectJ weaver has not properly processed the aspect code. I am not sure if this is a problem with my own code/configuration, or if it's an issue in Micrometer's jar. The aspect works perfectly fine using Spring AOP, but I would prefer to use AspectJ weaving with @Timed to allow it access to private/protected methods and the other various benefits one gets from AspectJ integration.

Relevant information:

• micrometer-core version: 1.1.1
• Spring Boot version: 2.1.1.RELEASE
• AspectJ verison: 1.9.2
• Java version: 1.8
• aspectj-maven-plugin version: 1.11

aspectj-maven-plugin configuration:

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>aspectj-maven-plugin</artifactId>
                <version>1.11</version>
                <configuration>
                    <complianceLevel>1.8</complianceLevel>
                    <source>1.8</source>
                    <target>1.8</target>
                    <showWeaveInfo>true</showWeaveInfo>
                    <Xlint>ignore</Xlint>
                    <aspectLibraries>
                        <aspectLibrary>
                            <groupId>org.springframework</groupId>
                            <artifactId>spring-aspects</artifactId>
                        </aspectLibrary>
                        <aspectLibrary>
                            <groupId>io.micrometer</groupId>
                            <artifactId>micrometer-core</artifactId>
                        </aspectLibrary>
                    </aspectLibraries>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>compile</goal>
                            <goal>test-compile</goal>
                        </goals>
                    </execution>
                </executions>
                <dependencies>
                    <dependency>
                        <groupId>org.aspectj</groupId>
                        <artifactId>aspectjtools</artifactId>
                        <version>${aspectj.version}</version>
                    </dependency>
                </dependencies>
            </plugin>

[jkschneider]

Have you added aspectj weaving to the build section of your POM?

<build>
<plugins>
  <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>aspectj-maven-plugin</artifactId>
    <executions>
      <execution>
        <goals>
          <goal>compile</goal> 
        </goals>
      </execution>
    </executions>
  </plugin>
</plugins>

[jefftap]

Yes. The aspectj-maven-plugin configuration I posted in my initial post is under <build>/<plugins>.

[jefftap]

My current hypothesis is that the build.gradle file needs the aspectj plugin applied to it. This should cause the Micrometer build to use ajc, which should process the aspect.

[jefftap]

Also, one way to work around this is to write your own aspect that weaves around an annotation and use the Timer methods in there. It still needs to be coupled with Spring, though. Inject the MeterRegistry as a dependency. The bean should be declared in the Spring configuration using the Aspects.aspectOf method to pull in the AspectJ instance, and Spring handles the injection from there.

[izeye]

I don't have much expertise on AspectJ but after some quick research, it seems to require a similar configuration to spring-aspects to support compile-time weaving as already pointed out by @jefftap although I'm not sure there's any plan for compile-time weaving support.

[jefftap]

Looks like spring-aspects.jar compiles with ajc, then. I think the solution to this ticket is to either compile Micrometer with ajc, or improve the documentation on how to get Micrometer to work properly with AspectJ. I can write a small addition to the documentation explaining this, if desired.

[ewencluley]

I am running into the exact same issue as @jefftap. While the compile time weaving seems to succeed, at runtime the aspectOf methods are not there on the TimedAspect classes. The documentation for micrometer suggests the @Timed annotation should be supported using compile time aspectj weaving. (https://micrometer.io/docs/concepts#_the_code_timed_code_annotation)

use in your application either through compile/load time AspectJ weaving or through framework facilities that interpret AspectJ aspects

Would be great to have some documentation on how to get this working.

[Phil-Ba]

I didn't manage to get this working with CTW. As far as I understood it, it seems that micrometer-core is not compiled with the ajc and thus the aspects are missing the required factory methods.
The only solution I found, was to do LTW and have the micrometer-core classes also be woven during load time.
Another solution would be the recompile the micrometer-core jar with the aspectj maven plugin, but this also requires all dependencies...

[Exidex]

The issue still persist. As noted higher it could be resolved by using LTW, but in my case it is not an option because I do not have access to the deployment setup, and the only option is CTW which doesn't work with this library

[innovationhub-asia]

Same issue here, CTW does not work. Is there any plan to support it properly, so CTW will work ?

[venushka]

I've had the same issue with CTW, although I got around this by wrapping the aspect like this for now.

@Aspect
public class MetricsAspect {
  @Around("execution (@io.micrometer.core.annotation.Timed * *.*(..))")
  public Object timedMethod(ProceedingJoinPoint pjp) throws Throwable {
    final TimedAspect timeAspect = new TimedAspect(MetricsServlet.getRegistry());
    return timeAspect.timedMethod(pjp);
  }
}

and adding the following to the aop.xml

<aspectj>
  <aspects>
    <aspect name="com.venushka.metrics.MetricsAspect"/>
  </aspects>
</aspectj>

It would be great if this works out of the box for CTW.

[dalbani]

Hi, for those on the interweb who came here for load time weaving (LTW), I confirm that it works.
That's my META-INF/aop.xml file:

<aspectj>
    <weaver>
        <include within="io.micrometer.core..*"/>
        <include within="my.app..*"/>
    </weaver>

    <aspects>
        <aspect name="io.micrometer.core.aop.TimedAspect"/>
    </aspects>
</aspectj>

To be used in conjunction with a class like:

package my.app;

public class App {
  @Timed("xyz")
  public void fun1() { }
}

In a Spring Boot application with the @EnableLoadTimeWeaving annotation.

I'm a newbie when it comes to aspects, but I'm wondering what the advantages of CTW over LTW are.
@Exidex: when you said that "you do not have access to the deployment setup", did you mean that you couldn't make sure that the JVM was configured with the appropriate agent?
I don't know if that would solve your problem, but I personally use https://github.com/invesdwin/invesdwin-instrument to have the application code register the agent by itself.

[kriegaex]

Because I often answer questions on StackOverflow, I found this issue, not for the first time in the last few years. Today I took some time to look into it, producing a little example project, showing how to apply TimedAspect via @Timed, using compile-time weaving with AspectJ Maven plugin. The same basic approach should also work with Gradlle, but I am a Maven guy.

https://github.com/kriegaex/SO_AJ_MicrometerTimed_67803726

The project simply consists of one class and a POM + an explanatory read-me file. The gist of it is: You must make sure to apply binary weaving to the Micrometer aspect in order to transform it into a real AspectJ aspect, and then apply that aspect to your own project.

[marcingrzejszczak]

Since there are ways of how to achieve this is there anything else we should do here, other than maybe document this?

[kriegaex]

Since there are ways of how to achieve this

My workaround is very contrived. IMO, it is unreasonable to assume that any normal user who does not happen to be an AspectJ expert can find out how to do this. Even if it was documented, users would be doing the Micrometer team's work there.

is there anything else we should do here, other than maybe document this?

Yes, add an AspectJ compilation step to the Gradle build (e.g. using Freefair plugin) and make sure that what is advertised as an AspectJ aspect, ...

micrometer/micrometer-core/src/main/java/io/micrometer/core/aop/TimedAspect.java

Lines 36 to 37 in 2252347

	* AspectJ aspect for intercepting types or methods annotated with
	* {@link Timed @Timed}.<br>

... actually really does deserve its name, and avoid that incomplete non-AspectJ compilation with Javac needs to be finished by the user. That this happens to work with LTW, because the AspectJ weaver is smart enough to notice and finish the job, does not mean that CTW is some kind of second-class citizen. Make your product easy to use. The correctly compiled aspect would, of course, still work with LTW. With CTW, the library could just be put on the aspectpath, as is customary. No extra build steps or extra modules, creating a refined version of this library as an input for later steps.

Of course, aspectjrt would become a dependency of this library, but in fact it already is anyway, because as-is, you need LTW and aspectjweaver,

micrometer/micrometer-core/build.gradle

Lines 80 to 81 in 2252347

	// Aspects
	optionalApi 'org.aspectj:aspectjweaver'

which is a superset of aspectjrt and actually more than the library really needs. The dependency should be downgraded to aspectjrt.

[mihalyr-prospect]

I am trying to migrate my project from Dropwizard Metrics to Micrometer and I'm blocked on this issue as I am trying to use compile-time weaving just like with Dropwizard annotations before and it doesn't seem to work with Micrometer despite the documentation saying it can be used also with compile time weaving.

I have a Gradle project and was trying to convert the above mentioned workaround from Maven to Gradle, but the plugins are different and am running into various build failures. I tried to revert to Spring AOP proxies, but that doesn't work on my project, CGLIB breaking some of the classes.

Are there any updates on the fix? Or did anyone make it work with Gradle (Freefair plugin)?

(Update: Fixed it by configuring AspectJ load-time weaving, seems to be working alongside CTW for other classes)

[kriegaex]

@marcingrzejszczak, see, this is what I mean. It is possible to finish the job unfinished by Micrometer manually as a user, but it is not trivial. Instead of burdening users, trying to figure out how to use your aspect, because you think it is unnecessary to compile it with the AspectJ compiler, you should finally get this issue off the table. Or are you expecting me to convert my Maven solution to Gradle on behalf of @mihalyr-prospect?

[marcingrzejszczak]

@kriegaex I don't think that your answer is nice or brings any value to this discussion. We will take care of this issue whenever we have bandwith to do so.

[kriegaex]

@marcingrzejszczak: I wanted to be clear rather than nice. I was not super nice, maybe, but also not non-nice. I did not insult anyone. I simply want to push this forward. Honestly, this issue has been open for more than 5 years, and I do not really buy the bandwidth argument, because

• your product is an aspect library, but you do not compile the aspect as such,
• which makes this issue a high priority one, IMO,
• it is clear what needs to be done, no further debugging or even any code changes necessary,
• changing the build configuration should be straightforward and in no way rocket science.

The product I maintain, AspectJ, is a cornerstone of Micrometer, so please understand that I would rather like to see it fixed than feeling compelled to devise custom workarounds to various users for a few more years.

[mihalyr]

For instance, I do not understand why you would need to change anything in your pointcuts for CTW in the first place. The only reason would be that that it was broken before for LTW, too, which is unrelated to this issue here.

Exactly, it was broken for LTW too.

The annotations could be added for a whole class and for separate methods. If it is on a class, it would instrument all methods (that are otherwise not annotated with the same annotation). But this class level annotation was broken because of the and not syntax so the pointcut didn't work (only worked for methods). When I fixed this by changing and not to && ! the pointcut started to work but also matched constructors which the code didn't expect and crashed - both CTW and LTW. My fix for this was to add && execution(* *(..)) to filter out constructors, which works now.

After all this I noticed that I get double counts using @Counted and the only difference between that and the other aspects was the pointcut.

Counted used: @Around(value = "@annotation(counted)", argNames = "pjp,counted")

While Timed used: @Around("execution (@io.micrometer.core.annotation.Timed * *.*(..))")

So I changed Counted also to @Around("execution (@io.micrometer.core.annotation.Counted * *.*(..))") and now it works fine.

So right now with these pointcut changes everything seems to be working, AspectJ with CTW or LTW and also Spring AOP (with 6.1.7-SNAPSHOT and JDK17).

I'm not really involved with Micrometer project though, I just wanted to use this library the first time ever and naturally went for CTW which didn't work and ended up here, found a little free time to help out, but don't know much about why things were written in a certain way or what other goals are here. For that I think Marcin is the person to ask.

[kriegaex]

Thanks for the clarification. I recommend a more readable change like this instead as a minimal and clean change compared to the main branch:

@Around(value = "@annotation(counted) && execution(* *(..))", argNames = "pjp,counted")

I find that more readable, and it is a simple and mechanical thing to do to just add && execution(* *(..)) when converting a Spring AOP aspect to native AspectJ without breaking compatibility. The reason why you want to add that is to exclude AspectJ's call() joinpoints, which cause the double counts in your case. Spring AOP only knows execution(), i.e. there it is unnecessary. But AspectJ knows both pointcut types, which are semantically different - one is in the calling class/method, the other one in the called one. I.e., && execution(* *(..)) makes explicit what Spring AOP assumes implicitly. I find that more readable than mixing everything into a single pointcut.

[kriegaex]

BTW, I tested a manually Ajc-compiled aspect in my old Spring AOP playground project with Spring 5.3.16 in the debugger, setting a breakpoint inside AbstractAspectJAdvisorFactory::compiledByAjc and each time forcing a return value of false, which made the native aspect work with Spring AOP. I guess, that is similar to your change for Spring 6.x., isn't it? I just wanted to make sure I understand this a bit better.

[kriegaex]

Another hint, just in case you happen to be using or be planning to use pointcuts with something like within(my.package..*). Be careful there in native AspectJ, if the aspect is in the same package. In that case, add && !within(MyAspect) to the pointcut to avoid the aspect from weaving itself or one aspect weaving the other one, which sometimes makes sense in AspectJ, but usually is not what you want. In Spring AOP, aspects cannot weave each other or themselves, i.e. it is implicitly excluded by the proxy-based approach, similar to how call() is not a thing due to the proxies.

Probably, this is not a problem at the moment, otherwise I guess you would be running into test problems already. Just a caveat for the future...

[mihalyr]

Thank you Alexander, super useful information and the simpler syntax would solve binary compatibility issue I have also.

BTW, I tested a manually Ajc-compiled aspect in my old Spring AOP playground project with Spring 5.3.16 in the debugger, setting a breakpoint inside AbstractAspectJAdvisorFactory::compiledByAjc and each time forcing a return value of false, which made the native aspect work with Spring AOP. I guess, that is similar to your change for Spring 6.x., isn't it? I just wanted to make sure I understand this a bit better.

I can't comment on this part as it was @jhoeller who made that change in Spring, but I also assume it was something like that.

[marcingrzejszczak]

@kriegaex we're building micrometer with jdk11. Can we fix the AspectJ compiler to 1.9.20.1?

[kriegaex]

@marcingrzejszczak, yes, if you do not mind missing compiler enhancements and bugfixes. Would it be a big deal to build on JDK 17+ instead? JDKs 17 and 21 are LTS.

[marcingrzejszczak]

We would have to discuss this internally @shakuzen @jonatan-ivanov

[marcingrzejszczak]

Ok, #5059 is ready for review. Let's try to close this 5 year old issue ;)

[shakuzen]

This has been delivered in 1.14.0-SNAPSHOT snapshots and for the upcoming 1.14.0-M1 milestone versions. Thank you to everyone who helped get this finally implemented.
Folks who were looking for this feature, let us know if it's working well for you or if there are any remaining issues.

[mihalyr]

I just found some time to test the snapshot briefly. I added the post-compile weaving Gradle plugin, removed the runtime javaagent and aop.xml from my project and checked that it builds and I get the metrics from the @Timed annotations on the /prometheus endpoint.

First, I thought, something might be missing as ajc was giving me the warning of not applied aspect from the TimedAspect.class:

/var/home/tryprospect/.gradle/caches/modules-2/files-2.1/io.micrometer/micrometer-core/1.14.0-SNAPSHOT/9c4d0b30591b8215fd409ec80d50d624675f9aae/micrometer-core-1.14.0-SNAPSHOT.jar!io/micrometer/core/aop/TimedAspect.class [warning] advice defined in io.micrometer.core.aop.TimedAspect has not been applied [Xlint:adviceDidNotMatch]

But, I think, this was for the class-level annotation (timedClass) and I only use the method-level annotations, so the warning was a bit misleading without the pointcut. However, at runtime, I got the metrics, so I think, it is working.

Before that, I tested also load-time weaving with the javaagent and was not getting the invalid pointcut syntax errors anymore at runtime, so that should be good too.

What I don't use is Spring AOP, so I didn't test that.