spring scanning same type bean with different names returning ambiguous exception after upgrading to spring-boot 3.2

[VelDeveloper]

Hi,

I recently upgraded my application to spring-boot 3.2 from spring-boot 3.0.x. After upgrading we are getting several bean ambiguous exceptions. This was working fine before.

The Application is consuming several client libraries and each client library is creating RestTemplate using the below code.

@RequiredArgsConstructor
@AutoConfiguration
@ConfigurationPropertiesScan
@ComponentScan(basePackages = {"com.partner.tracker.client"})
public class TrackerClientConfiguration {

	@Autowired(required = false)
	private RestTemplateCustomizer restTemplateCustomizer;
	
	@Bean(name = "trackerRestTemplate")
	@ConditionalOnMissingBean(name = "trackerRestTemplate")
	public RestTemplate trackerRestTemplate() {
		return createTrackerRestTemplate();
	}

	public RestTemplate createTrackerRestTemplate() {
		RestTemplateBuilder restTemplateBuilder = new RestTemplateBuilder()
				.requestFactory(this::customHttpRequestFactory)
				.interceptors(
						getDefaultHeadersInterceptor(),
						getTraceIdInterceptor()
				)
				.messageConverters(getMessageConverters());
		if (Objects.nonNull(restTemplateCustomizer)) {
			restTemplateBuilder = restTemplateBuilder.additionalCustomizers(restTemplateCustomizer);
		}
		return restTemplateBuilder.build();
	}
}

We are using the same code for other 5-libraries RestTemplate creation.

This was working fine till we upgraded to spring-boot 3.2, but we got the below exception after upgrading to 3.2.

Parameter 1 of constructor in com.tracker.client.TrackerApiClient required a single bean, but 6 were found:

- ulfRestTemplate: defined in file <file location>
- trackerRestTemplate: defined in file <file location>
- homeRestTemplate: defined by method
- pluginRestTemplate: defined by method
- partnerRestTemplate: defined by method
- goRestTemplate: defined by method

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

So we are using @Qualifier annotation temporarily to fix this issue, but I don't want to do that since it breaks unit testing. Also I use Lombok for constructor injection. Now I should go with manual constructor with @Qualifier annotation.

So this bug was recently introduced by the spring team or is this how Spring always works for the same type of bean? If this is the usual behavior then I wonder how it works in the past.

Any help would be really appreciated.

[sbrannen]

Since Spring Framework 6.1 / Spring Boot 3.2, you must compile your code with -parameters.

See the this section of the upgrade notes for details.

In addition, you should have seen a warning in the logs stating this with 6.0.x.

I am therefore closing this issue.

However, if -parameters does not resolve the issue for you, please provide additional feedback here.

[VelDeveloper]

@sbrannen Thank you for your prompt reply. I updated the "-parameters" flag in IntelliJ for 3-projects. In the 1st project, everything is fine and it doesn't require @qualifier annotation. In another project, everything works except it cannot Autowire Environment bean so I manually defined one. In another project which is a multi-module spring project "-parameters" in IntelliJ doesn't work at all and the issue remains the same.

Note: All the projects are using spring-boot 3.2 and Java-17. Is there any reason why we removed it?