eFix (APAR):  WAS_JSP_01-07-2003_5.0.0_cumulative_eFix

Status:  eFix

Release:  5.0.0

Operating System:  N/A

Supersedes eFixes:  

CMVC Defect:  

Byte size of APAR:  131416

Date: Tue Jan 07 14:01:41 EST 2003

Abstract:  WebSphere JSP cumulative eFix 01-07-2003

Description/symptom of problem:  NOTE:  YOU MUST FIRST DOWNLOAD THE EFIX INSTALLER TOOL IN ORDER TO INSTALL AN EFIX.
       The eFix Installer can be downloaded from the following link:
       http://www-3.ibm.com/software/webservers/appserv/support/index.html

Directions to apply efix:  Directions to apply efix:

1) Create temporary 'efix' directory to store the jar file:
             UNIX: /tmp/WebSphere/efix
          Windows: c:\temp\WebSphere\efix

2) Copy jar file to the directory

3) Shutdown WebSphere

4) Follow the eFix installation instructions that are packaged with the eFix Installer on how to install the eFix.

5) Restart WebSphere

6) The temp directory may be removed but the jar file should be saved.  Do not remove 
   any files created and stored in the <WASHOME>/WebSphere/AppServer/efix/<efix> directories.
   These files are required if an efix is to be removed.

Directions to remove efix:  Directions to remove an efix:

NOTE:  EFIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED.  DO NOT REMOVE AN EFIX UNLESS
       ALL EFIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED.  YOU MAY REAPPLY ANY REMOVED EFIX.

Example:  If your system has efix1, efix2, and efix3 applied in that order and efix2 is to be
          removed, efix3 must be removed first, efix2 removed, and efix3 re-applied.


1) Shutdown WebSphere

2) Follow the instructions that are packaged with the eFix Installer on how to uninstall the eFix.

3) Restart WebSphere

Directions to re-apply efix:  

Additional Information:  

 APAR: PQ65763 Version: 400 
 APAR: PQ68502 Version: 500 
      Abstract: 
      ADD EXTENDED DOCUMENT ROOT CAPABILITY FOR WEBAPPS
      Error Description: 
      The current implementation of WAS cannot serve JSPs from web
      applications that store JSPs in JAR files.  WAS expects to
      locate JSPs on the file system inside the war.
      The customer packages their JSPs in JARs that are accessible
      on the application's classpath,and expects the WAS JSP
      processor to serve them.
      Local Fix: 
      Package and deploy all JSPs such that they are distinct files
      located on the file system inside of the war file.
      
      Logically Dependent Apars:  
      Users Affected: 
      WebSphere Application Server installations
      that need the ability to share resources
      across multiple web applications.
      Problem Description: 
      Customer has JSP and static resources
      that are common to a variety of web
      applications and would like to install
      only one copy of each resource on a
      machine.
      Recommendation: 
      
      Problem Summary: 
      WebSphere follows the J2EE model for deploying web
      applications which suggests that all resources should be
      contained within a web application archive (WAR) structure.
      Since customers may have applications that contain reusable
      JSP and static resources, customers are required to place
      copies of each of these resources inside of each WAR.
      This prevents easy maintenance of common JSPs and other
      static resources.
      Problem Conclusion: To allow a resource (JSP and static) to be shared, WebSphere
      has created servlet initialization parameters for both
      the FileServingEnabler and JSP Processor which allows the
      developer to specify a comma delimited list of directories
      and/or jar files as search paths if the requested resource
      cannot be located in the web application archives public
      document tree.
      ==================================================
      This behavior can be enabled via the Application Assembly
      Tool (AAT).
      1) Open enterprise application archive (EAR) inside AAT.
      2) Expand Web Modules
      3) Expand selected Web Module
      4) Expand Assembly Property Extensions
      5) Right mouse click on JSP Attributes or File Serving
      Attributes (depending upon which you choose to use)
      6) Select New
      7)
      option 1.
      name = extendedDocumentRoot
      value = someResource.jar (relative to webapp archive).
      option 2.
      name = extendedDocumentRoot
      value = c:/sharedDir/someResource.jar (absolute reference).
      Note that value accepts a comma separated list that can mix
      both option 1 and option 2.
      
      The following is a sample ibm-web-ext.xmi file demonstrating
      how this feature is enabled for an application that has already
      been deployed.
      parameter name = extendedDocumentRoot
      parameter value = web application archive relative or absolute
      path to resource.
      
      <webappext:WebAppExtension xmi:version='2.0'
      xmlns:xmi='http://www.omg.org/XMI'
      xmlns:webappext='webappext.xmi'
      xmlns:webapplication='webapplication.xmi'
      xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
      xmi:id='WebAppExtension_2' reloadInterval='5'
      reloadingEnabled='true' defaultErrorPage='error.jsp'
      additionalClassPath='' fileServingEnabled='true'
      directoryBrowsingEnabled='true'
      serveServletsByClassnameEnabled='true'>
      <webApp href='WEB-INF/web.xml#WebApp_ID'/>
      <jspAttributes xmi:id='JSPAttribute_1' name='keepgenerated'
      value='true'/>
      <jspAttributes xmi:id='JSPAttribute_2' name='largefile'
      value='false'/>
      <jspAttributes xmi:id='JSPAttribute_3'
      name='extendedDocumentRoot'
      value='testcase.jar, c:/shared/my-test.jar,
      my-test.war/WEB-INF/lib/war_level.jar'/>
      <fileServingAttributes xmi:id='FileServingAttribute_1'
      name='extendedDocumentRoot' value='testcase.jar,
      c:/shared/my-test.jar,
      my-test.war/WEB-INF/lib/war_level.jar'/>
      </webappext:WebAppExtension>
      
      NOTE:  Line item 1657 1911 2164 LIDB1657 LIDB1911 LIDB2164
      Test Comments: 
      Circumvention: 
      Temporary Fix: //wasdoc0/apars/pq65763/4.0.4
      Comments: 









 APAR: PQ67750 Version: 400 
 APAR: PQ68500 Version: 500 
      Abstract: 
      JSPBATCHCOMPILER NEEDS TO COMPILE JSPS IN THE WAR'S WEB-INF DIR
      Error Description: 
      JSPs in the WAR's WEB-INF directory may be forwarded to or
      included.  A forward or include to a JSP in the WEB-INF
      directory will cause a compile of the JSP. Execution of the
      JspBatchCompiler does not currently compile the JSPs in the
      WAR's WEB-INF directory.
      Local Fix: 
      
      
      Logically Dependent Apars:  
      Users Affected: 
      WebSphere Application Server developers
      with JSPs deployed in the WEB-INF directory
      of the WAR file.
      Problem Description: 
      JSPBatchCompiler fails to search
      inside of WEB-INF directory for JSPs.
      Recommendation: 
      
      Problem Summary: 
      User has a Model View Controller (MVC) architecture
      which does not permit JSPs to be directly accessed via
      the client.  This structure requires the JSPs to be located
      inside of the protected non-public directory WEB-INF.
      Since this is a protected directory not part of the
      public document tree, the JSPBatchCompiler did not
      compile JSPs located within this directory structure.
      Problem Conclusion: Removed WEB-INF from the list of restricted directories
      that the JSPBatchCompiler skips compilation for.
      Test Comments: 
      Circumvention: 
      Temporary Fix: 
      Comments: 



 APAR: PQ67983 Version: 400 
 APAR: PQ68503 Version: 500 
      Abstract: 
      PERFORMANCE IMPROVEMENTS FOR JSPBATCHCOMPILER
      Error Description: 
      This APAR is for the propose of obtaining performance
      improvements in the JspBatchCompiler.
      Local Fix: 
      
      
      Logically Dependent Apars:  
      Users Affected: 
      WebSphere Application Server developers
      utilizing the JSPBatchCompiler at deploy
      time.
      Problem Description: 
      JSPBatchCompiler compilation takes
      hours to complete war files that
      contain a large number of JSPs.
      Recommendation: 
      
      Problem Summary: 
      Customers are advised to batch compile JSPs at deploy time.
      If a Web Application Archive contains a large number of JSPs,
      the compilation process creates a large number of
      javac compiler objects (one per jsp) for compiling thus
      degrading performance.
      Problem Conclusion: Modified the JSPBatchCompiler to create only one compiler
      per directory in a WAR file.  This improved performance
      without changing the underlying batch compilation process.
      The new process will first parse the directory of JSPs
      and then compile the list of parsed JSPs.
      Test Comments: 
      Circumvention: 
      Temporary Fix: 
      Comments: 



 APAR: PQ69278 Version: 500 
      Abstract: 
      XML-TYPE JSP 1.2 JSPS DON'T DISPLAY DBCS CHARACTERS PROPERLY
      Error Description: 
      Customer has created an XML-type JSP 1.2 JSP file using DBCS
      characters.  When run through the JSP processor, the DBCS
      characters do not show up properly.  The same logic run through
      the same JSP processor without using the XML-type coding works
      as expected.
      Local Fix: 
      
      
      Logically Dependent Apars:  
      Users Affected: 
      WebSphere Application Server Developers
      using XML Syntax for JSPs.
      Problem Description: 
      DBCS characters are corrupted when
      converted from XML Syntax to a .java
      file.
      Recommendation: 
      
      Problem Summary: 
      XML based JSPs are not checking for the existence of
      a pageEncoding or contentType parameter inside of the
      JSP page directive when creating an XMLReader to parse
      the JSP page.  One of these parameters are required to ensure
      that DBCS characters are properly interpeted when
      converting the .jsp file to a .java file.
      Problem Conclusion: Added logic to check for the page directive for XML based
      JSPs to allow JSPs written in XML to be interpeted the same
      way that HTML based JSPs are handled for DBCS encoded JSPs.
      Test Comments: 
      Circumvention: 
      Temporary Fix: 
      Comments: