0

I'm using Spring's @Configurable to autowire a bean constructed with 'new' in a Dropwizard application. I have an integration test that uses the DropwizardAppRule to bring up the application and am using the aspectj-maven-plugin for compile time weaving.

When I make build and run the integration test from IDEA the bean is wired as expected and the test passes.

When I run 'mvn clean install' the bean is NOT wired and the test fails with a NullPointerException.

When I run 'mvn clean install -DskipTests' and start the application the bean is wired correctly.

My question is why does it fail during 'mvn clean install'?

The aspectj-maven-plugin is running during the process-sources phase so the classes should be instrumented before the integration tests run:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>aspectj-maven-plugin</artifactId>
    <version>1.8</version>
    <configuration>
      <complianceLevel>1.8</complianceLevel>
      <source>1.8</source>
      <target>1.8</target>
      <aspectLibraries>
        <aspectLibrary>
          <groupId>org.springframework</groupId>
          <artifactId>spring-aspects</artifactId>
        </aspectLibrary>
      </aspectLibraries>
    </configuration>
    <executions>
      <execution>
        <phase>process-sources</phase>
        <goals>
          <goal>compile</goal>
          <goal>test-compile</goal>
        </goals>
      </execution>
    </executions>
  </plugin>

If I decompile the class I can see that it has indeed been instrumented.

If I put break point in the @Autowired setter and run the integration test from IDEA I can see that the class is being wired by Spring.

It doesn't break in the setter at all when running 'mvn clean install'.

Replacing @Autowired with @Resource doesn't help.

I have a Spring configuration class that has @EnableSpringConfigured. My best guess is that the DropwizardAppRule isn't using the correct Spring configuration although the other spring components are being managed correctly.

Any help is greatly appreciated. Thank you.

edit

I've also tested both default surefire (maven 3.2.5) and with:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.18.1</version>
</plugin>
user2830040
  • 1
  • 1

1 Answers1

0

I figured it out but a little more context is required to explain the problem. The @Configurable was being instantiated in an enum like so:

public enum Day {
    MONDAY(new MyConfigurableObject()),
    ...
}

Unit and integration tests were run together and the unit tests were instantiating the enum before a spring context was available. Because enums exist in a static context, the unwired enum was then used by the integration test.

The solution is to split up unit and integration test execution. I did this using the maven-failsafe-plugin like so:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.18.1</version>
    <configuration>
        <excludes>
            <exclude>it/**</exclude>
        </excludes>
    </configuration>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <version>2.18.1</version>
    <configuration>
        <includes>
            <include>it/**</include>
        </includes>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>integration-test</goal>
                <goal>verify</goal>
            </goals>
        </execution>
    </executions>
</plugin>
user2830040
  • 1
  • 1