Custom protocols are not honoured when Devtools is active

[snicoll]

See #9331 (comment)

[stoan]

I get the following error if Devtools is active

java.nio.file.InvalidPathException: Illegal char <:> at index 18: src\main\webapp\s3:\swooop\rootFile.log

	at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
	at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
	at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
	at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
	at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
	at java.io.File.toPath(File.java:2234)
	at org.springframework.core.io.FileSystemResource.<init>(FileSystemResource.java:82)
	at org.springframework.core.io.FileSystemResourceLoader$FileSystemContextResource.<init>(FileSystemResourceLoader.java:65)
	at org.springframework.core.io.FileSystemResourceLoader.getResourceByPath(FileSystemResourceLoader.java:54)
	at org.springframework.core.io.DefaultResourceLoader.getResource(DefaultResourceLoader.java:168)
	at org.springframework.mock.web.MockServletContext.getResourceAsStream(MockServletContext.java:345)
	at org.springframework.web.context.support.ServletContextResource.getInputStream(ServletContextResource.java:156)
	at com.housescent.sweeep.SweeepCoreApplicationTests.resourceLoadingMethod(SweeepCoreApplicationTests.java:30)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.springframework.test.context.junit4.statements.RunBeforeTestExecutionCallbacks.evaluate(RunBeforeTestExecutionCallbacks.java:74)
	at org.springframework.test.context.junit4.statements.RunAfterTestExecutionCallbacks.evaluate(RunAfterTestExecutionCallbacks.java:84)
	at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:75)
	at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:86)
	at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:84)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:251)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:97)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
	at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:190)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
	at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)

@RunWith(SpringRunner.class)
@SpringBootTest
public class SweeepCoreApplicationTests {

    @Autowired
    private ResourceLoader resourceLoader;

    @Test
    public void contextLoads() {
    }

    @Test
    public void resourceLoadingMethod() throws IOException {
        Resource resource = this.resourceLoader.getResource("s3://swooop/rootFile.log");
        Resource secondResource = this.resourceLoader.getResource("s3://myBucket/rootFolder/subFile");

        InputStream inputStream = resource.getInputStream();
        //read file
    }

}

[darioseidl]

Yes, this looks like the same problem. As seen in the stack trace, the resource returned is a ServletContextResource and not a SimpleStorageResource. resource.getInputStream() fails then because the ServletContextResource tries to parse s3://swooop/rootFile.log as a relative path, but that's not a valid path.

[L00kian]

From what I could gather - the DefaultResourceLoader#addProtocolResolver is invoked after the devtools resource loader is injected into the GenericApplicationContext. That said GenericApplicationContext#addProtocolResolver adds resolvers to the GenericApplicationContext.this of GenericApplicationContext not the GenericApplicationContext.this.resourceLoader if one set. I would suggest fixing it by overriding the addProtocolResolver in GenericApplicationContext so that it would set the resolver in both itself and the resourceLoader set if any.

@Override
public void addProtocolResolver(ProtocolResolver resolver) {
	super.addProtocolResolver(resolver);
	if (this.resourceLoader != null && this.resourceLoader instanceof DefaultResourceLoader) {
		((DefaultResourceLoader) this.resourceLoader).addProtocolResolver(resolver);
	}
}

@snicoll what do you think about that? I don't feel like devtools is the place that should affect the core code. But it sounds to me like there might be other implications beyond the devtools that might require such behaviour

[snicoll]

I've pushed something in 1ceba09 but I'd like a review first, flagging for team attention.

[snicoll]

I've also created spring-projects/spring-framework#23564 to see if a framework change couldn't make all this more idiomatic.

[wilkinsona]

In the absence of a change to Framework (which I agree could simplify this quite a bit), the proposal for Boot looks good to me.