In 1.5.2, the times on the JarEntries for jar files built with the Jar task are rounded up instead of down. When used with, e.g., Weblogic's jspc, this results in the jsps in the jar file being later than the date compiled into the jsp java code, and thus the compiled jsps are ignored. The end result is that when I build with ant 1.5.2, precompiled jsps are ignored by Weblogic. I can see in the code on line 960 of ant/src/main/org/apache/tools/ant/taskdefs/Zip.java, tag ANT_152_FINAL, that 1999 milliseconds are being added to the modification date. ANT_151_FINAL doesn't do this. It appears to me that this is causing the problem. Strangely, we put a sleep in before the jspc task in our ant script and it still doesn't fix the out of date issue that we're having. The only workaround we have is to use 1.5.1 for now.
From the manual of the <zip> task: Please note that ZIP files store file modification times with a granularity of two seconds. If a file is less than two seconds newer than the entry in the archive, Ant will not consider it newer. If Ant was rounding down instead of up, it would always consider the files inside the archive out-of-date and thus always update your archive. I'm changing this to an enhancement request. The possible enhancement I see is a new attribute to control the rounding behavior, but for the reason above, rounding up has to be the default.
Would it not be better to round down on the file lastModified() dates when doing the comparison for the update? It would leave you in a position so that if someone did an update & save within 2 seconds after they did the initial jarring, jar could fail to recognize that the file was updated, but that seems preferable to the current behavior. I suspect that jspc is a very common thing to do for ant users, and with the current behavior jsp precompiling will always fail to be useful at least for weblogic and I suspect for most other jsp engines. The only workaround I know of is to jar the jsp files into your jar, then wait 2 seconds, touch the jsp files, jspc, then update the jar with the compiled jsps. To be very clear about what's happening: My jsps get copied to a working directory; they get a timestamp of e.g. 2137 millis. I do a jspc. The jspc process checks the modification date on the jsp files and embeds it in the compiled jsp so it can check the jsp for staleness. It uses the 2137 as the embedded date. Then I jar all these up into a war file. The jsp timestamp gets bumped to 4000 in the jar file. When I run, the compiled jsp checks to see if it's stale after it's loaded. The modification date it sees on the jsp is 4000, which is after the 2137 which is hard-coded into the compiled jsp, which causes the jsp to be recompiled. Sleeping won't help unless I do a two step jarring process, or I have two copies of the jsps - the ones I compile from and an older version that I actually put in the war file. In either case it's pretty kludgy, and, again, it strikes me as likely to be a problem for lots of people.
I dont know what Jar is up to, but 2seconds is a common feature in some of the comparison tasks, because it is the FAT filesystem's granularity. So a fair few of the tasks assume that if the dest file is < 2 seconds of the date of the source file, it is up to date.
I'd like to further clarify the solution I'm proposing: Instead of adding 1999 milliseconds to the file modification date when you jar the files, change the jar update process to check for (file.lastModified() % 2000 > entry.getTime()) instead of (file.lastModified() > entry.getTime()).
In my book the impact of this bug cannot be overstated: it has cost us hours and hours of developer and QA productivity. Let me say that again, for emphasis: this bug has cost us hours and hours of developer and QA productivity. Every single time we deploy a new WAR, the application servers rebuild the JSP files, either on server startup or page access, depending on the configuration. Multiply this by a dozen people doing dozens of deployments a day, and then think about whether this should be an 'enhancement request' or 'bug'.
*** Bug 23327 has been marked as a duplicate of this bug. ***
hi all, - with Bea's weblogic 5.1 the current behaviour of ant's Zip-Task >=1.5.2 is a bug - i migrated from an older ant-version to the 1.5.4stable, problem occurs in usage of ant's jar-task result was that after the complete deployment of packed webapps in war-achives an server-restart the weblogic-server recompiles every (!) JSP in production-environment. (of course there is for performance reason every recompilation turned off) before live-going of our new deployed version i had to fall back in org/apache/tools/ant/taskdefs/Zip.java form the ...lastModified() + 1999 to the ...lastModified() version. ** File-Date Manipulation in this "hidden" way isn't a good way. ** zip is a zip task and should zip files, nothing else. if you want to change the webapp deployment behaviour, then any additional task parameter should be implemented, but not the core-zip-behaviour. --------------- some more detailled explanation how weblogic handle jsp-compile-times. 1. Bea-Guys compile with theire jspc and generate a timestamp in every generated java-class derived from jsp's original timestamp. Original timestamp was e.g. 2000-01-01 10:01 and that they pack into the generated java-file as java.lang.long in milliseconds (!) 2. at server runtime they check the jsp-file-time in the war-file they compare e.g. 2000-01-01 10:02 (time of the jsp in the archive after running ant's jar task) with the original date (packed in the class at JSP's compile time) and find that 2000-01-01 10:02(JSP-in-warfile-time) is YOUNGER than 2000-01-01 10:01 (original JSP-time) and so the server decides to recompile every JSP one time after deployment. (That is not acceptable in production environment, precompilation of JSPs is here the right way.) 3. ant < 1.5.2 The old zip-behaviour (ant's jar extends zip) created the JSP in above example with date 2000-01-01 10:00. And weblogic StaleIndicator now compares: 2000-01-01 10:00 Jsp-in-warfile-time) is OLDER than 2000-01-01 10:00 (original JSP-time). --- Weblogic's JSP-check is crazy, but acceptable. A zip-task should not manipulate lastModified. I think, this is a bug.
I've added a new roundup attribute that can be used to control the rounding behavior.
*** Bug 29193 has been marked as a duplicate of this bug. ***
I think roundUp="false" should the default for the <war> target, since this is likely to be needed for precompiled JSPs. "true" can remain the default for the <zip> and <jar> targets.
<war> is far older than the roundup attribute, so any change to its default value would break backwards compatibility. Existing build files would suddenly start to behave different after an upgrade of Ant. I don't think that anybody ever wants to set roundup to false in a development environment because of the "Ant always updates my war even if nothing changes" that would be the result. You can always use <presetdef> to change Ant's defaults: <presetdef name="mywar"> <war roundup="true"/> </presetdef> will give you a mywar task that behaves the way you want. If you are willing to live with a Trying to override old definition of task war warning, you can even use <presetdef name="war"> <war roundup="true"/> </presetdef>