MockServletContext should treat InvalidPathException like an IOException

[Spunc]

I have a simple ConfigurationProperties class that binds a String property to a Path object:

@Component
@ConfigurationProperties("app")
@Getter
@Setter
public class AppConfigurationProperties {
	
	private Path somePath;
}

Then I define app.somePath=C:\\temp within application.properties. This works when running the application, but a simple Test that loads the context throws:

com.example.demo.DemoApplicationTests > contextLoads() FAILED
    java.lang.IllegalStateException
        Caused by: org.springframework.boot.context.properties.ConfigurationPropertiesBindException
            Caused by: org.springframework.boot.context.properties.bind.BindException
                Caused by: org.springframework.core.convert.ConverterNotFoundException

The test class is most simple:

@SpringBootTest
public class DemoApplicationTests {

	@Test
	public void contextLoads() {
	}
}

I created a project with the most recent Spring-Boot version (2.1.8.RELEASE) with Initializr (Gradle build with Spring Web as only dependency) to replicate the problem in isolation. It can be found here. I run the project on Windows 10.

I found out that the test passes, if there are no backslashes in the property value. Furthermore, it passes if I don't use org.springframework.boot:spring-boot-starter-web but org.springframework.boot:spring-boot-starter as dependency. (The test project does not require web, but the actual project does.)

[mbhave]

Thanks for the sample @Spunc. I ran DemoApplicationTests without changing anything and it was green. Is there something additional that needs to be done to reproduce the failure?

[wilkinsona]

It looks like running on Windows is significant. The test fails for me there. We end up with the following:

1. PathEditor setAsText(String) is called with C:\temp
2. ResourceEditor setAsText(String) is called with C:\temp
3. GenericWebApplicationContext (the ResourceLoader) getResource(String) is called with C:\temp
4. A ServletContextResource with the path /C:/temp is created
5. The stack unwinds into PathEditor and it calls exists() on the resource
6. SpringBootMockServletContext getResource is called with /C:/temp
7. MockServletContext getResource(String) is called with /C:/temp
8. SpringBootMockServletContext getResourceLocation(String) is called with /C:/temp
9. MockServletContext getResourceLocation(String) is called with /C:/temp and it prepends the base path and returns src/main/webapp/C:/temp
10. FileSystemResourceLoader getResource(String) is called with src/main/webapp/C:/temp
11. FileSystemResourceLoader getResourceByPath(String) is called with src/main/webapp/C:/temp
12. A FileSystemResource is constructed with src/main/webapp/C:/temp. It creates a File and then calls toPath() which fails with an InvalidPathException

The Windows-specific behaviour is in step 12. The InvalidPathException is not thrown on macOS where a UnixPath is successfully created and returned.

This feels like a bug in MockServletContext getResource(String) to me (which is why the problem only occurs in the tests of a web application). The contract allows the method to throw a MalformedURLException or to return null. The implementation catches IOException and returns null. I think this catch needs to be broadened to map other failures, such as InvalidPathException, to null as well.

@Spunc You can work around the problem by using file:/C:/temp as the value of your app.somePath property.

[Spunc]

Thank you very much for your replies. At first, I was surprised that @mbhave could not reproduce the problem. I had colleagues verify the issue and indeed, those with Windows have the problem while those with Mac-OS are not affected.

Thanks, @wilkinsona for your suggestion of a workaround. We will apply that.

[sbrannen]

Thanks for the great detective work, @wilkinsona!

We'll look into it.