This is a discussion on JSPs recompile in different time zone - Weblogic ; I'm using WLS 7.0.2, JDK 1.4.1_b01, and running on Win 2000. I'd deploying a .ear that contains a .war that contains precompiled JSPs. When I deploy this to a timezone that is behind the one in which the .war was ...
I'm using WLS 7.0.2, JDK 1.4.1_b01, and running on Win 2000. I'd deploying a .ear
that contains a .war that contains precompiled JSPs. When I deploy this to a timezone
that is behind
the one in which the .war was created my JSPs get recompiled when accessed, and
I know why. Is my understanding correct, and if so is there a solution, or is
this a bug in the JDK, WLS, or somewhere else?
When the JSPs get precompiled jspc inserts into the JSP .class files methods _isStale
and _staticIsStale, which contain a timestamp that appears to be the last modification
date of the
JSP from which the .class was generated. When the JSP gets accessed after WLS
WLS compares this timestamp with the last modified date of the .jsp that is in
the the .war.
If the timestamp ffrom the _*Stale method is before the last modified date of
the .jsp WLS
recompiles the .jsp.
The problem seems to occur because the last modified date of the .jsp is not adjusted
to the timezone in which you're running. So, if you're in a timezone that is 'behind'
the timezone in which the .zip was created the timestamp in the _*Stale method
is always before the last modified date. For example, if the .war is created in
the US East-coast timezone and the last modified date of the .jsp has time 10:20:30
when the JSP is precompiled then a timestamp containing 10:20:30 (or actually,
the number of milliseconds that 10:20:30 is since the GMT epoch) is placed in
the *Stale method, and the last modified date is attached to the .jsp in the .war.
When deployed in the US Pacific coast timezone, which is 3 hours behind
the east coast, the *Stale method's timestamp is interpreted as 7:20:30, but the
last modified date attached to the .jsp in the .war is retrieved by WLS using
java.util.zip.ZipEntry.getTime and is still 10:20:30, so the .class is obsolete
and the .jsp is recompiled.
How is the time attached to the .jsp in the .war? If it's a UTC then the timezone
you're in should be irrelevant. I noticed that if I open the .war in WinZip files
always show the same date
irregardless of which timezone the PC I'm opening the .war is in, which seems
to imply that
the last modified date in the .war is absolute, not UTC.
I also noted a bug posting at Sun that ZipEntry may have problems when used in
an OS, like Windows, that uses local, and not universal, time, but no additional
explanation was forthcoming.
So at this point I'm looking for deeper understanding, and whether there's a way
to keep the JSPs from recompiling when deployed in a timezone that's behind the
one the deployment archive was created in.