ResourceLoader with local "file:foo/bar/file.file" reference does not return WritableResource [SPR-16140]

[spring-projects-issues]

Dennis Schmidt opened SPR-16140 and commented

For code example, see attached gist.

When loading a local file with the ResourceLoader, we are expecting the returned resource to be a WritableResource. The code example from the gist is derived from a spring-cloud-aws test where the same behavior as we expect works when loading an S3 resource.

After a brief discussion in the slack channel, Dave Syer suggested this may in fact be a bug. He expects the resource to be returned a FileSystemResource, which should be writable.

---

Affects: 5.0 GA

Reference URL: https://gist.github.com/anonymous/c11fee2d338ed4d984c5e7fa698af6e0

Issue Links:

• ClassPathResource.createRelative is using wrong ClassPathResource constructor for the returned resource [SPR-16146] #20694 ClassPathResource.createRelative is using wrong ClassPathResource constructor for the returned resource

Referenced from: commits 07b479e, b921d56

[spring-projects-issues]

Juergen Hoeller commented

That kind of resource path resolves to a UrlResource, not a FileSystemResource: The latter is only returned from a FileSystemResourceLoader, and even there only for local paths (without a "file:" URL prefix).

I'll see what we can do about this for 5.0.2. I suppose we can simply make UrlResource implement WritableResource since that interface doesn't guarantee writability, it just allows for potential write access... which we'd only support for the "file" protocol then.

[spring-projects-issues]

Dennis Schmidt commented

Interesting. Thansk for the insight. So just for more context on why the behavior we expected would be very beneficial in our case:

On our cloud env we are using S3 for file storages. On dev however we want to avoid the overhead and simply use local file storage. If the default ResourceLoader returned a WritableResource, we could completely hide this detail behind that abstraction. Right now we need to do some clumsy workaround. Not a lot of code, but still clumsy ;)

[spring-projects-issues]

Juergen Hoeller commented

I've introduced a dedicated FileUrlResource subclass which assumes file resolution, to the degree of implementing the WritableResource interface for it. This is the class resolved by DefaultResourceLoader for a "file:..." URL location now, allowing a downcast to WritableResource for it.

For direct construction from a java.io.File or java.nio.file.Path, it's still recommendable to go with the existing FileSystemResource and PathResource classes, respectively.

[spring-projects-issues]

Dennis Schmidt commented

That was fast! Thanks. We'll make use of it as soon as 5.0.2 is out.