DevTools overrides AppContext.resourceLoader causing custom protocol resolvers to be discarded

[JoostK]

Introduction

In SPR-12857 a feature was implemented for registering custom resource protocol resolvers on DefaultResourceLoader, including a setter on ConfigurableApplicationContext to expose this feature to application initializers. When enabling DevTools however a custom ResourceLoader is injected into the application context, hiding the custom protocol resolvers.

Analysis

The issue arrises from code in org.springframework.boot.devtools.restart.ClassLoaderFilesResourcePatternResolver.

Non-web Applications

For non-web applications, a PathMatchingResourcePatternResolver is used with a reference to either the ApplicationContext's resourceLoader, or a new DefaultResourceLoader if that is null:

	private static class ResourcePatternResolverFactory {

		public ResourcePatternResolver getResourcePatternResolver(
				ApplicationContext applicationContext, ResourceLoader resourceLoader) {
			return new PathMatchingResourcePatternResolver(resourceLoader == null
					? new DefaultResourceLoader() : resourceLoader);
		}

	}

Hence the protocol resolvers that are registered onto the ApplicationContext itself are no longer considered. I prepared a PR to change this but unfortunately, using applicationContext itself instead of a new DefaultResourceLoader fails the tests, as circular calls occur when requesting the ApplicationContext's classloader.

Web Applications

For web applications, a custom code path is followed. Again, when a ResourceLoader has been explicitly set onto the ApplicationContext it is used, otherwise a WebApplicationContextResourceLoader is created instead:

	private static class WebResourcePatternResolverFactory
			extends ResourcePatternResolverFactory {

		@Override
		public ResourcePatternResolver getResourcePatternResolver(
				ApplicationContext applicationContext, ResourceLoader resourceLoader) {
			if (applicationContext instanceof WebApplicationContext) {
				return new ServletContextResourcePatternResolver(resourceLoader == null
						? new WebApplicationContextResourceLoader(
								(WebApplicationContext) applicationContext)
						: resourceLoader);
			}
			return super.getResourcePatternResolver(applicationContext, resourceLoader);
		}

	}

This may seem to work as applicationContext is used this time, however it is only used for configuring a ServletContextResource:

	private static class WebApplicationContextResourceLoader
			extends DefaultResourceLoader {

		private final WebApplicationContext applicationContext;

		WebApplicationContextResourceLoader(WebApplicationContext applicationContext) {
			this.applicationContext = applicationContext;
		}

		@Override
		protected Resource getResourceByPath(String path) {
			if (this.applicationContext.getServletContext() != null) {
				return new ServletContextResource(
						this.applicationContext.getServletContext(), path);
			}
			return super.getResourceByPath(path);
		}

	}

As can be seen, the above implementation returns a ServletContextResource without ever consulting the ApplicationContext's custom protocol resolvers. Somehow that feels incorrect, as its parent implementation may have returned an UrlResource as well, for example.

Workaround

I realize now that I can circumvent the problem by setting a new DefaultResourceLoader with the GenericApplicationContext (not ConfigurableApplicationContext unfortunately) from within the initializer and register my custom protocol resolver onto that, as then this resource loader is supposedly kept in the delegation chain:

public class ResourceLoaderInitializer implements ApplicationContextInitializer<GenericApplicationContext> {
	
	@Override
	public void initialize(GenericApplicationContext context) {
		DefaultResourceLoader resourceLoader = new DefaultResourceLoader();
		resourceLoader.addProtocolResolver(...);
		context.setResourceLoader(resourceLoader);
	}
	
}

This potentially introduces another problem however, in that an AbstractApplicationContext registers itself as ResourceLoader in the main BeanFactory and this registration is not reset when a custom resourceLoader is assigned, therefore DI of ResourceLoader will continue to resolve the ApplicationContext itself. I need to file an issue with Spring Context for this, as this is not a Spring Boot problem.

@snicoll I am indeed the one who asked you about this at Spring I/O 😃 Only now did I get around to investigate some more and file this report.

[snicoll]

ResourcePatternResolverFactory shouldn't take both the ApplicationContext and a ResourceLoader as the former is a facade for the latter. I suspect that changing that should fix your issue. I have a patch locally but if you could share a sample that reproduces the problem, that would be quite helpful.

[JoostK]

I pushed a failing testcase to my fork, see JoostK@1d93f42 for commit.

[snicoll]

@JoostK those tests do not reproduce the problems as described. They are overriding the facade (the ApplicationContext) rather than customizing the ResourceLoader. When I change your test to create a custom ResourceLoader and set it to the context, the test pass, e.g.

@Test
public void contextIsUsedAsResourceLoaderInNonWebApplication() throws Exception {
	GenericApplicationContext context = new GenericApplicationContext();
	ResourceLoader resourceLoader = new ResourceLoader() {

		@Override
		public Resource getResource(String location) {
			return new DescriptiveResource("Resource " + location);
		}

		@Nullable
		@Override
		public ClassLoader getClassLoader() {
			return ClassLoaderFilesResourcePatternResolverTests.class.getClassLoader();
		}
	};
	context.setResourceLoader(resourceLoader);
	this.resolver = new ClassLoaderFilesResourcePatternResolver(context, this.files);
	Resource resource = this.resolver.getResource("foo.txt");
	assertThat(resource.getDescription()).isEqualTo("Resource foo.txt");
}

The problem with overriding getResourceLoader in the context directly is that you're not customizing the ResourceLoader the ApplicationContext exposes but rather customizing the context itself. When Devtools switches the ResourceLoader that customization is hardcoded in the context so it will always behaves wrongly.

Given the description above, I can only assume that's a glitch in the test. Can you please revisit it and update your fork?

[JoostK]

When Devtools switches the ResourceLoader that customization is hardcoded in the context so it will always behaves wrongly.

This is exactly what my issue is. I am indeed overriding the ApplicationContext itself because it only works as a facade when GenericApplicationContext.resourceLoader is null, otherwise it uses the resource loading capabilities of its superclass, since GenericApplicationContext derives from DefaultResourceLoader. Therefore, when custom protocol resolvers are registered with the ApplicationContext itself (actually, the DefaultResourceLoader it extends) they fail to be consulted once Devtools injects the custom ResourceLoader. Therefore, I chose to reimplement ApplicationContext.getResource to easily showcase the fact that this method is never called.

You are correct in your suggestion to change the testcase the way you did, as you then implement the workaround I illustrated. What my tests show is that if GenericApplicationContext.resourceLoader is not set, then the ApplicationContext's implementation is not used, therefore its behaviour is lost.

The main problem here is that ApplicationContext in some cases is not just a facade, but an actual implementor of ResourceLoader. If you ask me, a better solution would be to remove DefaultResourceLoader from the inheritance chain of GenericApplicationContext and always delegate to an instance property. This would however be a breaking change and I understand that this cannot be changed at the moment (neither is it in Spring Boot, but in Spring Context).

Is the problem more clear now? Do you need anything else from me to help?