Warning printed after migrating to Spring Boot 3.0 & Spring Integration 6.0-CodePudding

After migrating a project from Spring Boot v2.7 to v3.0 (and thus from Spring Integration v5.5 to v6.0), the following warnings are printed out:

WARN 22084 --- [  restartedMain] ocalVariableTableParameterNameDiscoverer : Using deprecated '-debug' fallback for parameter name resolution. Compile the affected code with '-parameters' instead or avoid its introspection: com.foobar.MyClassA
WARN 22084 --- [  restartedMain] ocalVariableTableParameterNameDiscoverer : Using deprecated '-debug' fallback for parameter name resolution. Compile the affected code with '-parameters' instead or avoid its introspection: com.foobar.MyClassB
WARN 22084 --- [  restartedMain] ocalVariableTableParameterNameDiscoverer : Using deprecated '-debug' fallback for parameter name resolution. Compile the affected code with '-parameters' instead or avoid its introspection: com.foobar.MyClassC
WARN 22084 --- [  restartedMain] ocalVariableTableParameterNameDiscoverer : Using deprecated '-debug' fallback for parameter name resolution. Compile the affected code with '-parameters' instead or avoid its introspection: com.foobar.MyClassD

MyClassA extends IntegrationFlowAdapter, and is annotated with @Component:

package com.foobar;

@Component
class MyClassA extends IntegrationFlowAdapter {
  // …
}

MyClassB is annotated with @ConfigurationProperties:

package com.foobar;

@ConfigurationProperties("my-config")
class MyClassB {
  // …
}

MyClassC is annotated with @Configuration:

package com.foobar;

@Configuration
class MyClassC {
  // …
}

And this particular one not even extending anything, nor annotated:

package com.foobar;

class MyClassD {
  // …
}

I didn’t see any relevant information in the Spring Boot and Spring Integration migration guides. There is a section about name resolution in the Spring Boot migration guide, but it is related to Gradle, and I’m using Maven. I’m not even sure what this name resolution is all about.

I’m puzzled with the class LocalVariableTableParameterNameDiscoverer, and I’m not sure what migration task I’m supposed to do.

CodePudding user response：

As pointed by @m-deinum in the question’s comments, the problem is not related to Spring Boot or Spring Integration, but to Spring Framework itself. I needed to add the -parameters option to javac.

If you are using Maven, adding the following in the pom.xml should solve the problem:

<project>
  
  <!-- … -->

  <build>
    <pluginManagement>
      <plugins>
        <plugin>
          <artifactId>maven-compiler-plugin</artifactId>
          <version>3.10.1</version>
          <configuration>
            <compilerArgs>
              <arg>-parameters</arg>
            </compilerArgs>
          </configuration>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>

  <!-- … -->

</project>

CodePudding user response：

This is somewhat irrelevant to Spring Integration, neither Spring Boot. The change has happened in Spring Framework by itself: https://github.com/spring-projects/spring-framework/issues/29563.

Yes, Spring Integration uses that LocalVariableTableParameterNameDiscoverer in the MessagePublishingInterceptor for @Publisher to have method arguments as an PublisherMetadataSource.ARGUMENT_MAP_VARIABLE_NAME variable in a SpEL EvaluationContext: https://docs.spring.io/spring-integration/docs/current/reference/html/message-publishing.html#message-publishing.

Another one is a @MessagingGateway where we try to resolve header names from @Header method params if you don't provide a name attribute for that annotation: https://docs.spring.io/spring-integration/docs/current/reference/html/messaging-endpoints.html#mapping-method-arguments

Similar logic is present in the MessagingMethodInvokerHelper to resolve header names for POJO service methods: https://docs.spring.io/spring-integration/docs/current/reference/html/configuration.html#annotations

So, we need more info from your Spring Integration configuration to determine the place where you possible just would need to add a name attribute to the @Header annotation on your method param.

I also see that this one LocalVariableTableParameterNameDiscoverer was deprecated in 6.0.1. Please, raise a GH issue against Spring Integration, so we will fix it in favor of the mentioned StandardReflectionParameterNameDiscoverer.