Compile-time-weaving for injecting Spring Beans into unmanaged objects broken?

[AG72]

We use compile-time-weaving for injecting Spring Beans (using @Autowired) into unmanaged objects inside a Spring boot application for a long time now. Inside the pom.xml, aspectj-maven-plugin is used to do the magic. Using the plugin from org.codehaus.mojo worked fine up to java 16.

To upgrade to java 17, we tried to switch to dev.aspectj plugin assuming not to change the behavior - but this somehow breaks the compile time weaving. Those @Autowired variables are suddenly null with this plugin.

Some version information:

• Spring boot 2.7.8
• Java 17

Sample of a class to be weaved:

package de.ba.wws.dtoassembler.impl;

@Configurable
public class ArtikelinfoDtoAssembler {

    @Autowired
    private ArtikelSearchDao artikelSearchDao;
    @Autowired
    private ArtikelBeinhaltetDao artikelBeinhaltetDao;
    @Autowired
    private BestandDao bestandDao;

    // ...
}

Extract from pom.xml, ${aspectj.version} is 1.9.8:

            <!-- ... -->
            <plugin>
        <groupId>dev.aspectj</groupId>
        <artifactId>aspectj-maven-plugin</artifactId>
                <configuration>
                    <proc>none</proc>
                    <showWeaveInfo>true</showWeaveInfo>
            <!-- <verbose>true</verbose>-->
                    <complianceLevel>${java.compiler.version}</complianceLevel>
                    <Xlint>ignore</Xlint>
                    <aspectLibraries>
                        <aspectLibrary>
                            <groupId>org.springframework</groupId>
                            <artifactId>spring-aspects</artifactId>
                        </aspectLibrary>
                    </aspectLibraries>
                    <sources>
                        <source>
                            <basedir>${basedir}/src/main/java</basedir>
                            <includes>
                                <include>de/ba/wws/bo/*</include>
                                <include>de/ba/wws/dtoassembler/impl/*</include>
                <!-- ... lots more ... -->
                            </includes>
                        </source>
                    </sources>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>compile</goal>
                        </goals>
                    </execution>
                </executions>
                <dependencies>
                    <dependency>
                        <groupId>org.aspectj</groupId>
                        <artifactId>aspectjrt</artifactId>
                        <version>${aspectj.version}</version>
                    </dependency>
                    <dependency>
                        <groupId>org.aspectj</groupId>
                        <artifactId>aspectjtools</artifactId>
                        <version>${aspectj.version}</version>
                    </dependency>
              </dependencies>
            </plugin>

Thanks for any help!

[kriegaex]

You claim that switching the plugin causes the problems, but maybe it is not the plugin but rather switching to Java 17, which you cannot do with the Mojohaus plugin in the first place. To isolate the problem and find out if this plugin really is part of the problem, does the exact same project which builds on Java 16 with the Mojohaus version also build with this one here, or does it break already?

Furthermore, in order to find out what is the problem with your Java 17 compilation, please provide a minimal reproducer project on GitHub. I do not need your original project with confidential code, just a small, but complete reproducer. I cannot compile, run and debug your out-of-context snippets. Without further evidence, for now I am assuming that the problem sits in front of the computer. As soon as I have reproducible evidence to the contrary, I shall be more than ready to investigate and fix the problem, either in AspectJ Maven or in AspectJ itself.

[kriegaex]

${aspectj.version} is 1.9.8

P.S.: No need to stick with 1.9.8, you can use the latest release 1.9.19.

[kriegaex]

I just tried an old proof-of-concept sample project, also using this plugin with Java 17, spring-aspects, @Configurable and @Autowired. No problems, everything works fine, no matter if I use the older AspectJ 1.9.8 or the latest 1.9.19.

[AG72]

Thanks for your quick responses! I'll try to setup a small project that reproduces the issue and then come back to you.

[AG72]

While trying to setup a reproducer project by stripping down our big application into something small, I found out that there was another piece in our pom (<pluginExecutionFilter>) that needed to be switched to the dev.aspectj plugin as well. Doing so solved the issue!

Without further evidence, for now I am assuming that the problem sits in front of the computer.

I must admit that your assumption was right ;-) . Sorry for bothering you.

[kriegaex]

You were not bothering me at all. After all, you thought that there was a problem in this plugin. You just have to bear with me challenging your assumptions, if I think I have reason to do so. 😉

I am glad you managed to solve the problem. This is why I like asking for MCVEs: By creating one, usually you learn something about your own problem already. Creating a reproducer is a great tool to focus on the essential part of a problem. 🙂

[kriegaex]

there was another piece in our pom (<pluginExecutionFilter>) that needed to be switched to the dev.aspectj plugin as well

Note to myself for similar future inquiries: Said part of the POM should be completely irrelevant for the Maven build as such. It is only used to map plugin executions to the Eclipse IDE lifecycle when importing Maven projects.