Autowired Environment bean is null if I register AmazonS3 bean with name “amazonS3”

[sivaprasadreddy]

Type: Bug

Component: "S3"

Describe the bug I have a simple SpringBoot 2.3.5, SpringCloud Hoxton.SR8 application with spring-cloud-starter-aws-messaging starter added. I have some configuration class as follows:

@Configuration
public class AppConfig {
   @Autowired
   private Environment env;

   @Bean
   public AmazonS3 amazonS3() {
        AmazonS3ClientBuilder builder = AmazonS3ClientBuilder.standard();
        builder.enablePathStyleAccess();
        AmazonS3 amazonS3 = builder.build();
        return amazonS3;
   }
}

When I run the application the @Autowired environment is NULL. Not only Environment bean but also any @ConfigurationProperties beans also injected as NULLs.

If I rename the bean registration method from amazonS3 to anything say amazonS3Bean then Environment and @ConfigurationProperties beans are properly initialised and is not null.

As pointed out by Spncergibb https://stackoverflow.com/questions/64753747/why-autowired-environment-bean-is-null-if-i-register-amazons3-bean-with-name-am I tried setting spring.main.allow-bean-definition-overriding to true and false but in both cases I am getting the same issue.

Even if it has something to do with bean overriding then there should be an issue registering AmazonS3 bean only, it shouldn't make Environment and @ConfigurationProperties beans as NULL. I feel this behaviour is a bug.

Why amazonS3 name is so special and why it is making Environment bean as NULL?

[maciejwalkowiak]

@sivaprasadreddy this issue has been fixed in 2.2.5 and is already available in Hoxton.SR9.

S3 integration is "special" because it is used to resolve resources path @Resource("s3://....") - when I attempted to do it a usual way, the overwritten bean is created before the environment and any @ConfigurationProperties beans are available. So we decided to do it in not-that-usual-but-working way: https://github.com/spring-cloud/spring-cloud-aws/pull/658

I created a sample repository that tries to reproduce your issue: https://github.com/maciej-scratches/spring-cloud-aws-gh-718 It is the case for Hoxton.SR8, but not anymore for Hoxton.SR9. Please verify if this is the actual problem or maybe there is some other corner case that I missed.

[sivaprasadreddy]

@maciejwalkowiak Verified with Hoxton.SR9 and it's working perfectly fine. Thanks for checking.