Spring-cloud-aws: s3:// ProtocolResolver registration order

Created on 10 Jul 2018  路  3Comments  路  Source: spring-cloud/spring-cloud-aws

Hi All,

After I migrate from version 1.2.2 to 2.0.0 I have faced a very annoying issue on S3 download feature.
It seems that in version 2.0.0 something has changed related to when the Protocol Resolver that handles "s3://" URIs is registered in Spring Context.
When I try to read any file from S3 during the context loading a FileNotFoundException is thrown.

That issue can be easily reproduced with the following code:

    @SpringBootApplication
    public class Main {

      @Autowired
      private ResourceLoader resourceLoader;

      @Bean
      public Object simpleBean() {

        Resource resource = this.resourceLoader.getResource("s3://anyBucket/anyFile.txt");

        try (InputStream inputStream = resource.getInputStream()) {
            System.out.println(IOUtils.toString(inputStream));
        } catch (Exception e) {
             //An Exception will be thrown
        }

        return new Object();
      }

      public static void main(String[] args) {
        SpringApplication.run(Main.class, args);
      }

   }

Has anyone faced this kind of problem?

Thanks,
Andr茅 Souza

Most helpful comment

You can't do that during bean definition. It's still too early for any container-specific operations.
Anyway it's bad from the remote resource perspective: would be better do not connect to the remote service during application initialization phase.

You should consider to move S3 resources loading to the later phase, e.g. ApplicationRunner or SmartInitializingSingleton, or even into some SmartLifecycle implementation.

Even if that worked for you before, that doesn't mean it was right. The previous version caused some other, more dangerous issues to the application. Right now it is just your approach is wrong, nothing more.

All 3 comments

You can't do that during bean definition. It's still too early for any container-specific operations.
Anyway it's bad from the remote resource perspective: would be better do not connect to the remote service during application initialization phase.

You should consider to move S3 resources loading to the later phase, e.g. ApplicationRunner or SmartInitializingSingleton, or even into some SmartLifecycle implementation.

Even if that worked for you before, that doesn't mean it was right. The previous version caused some other, more dangerous issues to the application. Right now it is just your approach is wrong, nothing more.

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

Was this page helpful?
0 / 5 - 0 ratings