Skip to content
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

Add support to enhance default resource loader [SPR-12857] #17455

Closed
spring-projects-issues opened this issue Mar 27, 2015 · 4 comments
Closed
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Mar 27, 2015

Agim Emruli opened SPR-12857 and commented

There are a few implementations of the resource loader already available that support custom protocols like S3 (https://github.com/spring-cloud/spring-cloud-aws/blob/master/spring-cloud-aws-core/src/main/java/org/springframework/cloud/aws/core/io/s3/PathMatchingSimpleStorageResourcePatternResolver.java) and HDFS (https://github.com/spring-projects/spring-hadoop/blob/master/spring-hadoop-core/src/main/java/org/springframework/data/hadoop/fs/HdfsResourceLoader.java)

that can not register easily within the application context. It would be great if the Spring Framework would allow to register some custom ResourceLoader so that the default one can be overriden and then used by the beans.

Currently it is hard / not possible to override the resource load if the user is using a ClasspathXmlApplicationContext (or any context that does not extend GenericApplicationContext).


Affects: 4.1.6

Issue Links:

Referenced from: commits 0dff782, 37de0b2

0 votes, 7 watchers

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Feb 11, 2016

Juergen Hoeller commented

I've added an SPI called ProtocolResolver with the following signature:

Resource resolve(String location, ResourceLoader resourceLoader)

allowing for resolving a custom protocol if known, or null otherwise.

Any number of such resolvers can be registered with a DefaultResourceLoader and therefore any AbstractApplicationContext subclass, preserving that loader/context's standard resolution rules while individually handling custom protocols. Replacing the entire ResourceLoader would bypass the path resolution assumptions that some context implementations make... or suggest several variations of such custom ResourceLoader implementations with different path resolution rules, which isn't ideal either.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Aug 28, 2016

Petar Tahchiev commented

Hello,

I tried to register my own ProtocolResolver in my spring-boot application like this:

@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
    if (!registry.hasMappingForPattern("/media/**")) {
        applicationContext.addProtocolResolver(new MediaProtocolResolver());
        registry.addResourceHandler("/media/**").addResourceLocations("media:/media/").setCacheControl(CacheControl.maxAge(365, TimeUnit.DAYS));
    }
    super.addResourceHandlers(registry);
}

and then I try to load media /media/a.jpg, however the execution flow never goes through my MediaProtocolResolver .. Can you tell me what am I doing wrong? I also tried to search the official documentation but I couldn't find anything on the topic.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Sep 5, 2016

Brian Clozel commented

Hello Petar Tahchiev

The current resource handling infrastructure relies on chains of ResourceResolvers and ResourceTransformers.

I believe you can register and order your own resolvers and transformers to achieve this goal. Currently, the last ResourceResolver of the chain is by default the PathResourceResolver, which resolves resources by trying to create resources relative to the configured locations. Of the resource exists, it is considered as resolved.

In your case, you could create your own ResourceResolver implementation and configure it in the chain. You can even use a DefaultResourceLoader with custom ProtocolResolvers if this might help you.

If you can think of something we can improve with the current PathResourceResolver implementation, let us know by creating a new issue so we can discuss things there.

Thanks!

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Oct 18, 2016

roll tide commented

This looks like fantastic addition. I am in need to extend the existing PathMatchingSimpleStorageResourcePatternResolver.java as Resource does not expose some of the S3 metadata. Since the Resource class defined in AWS package is final, easiest way for me to extend that was to create custom protocol for ex: "s3c://" and was hoping to find quick way to do that.

I am using Spring Boot v1.3.5 and Spring Core v4.3.3 so I was hoping to use this feature but I may be configuring it incorrectly. Is there specific example for reference? I create bean of type DefaultResourceLoader in configuration and add new ProtocolResolver for "s3c://" but it does not seem to use new ProtocolResolver to resolve the resource.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants