You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When local files (from --path) are copied into the container, they get a last-modified timestamp of 1970-01-01 00:00:00 instead of preserving the timestamp from local.
This causes a problem with spring-boot, which tries to validate the files in an executable JAR file before starting:
Exception in thread "main" java.time.DateTimeException: Invalid value for MonthOfYear (valid values 1 - 12): 0
at java.time.temporal.ValueRange.checkValidValue(ValueRange.java:311)
at java.time.temporal.ChronoField.checkValidValue(ChronoField.java:703)
at java.time.LocalDate.of(LocalDate.java:267)
at java.time.LocalDateTime.of(LocalDateTime.java:336)
at org.springframework.boot.loader.jar.CentralDirectoryFileHeader.decodeMsDosFormatDateTime(CentralDirectoryFileHeader.java:130)
at org.springframework.boot.loader.jar.CentralDirectoryFileHeader.getTime(CentralDirectoryFileHeader.java:119)
at org.springframework.boot.loader.jar.JarEntry.<init>(JarEntry.java:55)
at org.springframework.boot.loader.jar.JarFileEntries.getEntry(JarFileEntries.java:328)
at org.springframework.boot.loader.jar.JarFileEntries.access$400(JarFileEntries.java:48)
at org.springframework.boot.loader.jar.JarFileEntries$EntryIterator.next(JarFileEntries.java:379)
at org.springframework.boot.loader.jar.JarFileEntries$EntryIterator.next(JarFileEntries.java:363)
at org.springframework.boot.loader.jar.JarFile$2.nextElement(JarFile.java:198)
at org.springframework.boot.loader.jar.JarFile$2.nextElement(JarFile.java:189)
at org.springframework.boot.loader.archive.JarFileArchive$EntryIterator.next(JarFileArchive.java:186)
at org.springframework.boot.loader.archive.JarFileArchive$EntryIterator.next(JarFileArchive.java:171)
at org.springframework.boot.loader.archive.JarFileArchive.getNestedArchives(JarFileArchive.java:84)
at org.springframework.boot.loader.ExecutableArchiveLauncher.getClassPathArchives(ExecutableArchiveLauncher.java:70)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:49)
at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:51)
The first file that triggers this is usually META-INF/maven/com.example/java-getting-started/pom.xml, which is the first file the Spring ExecutableArchiveLauncher hits with a timestamp of 1970-01-01 00:00:00
The text was updated successfully, but these errors were encountered:
* This prevents an issue where certain versions of the jdk
cannot parse jar file creation times
[buildpacks/pack#130]
Signed-off-by: Danny Joyce <djoyce@pivotal.io>
Signed-off-by: Andrew Meyer <ameyer@pivotal.io>
* This prevents an issue where certain versions of the jdk
cannot parse jar file creation times
[#130]
Signed-off-by: Danny Joyce <djoyce@pivotal.io>
Signed-off-by: Andrew Meyer <ameyer@pivotal.io>
@jkutner We ended up writing all file times at January 1, 1980 00:00:1. This is because zip files (jars) use MS-DOS format for their file times and the epoch for those is Jan 1, 1980. This prevents a cascading failure with the JDK as noted here: https://bugs.openjdk.java.net/browse/JDK-8184940
Additionally, we wanted to stick to a known date and time for all files with an aim towards reproducible builds.
When local files (from
--path
) are copied into the container, they get a last-modified timestamp of1970-01-01 00:00:00
instead of preserving the timestamp from local.This causes a problem with spring-boot, which tries to validate the files in an executable JAR file before starting:
The first file that triggers this is usually
META-INF/maven/com.example/java-getting-started/pom.xml
, which is the first file the SpringExecutableArchiveLauncher
hits with a timestamp of1970-01-01 00:00:00
The text was updated successfully, but these errors were encountered: