ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 17934] - Dates too late in jar entries
Date Tue, 25 Nov 2003 21:55:37 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17934>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17934

Dates too late in jar entries





------- Additional Comments From thomas@jprog.de  2003-11-25 21:55 -------
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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message