Spring's AbstractResource (used in spring-mvc) is unusable in Docker. [SPR-12862]

[spring-projects-issues]

Nicholas Wertzberger opened SPR-12862 and commented

It appears that Spring does a sanity check on the lastModified date of files before using them with the AbstractResource class.

When using spring templates to render a UI for an html page, this sanity check fails on docker images, which appear to have a lastModified date of Jan 1, 1970 (an epoch time of 0L).

This means that no spring-mvc app works in a docker container without some echo -n >> /path/to/file's (totally ruining the point) to start up the container.

Here's the failing line:
http://grepcode.com/file/repo1.maven.org/maven2/org.springframework/spring-core/4.1.4.RELEASE/org/springframework/core/io/AbstractResource.java?av=f#152

P.S. I also have a bug with docker to not have a last modified of NEVER, but it seems weird that you would fail completely on this.

---

Affects: 4.1.4

Reference URL: http://stackoverflow.com/questions/29337432/spring-templates-in-docker-container/29337588#29337588

Issue Links:

• HTTP 404 for static resources with last modified = 0L (breaks Docker images build with Jib) [SPR-17320] #21853 HTTP 404 for static resources with last modified = 0L (breaks Docker images build with Jib)

1 votes, 5 watchers

[spring-projects-issues]

Brian Clozel commented

For reference, here's the Docker issue you opened as well: moby/moby#11916

[spring-projects-issues]

Juergen Hoeller commented

Note the javadoc on java.io.File.lastModified():

@return A <code>long</code> value representing the time the file was last modified,
measured in milliseconds since the epoch (00:00:00 GMT, January 1, 1970), or
<code>0L</code> if the file does not exist or if an I/O error occurs

A 0 return value from that method indicates non-existence or an I/O error, which is why we turn it into an exception. I suppose we could do extra checks for whether the file actually exists, but fundamentally, this silly java.io.File API just uses 0 as an indicator for I/O failure and we can't differentiate between resolution failure and a real 0 value.

I'm afraid this will have to be fixed in Docker, since relaxing our check would lead to false 0 values for non-accessible files :-(

Juergen

[spring-projects-issues]

Nicholas Wertzberger commented

From a triaging standpoint, I have shoved a command to touch these files on startup, so spring now works, with a little bit of a shim.

[spring-projects-issues]

Brian Clozel commented

So this behavior is by design in the JDK and in Docker (the docker github issue has been closed).

In the meantime, our Spring Boot + docker getting started guide does warn about this issue and recommends a touch command.

[spring-projects-issues]

Stephen Todd commented

It appears that with spotify/docker-maven-plugin#58, this is no longer an issue. The Spotify docker-maven-plugin now preserves modification dates of the files. That means that the touch command when using this plugin is no longer required. The guide probably ought to be updated.