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/AEsComments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
|
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
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.