Spring Spring Core - IoC issue

test.zip

<springBootVersion>2.2.4.RELEASE</springBootVersion>
<springVersion>5.2.3.RELEASE</springVersion>

I uploaded bug in IoC.

Autowired inject bad bean.

@Configuration
@EnableAutoConfiguration
@ComponentScan(basePackages = {"app"})
@Import(value = {})
public class SpringAppConfig {
    @Bean("currentAppDir1")
    public String currentAppDir1() {
        return "test1";
    }
    @Bean("currentAppDir2")
    public String currentAppDir2() {
        return "test2";
    }
    @Bean("currentAppDir3")
    public String currentAppDir3() {
        return "test3";
    }
    @Bean("javaMailSenderMailFromString")
    String[] javaMailSenderMailFromString() {
        return new String[]{"test", "test"};
    }
    public static void main(String[] args) {
        try {
            System.out.println("Start");
            ConfigurableApplicationContext c = new SpringApplicationBuilder(SpringAppConfig.class).web(WebApplicationType.NONE).run(args);
            EmailService test = c.getBean(EmailService.class);
            // !Should be length 2 but it inject currentAppDir1 currentAppDir2 currentAppDir3 not javaMailSenderMailFromString!
            System.out.println(test.javaMailSenderMailFromString.length);
            System.out.println("End");
        } catch (Throwable e) {
            e.printStackTrace();
        }
    }
    @Component
    public class EmailService {
        @Autowired
        //@Qualifier("javaMailSenderMailFromString")
        public String[] javaMailSenderMailFromString;
    }
}

Comment From: sbrannen

I've edited your comment to improve the formatting. You might want to check out this Mastering Markdown guide for future reference.

Comment From: sbrannen

Please note that it is rather unusual to have a bean of type String[].

I have not debugged your example, but I assume that Spring's support for aggregating beans of a given type into a list or array is what is causing the undesired result.

In any case, it appears to me that you are configuring properties as beans. For such use cases, one would typically store them in a properties file (registered via @PropertySource or in the standard application.properties/application.yaml file in a Spring Boot application). The properties can then be consumed via @Value("${property.name}") or via Spring Boot's explicit support for @ConfigurationProperties.

Have you considered those options?

Comment From: PiotrTraczynski

This String is not from properties. It has more complex logic. Ok. We change it to return complex type and it solve. I know know how it work.

pon., 24 lut 2020 o 14:55 Sam Brannen notifications@github.com napisał(a):

Please note that it is rather unusual to have a bean of type String[].

I have not debugged your example, but I assume that Spring's support for aggregating beans of a given type into a list or array is what is causing the undesired result.

In any case, it appears to me that you are configuring properties as beans. For such use cases, one would typically store them in a properties file (registered via @PropertySource or in the standard application.properties/application.yaml file in a Spring Boot application). The properties can then be consumed via @Value("${ property.name}") or via Spring Boot's explicit support for @ConfigurationProperties.

Have you considered those options?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/spring-projects/spring-framework/issues/24579?email_source=notifications&email_token=AOUPXSG5K2S3MFORDDTCQLLREPGV3A5CNFSM4K2DI2DKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMX3VRA#issuecomment-590330564, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOUPXSEQTPVJ3T74BADIMODREPGV3ANCNFSM4K2DI2DA .

-- Piotr Traczyński

Comment From: sbrannen

This String is not from properties. It has more complex logic. Ok. We change it to return complex type and it solve. I know know how it work.

Thanks for the prompt feedback.

Glad to hear that you came up with a working solution!

In light of that, I am closing this issue.