PQ56068: JSP WITH DATE OLDER THAN .CLASS FILE IS ADDED TO WAS. THE CHANGED JSP IS NOT BEING COMPILED. JSP FUNCT. IS STILL FROM PREVIOUS.

APAR status
Closed as program error.

Error description
APAR:
Customer reports WAS AE 4.0.1 functionality not working
according to the following WAS AE 4.0.1
infocenter references:
-
"6.5.1: Hot deployment and dynamic reloading"
Change an existing JSP File
-
User Action: None
Comments: The changed JSP can be placed directly in the
product_installation_root/installedApps/<app name>/<module name>
directory, or the appropriate subdirectory. The change will be
automatically detected and the JSP will be recompiled and
reloaded.
-
"4.2.2.1: JavaServer Pages (JSP) lifecycle"
When the Web container receives a request for a JSP file, the
engine checks to determine whether the JSP file (.jsp) has
changed since it was loaded. If it has changed, the Web
container reloads the updated JSP file (that is, generates an
updated Java source and class file for the JSP). The newly
loaded servlet instance receives the client request.
-
Customer also references the book "Desigining Enterprise
Applications with the Java 2 Platform, Enterprise Edition" by
Nicholas Kassem which is stamped with Sun approved and signed by
Scott McNealy.  Page 79 in book states "When a Web designer
changes a JSP page, the page is automatically recompiled and
reloaded into the Web server."
-
In short customer indicates that the documentation
states that a changed .jsp file will be picked up
and compiled.  The operative word is "changed".
They state that the sole condition for recompiling
a .jsp according to the documentation is whether
it has changed.
-
Currently they indicate that the .jsp's file date must be more
recent than the .jsp's .class file date for the changes to take
affect.  The believe this is not in accordance to what the
documentation states.
-
This issue causes the customer problems in different scenarios.
These scenarios are compounded by the fact that customer has
50-80 servers to maintain.  Some of the problem scenarios
include:
-
1) Consider the case of when a WebSphere is installed or the
JSP's .class files are removed on Jan. 2, 2002.  Then on
Jan. 10, 2002, .jsp files are added to the system that were
developed in the year 2001.  These newer JSPs will not be
picked up by the system.
-
2) The customer site includes JSPs that are coded and JSPs
that are generated on a regular basis.  The JSPs generated
are often news items that are created and pushed out to the
system multiple times a day.  Thus some JSPs are created
at a time before the previous JSP was pushed to server and
compiled.  Thus when the newer JSP are pushed to the server
it's changes are not picked up.
-
3) There are times when the customer pushes JSP changes out to
the servers only to find out they need to revert back to the
previous JSP.  When they revert back, the old JSP change is
not reflected until they delete the .class files.
Local fix
Customer must delete his temp directory files to ensure his
JSPs will compile.  This impacts customers performance.
Problem summary
****************************************************************
* USERS AFFECTED: WebSphere Application Server Developers      *
*                 using jsps.                                  *
****************************************************************
* PROBLEM DESCRIPTION: Replacing jsp files with jsp files      *
*                      that have a last modified timestamp     *
*                      older than the one it is replacing      *
*                      will not be compiled.                   *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
Jsp processor checks the last modified timestamp of the jsp
file to determine if the current jsp file is newer than
the compiled class file that WebSphere is currently
using in its classloader.  If the file is older than
the compiled class file, then WebSphere does not recompile
the jsp.  This behavior does not properly handle all of the
current Java 2 Enterprise Edition methods for deployment
of jsps.
Problem conclusion
Change made to the jsp processor algorithm for determining
when a jsp is outdated. Oudated check now accounts
for the various deployment methods WebSphere currently uses.
Temporary fix
//wasdoc0/apars/pq56068/4.0.2/ AE/AEs
Comments
APAR information
APAR number PQ56068
Reported component name WEBSPHERE AE NT
Reported component ID 5630A2201
Reported release 400
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Submitted date 2001-12-18
Closed date 2002-01-22
Last modified date 2002-02-12

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros
JSP          

Fix information
Fixed component name WEBSPHERE AE NT
Fixed component ID 5630A2201

Applicable component levels
R400 PSY    UP


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ56068
IBM Group: Software Group
Modified date: Feb 12, 2002