Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autowiring by name not working in 3.2.0? #38536

Closed
anogueiraFlywire opened this issue Nov 24, 2023 · 10 comments
Closed

Autowiring by name not working in 3.2.0? #38536

anogueiraFlywire opened this issue Nov 24, 2023 · 10 comments
Labels
status: invalid An issue that we don't feel is valid

Comments

@anogueiraFlywire
Copy link

Hello team,
We've tried upgrading to version 3.2.0 of Spring Boot and we came across what we think might be a bug.
With this new version, Autowiring by name doesn't seen to be working, and it's forcing us to include a @qualifier(name) tag whenever we have multiple beans of the same type. Is this behaviour intended and we missed it from the docs?

Example:

We have multiple Queue and TopicExchange defined with different names, like

@Bean
   Queue activityQueue(@Value("${amqp.activity.queue}") String queueName) {
       return new Queue(queueName);
   }

And we used to inject it with:

@Bean
   Binding rabbitActivityBinding(Queue activityQueue, TopicExchange activityExchange) {
       return BindingBuilder.bind(activityQueue)
           .to(activityExchange).with(ACTIVITY_POSTED_ROUTING_KEY);
   }
This used to find the right beans and inject them properly, but now it's complaining that it finds 9 instances and forces us to add a @Qualifier. This looks like a major change to Spring behaviour

A similar example happened with @PathVariable:
     @GetMapping(path = "/{id}", produces = MediaType.APPLICATION_JSON_VALUE)
    @ResponseStatus(HttpStatus.OK)
    public GetPaymentResponse getPayment(@PathVariable String id)

Is now forcing us to include @PathVariable("id")

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Nov 24, 2023
@bclozel
Copy link
Member

bclozel commented Nov 24, 2023

It sounds like this is linked with the removal of the LocalVariableTableParameterNameDiscoverer in Spring Framework 6.1. You should have gotten warning logs as early as 6.0 about those.

Can you compile your project with -parameters compiler argument? This has been outlined in the second paragraph of this section of the Spring Framework upgrade notes.

If this doesn't work, could you please create a minimal project that reproduces the problem and share it as a git repository or attached as a zip here? Thanks!

@drothmaler
Copy link

Had the same issue. Adding the -parameters issue fixed it for me... Thanks a lot!

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Nov 24, 2023
@bclozel bclozel added status: waiting-for-feedback We need additional information before we can continue and removed status: feedback-provided Feedback has been provided labels Nov 24, 2023
@anogueiraFlywire
Copy link
Author

Hi @bclozel ,
Thanks for the quick reply, and sorry for the late response; I haven't been able to test your suggestion until now and it works like a charm!

@bclozel bclozel closed this as not planned Won't fix, can't repro, duplicate, stale Nov 28, 2023
@bclozel bclozel added status: invalid An issue that we don't feel is valid and removed status: waiting-for-feedback We need additional information before we can continue status: waiting-for-triage An issue we've not yet triaged labels Nov 28, 2023
@bclozel
Copy link
Member

bclozel commented Nov 28, 2023

Thanks for letting us know @anogueiraFlywire !

@anydoby
Copy link

anydoby commented Dec 13, 2023

Here is a little example project where it does not work. --parameters are in place. Does not work in IDE as well. With spring-boot 3.1.4 it works fine.

autowiring.tar.gz

@wilkinsona
Copy link
Member

@anydoby, your app's using an old version of Maven's compiler plugin. The problem does not occur if you use the latest version, 3.11.0.

With spring-boot 3.1.4 it works fine.

With Spring Boot 3.1.4, you see this warning:

[2023-12-13 16:45:10.354] - 55708 WARNING [main] --- org.springframework.core.LocalVariableTableParameterNameDiscoverer: Using deprecated '-debug' fallback for parameter name resolution. Compile the affected code with '-parameters' instead or avoid its introspection: autowiring.Service

This warning when using Spring Boot 3.1.x is also addressed by upgrading the version of Maven's compiler plugin.

@anydoby
Copy link

anydoby commented Dec 13, 2023

@anydoby, your app's using an old version of Maven's compiler plugin. The problem does not occur if you use the latest version, 3.11.0.

With spring-boot 3.1.4 it works fine.

With Spring Boot 3.1.4, you see this warning:

[2023-12-13 16:45:10.354] - 55708 WARNING [main] --- org.springframework.core.LocalVariableTableParameterNameDiscoverer: Using deprecated '-debug' fallback for parameter name resolution. Compile the affected code with '-parameters' instead or avoid its introspection: autowiring.Service

This warning when using Spring Boot 3.1.x is also addressed by upgrading the version of Maven's compiler plugin.

Thank you @wilkinsona. This indeed worked for the simple example. Unfortunately it did not for a real-life one which I have issues with. I'll continue investigating what is causing it.

@oliverwerlen
Copy link

It also very important that you run a mvn clean install (or at least mvn clean verify) after upgrading the maven-plugin.
Otherwise, it won't work as intended.

@StuartBrown1981
Copy link

We noticed this issue going from spring-boot 3.1.X to 3.2.2 and resolved it by updating the maven-compiler-plugin to version 3.12.1

@giovanni-nabil
Copy link

giovanni-nabil commented Mar 17, 2024

As suggested in the error message

Action:

Consider marking one of the beans as @Primary, updating the consumer to accept multiple beans, or using @Qualifier to identify the bean that should be consumed

Ensure that your compiler is configured to use the '-parameters' flag.

adding -parameters to allow this autowiring behavior, in Gradle, would be something like this

compileJava {
   options.compilerArgs.add("-parameters")
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: invalid An issue that we don't feel is valid
Projects
None yet
Development

No branches or pull requests

9 participants