-
Notifications
You must be signed in to change notification settings - Fork 37.7k
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
DependencyDescriptor#getDependencyName() returns null in 6.1.2, but not 6.0.x or earlier #31998
Comments
This looks like you are missing the See the note in https://github.com/spring-projects/spring-framework/wiki/Upgrading-to-Spring-Framework-6.x |
Indeed it was! The description in Parameter Name Retention for 6.1 was spot on. No idea why this wasn't an issue in the reproduction, but I won't bore you with that. Thanks! Hopefully all the details should guide some other unlucky soul to the solution 😄 No amount of googling, reading/searching for Github issues in Spring and reading of Changelogs (the wrong ones, it turns out) helped us find the issue, so leaving a trace.
|
This was not a problem with the repro project because Spring Boot configures the parameters flag by default with the maven compiler plugin. |
Not quite. That wasn't the case, as I was duplicating the configuration of the production setup having issues, where the beans in question were set up (and compiled) in a dependency that had nothing to do with Spring Boot (it just depended on Spring). The real issue with the repro was that while I did create multiple beans, I never had the issue where there were multiple candidates for parameter injection, only field injection, so it did not exercise the same code. Once I knew that the issue was really about matching on parameter name, I simplified the whole repro into just having the code to show the issue. Thanks anyhow! We struggled quite a bit with this 👍 |
Affects: 6.1.2
It is not present in
spring-framework
version 6.0.15 (shipped with Spring Boot 3.1.7)When upgrading from any Spring Boot 3.1 version (tried 3.1.2 and 3.1.7) of Spring Boot to Spring Boot 3.2 (both 3.2.0 and 3.2.1 tried) our tests break with issues such as
expected single matching bean but found 2: clientAdminDataSource,dataSource
orexpected single matching bean but found 2: clientAdminTemplateJdbcTemplate, jdbcTemplate
. This has worked through all Spring Boot versions up until 3.2.0I then went and tried to reproduce the issue, thinking the issue was that autowiring in 3.2.0 somehow was not excluding the
@Configuration
bean that was set to be excluded in our@TestConfiguration
bean, thus ending up with multiple candidate beans. The reproduction (at fatso83/issue-reproductions/spring-3.2.0-autowire-issue) failed to display the issue, which forced me to do some more debugging, comparing test runs in 3.1 and 3.2. It turns outMy attempt at reproducing was unsuccessful, so my only clues must be in what is different.
The main difference I can see is that in our production setup, the beans that fails to map up are either
DataSource
's orJdbcTemplates
. So type/class seems to matter somehow. Both of these types have@Bean
's supplied by Spring itself (the default ones). This is of course not the case for myFoo
andBar
classes in the repro.Where the bug manifests in Spring:
DefaultListableBeanFactory#determineAutowireCandidate()
.When
DefaultListableBeanFactory#doResolveDependency()
calls that method the code looks like this:In Spring 3.1.7 (and 3.1.2),
autowiredBeanName
returns one bean. In Spring 3.2.0 and 3.2.1, it returnsnull
. The reason is this code:descriptor.getDependencyName()
returns null in 3.2, but not 3.1, so naturally this fails.It was at this point I got dizzy trying to debug this, diving further into a rabbit hole I had no idea where was going, so
that's when I gave up and just submitted the bug without knowing what goes wrong.
The text was updated successfully, but these errors were encountered: