Provide guidelines in AspectJ documentation to avoid dumps

[kriegaex]

Preface

When using spring-aspects with native AspectJ LTW, the AspectJ weaving agent core-dumps, at least in some Spring Boot playground projects I am using in order to answer AOP-related StackOverflow questions. I am not sure if this is is specific to Spring Boot (did not try without it) and ought to be fixed there, or if it is a Spring Core (spring-aspects) problem. Maybe, it even needs some work in AspectJ. Probably the best person to answer that is @aclement, who I had a private conversation with about this issue already.

Either way, it is an issue that needs to be tracked here, because it affects Spring users.

Issue description

As discussed in StackOverflow question #69800420, running a minimal Spring Boot application with JVM parameters (parameter in a single line, of course, and the first one only necessary for JDK 16+)

--add-opens java.base/java.lang=ALL-UNNAMED
-javaagent:.../aspectjweaver-1.9.7.jar
-javaagent:.../spring-instrument-5.3.12.jar

yields ajcore.*.txt core dump files created by AspectJ. Corresponding stack traces featuring MissingResolvedTypeWithKnownSignature are logged to the console. The missing resolved type varies between Spring Boot versions and is e.g. org.springframework.boot.diagnostics.analyzer.ValidationExceptionFailureAnalyzer for Boot 2.3.3 and org.springframework.boot.jdbc.DataSourceBuilder.OraclePoolDataSourceProperties for Boot 2.5.6.

How to reproduce

• Clone the repository found at https://github.com/kriegaex/SO_AJ_SpringTransactionalNotApplied_69789179
• Check out branch aspectj if you prefer Gradle and branch aspectj-with-maven for Maven. The code in both branches is equivalent, only the build tool differs.
• Build and run the sample application, currently based on Spring Boot 2.5.6, adding the JVM parameters mentioned above to the command line. Because the Git repository already contains a workaround configration in a custom aop.xml file, you are not going to see any problems.
• In order to reproduce the problem, simply either delete the aop.xml file or comment out the <exclude within="..."/> tags.

Workaround

The default aop.xml for spring-aspects simply declares aspects and no further weaving options.

A simple way to avoid the core dumps is to exclude problematic target classes from weaving. Even if a future AspectJ release would contain a fix avoiding the core dumps, until then Spring Core could avoid weaving unwanted classes and/or packages by excluding them like I have shown in my custom aop.xml file:

<!DOCTYPE aspectj PUBLIC "-//AspectJ//DTD//EN" "http://www.eclipse.org/aspectj/dtd/aspectj.dtd">
<aspectj>

  <!-- Be verbose about registered aspects, woven joinpoints and Xlint warnings -->
  <!--<weaver options="-verbose -showWeaveInfo">-->
  <!-- Be less noisy, suppressing Xlint warnings and info about registered aspects -->
  <weaver options="-showWeaveInfo -Xlint:ignore">

    <!-- Avoiding AspectJ core dump files 'ajcore.*.txt' by only weaving classes in application-specific packages -->
    <!--<include within="com.example.aspectj..*"/>-->

    <!-- Avoid AspectJ core dump files 'ajcore.*.txt' for ´Spring Boot 2.5.6-->
    <exclude within="org.springframework.boot.jdbc.DataSourceBuilder.OraclePoolDataSourceProperties"/>

    <!-- Avoid AspectJ core dump files 'ajcore.*.txt' for ´Spring Boot 2.3.3-->
    <exclude within="org.springframework.boot.diagnostics.analyzer.ValidationExceptionFailureAnalyzer"/>

  </weaver>

</aspectj>

These weaver options could be merged into the upstream aop.xml for spring-instruments. Otherwise, all users would have to create a custom aop.xml by themselves like I did, just so as to avoid an upstream problem.

BTW, the weaver by default prints lots of [Xlint:cantFindType] warnings, which do no harm but clutter the console log. You might also want to consider adding the -Xlint:ignore weaver option. Another helpful default option is -showWeaveInfo, because it would show to the user by default all woven joinpoints. I think the latter is more desireable than the Xlint messages. But both options are unrelated to the workaround for this issue, I am just mentioning them as ideas for improvement.

[sdeleuze]

After a related team discussion, I am turning this issue into a documentation one.

[kriegaex]

@sdeleuze, I do not think that this is sufficient and only a docs issue, because like I said, spring-aspects has its own aop.xml file in its belly, and it produces those AspectJ core dumps out of the box with Spring Boot. I do not think, it is the user's responsibility to always override the settings from there. She might not even be aware of the fact that there is such a thing as aop.xml, but simply turn on LTW mode for transactions or for injecting Spring beans into non-Spring classes. By first ignoring this issue for 2 years and then just documenting something, it does not go away.