On 12/10/2020 13:53, Mark Thomas wrote: > On 12/10/2020 12:49, Mark Thomas wrote: >> On 12/10/2020 12:19, Peter Henderson wrote: >>> Hello fellow tomcat users. >>> >>> My environment. >>> Tomcat: 9.0.39 >>> Java: openjdk 11.0.8 2020-07-14 >>> OS: Ubuntu 18.04.5 LTS >>> >>> Source code [0] >>> >>> When deploying this war [1], by copying it into the webapps directory, >>> I get this exception. [2] >>> java.lang.IllegalArgumentException: Negative time >>> >>> >>> I only started seeing this exception when I upgraded my projects build tool >>> version >>> from >>> sbt.version=1.3.10 >>> to >>> sbt.version=1.4.0 >>> >>> >>> Is this a tomcat bug, a build tool bug or most likely something I'm doing >>> wrong? >> >> Looks like an issue with the dates of files in the WAR. >> >> If you look at the dates of the files in the WAR nearly all of them are >> in the future (07 Feb 2106, 06:28). >> >> It looks like something is overflowing but a Java long shouldn't do that. >> >> Need to dig into exactly what is going on as this looks like it should >> work - even if the WAR contains files created almost a century in the >> future. > > Hmm. I see the 2106 date on the file system and with Java 8 but with > Java 11 I see 1969-dec-31 23:00 which gives -3600000 which triggers the > exception. > > The root cause appears to be in the JRE at this point. Whether it is in > the JRE used to create the WAR or the JRE reading the WAR is TBD. > > I think I am going to have to look at the raw bytes and the zip file > spec to figure out where the root cause is.
That was fun. Per the zip spec, the last modified time on those files is: 1969-Dec-31 23:00:00 UTC i.e. 1 hour before the Epoch at 1970-Jan-01 00:00:00 UTC It is stored as a signed 32-bit int (FFFFF1F0) which is -3600 (zip timestamps are in seconds since the Epoch). Java 8 reads this incorrectly as an unsigned int (4294963696) which, when taken as seconds since Epoch, gives 2016-Feb-07 05:28:16 UTC. (Incidently the archiver that ships with Ubuntu appears to make the same error) Java 11 reads this correctly but Java does not let you set times before the Epoch so the exception is triggered. The short version is that the modification times of the files in the WAR are being set to "1969-Dec-31 23:00:00 UTC" which Java doesn't like. Tomcat could handle this more gracefully but the end result will be the same - the WAR isn't going to deploy. I'm not convinced it is worth doing anything here. It looks like the fix will be somewhere in the build system used to create the WAR. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
