Fix (APAR): WAS_Engine_02-07-2003_5.0.0_cumulative_Fix Status: Fix Release: 5.0.0 Operating System: All Supersedes Fixes: WAS_JSP_01-07-2003_5.0.0_cumulative_eFix CMVC Defect: none Byte size of APAR: 1111559 Date: 2003-03-14 Abstract: WAS_ENGINE_02-07-2003_5.0.0_cumulative_efix Description/symptom of problem: WAS_ENGINE_02-07-2003_5.0.0_cumulative_efix contains the most recent changes made to the webcontainer since 5.0.0 was released. Directions to apply fix: NOTE: YOU MUST FIRST DOWNLOAD THE FIX INSTALLER TOOL IN ORDER TO INSTALL A FIX. The Fix Installer can be downloaded from the following link: http://www-3.ibm.com/software/webservers/appserv/support/index.html 1) Create temporary "fix" directory to store the jar file: UNIX: /tmp/WebSphere/fix Windows: c:\temp\WebSphere\fix 2) Copy jar file to the directory 3) Shutdown WebSphere 4) Follow the Fix installation instructions that are packaged with the Fix Installer on how to install the Fix. 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 /WebSphere/AppServer/fix/ directories. These files are required if a fix is to be removed. Directions to remove fix: NOTE: FIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED. DO NOT REMOVE A FIX UNLESS ALL FIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED. YOU MAY REAPPLY ANY REMOVED FIX. Example: If your system has fix1, fix2, and fix3 applied in that order and fix2 is to be removed, fix3 must be removed first, fix2 removed, and fix3 re-applied. 1) Shutdown WebSphere 2) Follow the instructions that are packaged with the Fix Installer on how to uninstall the Fix. 3) Restart WebSphere Directions to re-apply fix: 1) Shutdown WebSphere 2) Follow the Fix instructions that are packaged with the Fix Installer on how to uninstall and reinstall the Fix. 3) Restart WebSphere Additional Information: Repackaged on 03/14/2003 to make use of installers prerequisite feature. Requires the following fixes (These can be applied at the same time as this cumulative fix. There are no shared file dependencies accross these fixes) : WAS_Sessions_02-07-2003_5.0.0_cumulative_eFix PQ70656 -- Servlet 2.3 spec compliancy related to filter & dispatch WAS_Security_02-24-2003_5.0.0_cumulative_Fix Also note that as a result of a change in this cumulative fix, the location of the plugin-cfg.xml file has been moved from the /config directory to /plugins directory. This will require customers to change the webserver configuration file to be modified to point to the new plugin-cfg.xml file. This will be documented in the release notes per the original defect owner when WebSphere 5.0.1 is released. List of included APARS ======================= APAR: PQ69629 Version: 500 Abstract: WAS V5 SERVLET FITERING DEFECT INCORRECT USE OF WRAPPERED RESPONSE AND REQUEST OBJECTS. Error Description: During the WebSphere 5.0 Beta we opened PMR 9398 to track the change in filter invocation by WebSphere. WebSphere had been invoking servlet filters on all jsps when the url-pattern in web.xml is *.jsp and changed to only invoke the filter for the top level jsp, not included jsps. Although the filter invocation change is permanent we discovered that WebSphere was wrapping the request/response of included jsps. The original request/response objects are then no longer visible to the application. We were told this was a known problem and an e-fix would be available after GM. The target was the first week of December. I believe the internal WebSphere defect was 15464. Local Fix: N/A Logically Dependent Apars: Users Affected: WebSphere Application Server developers using servlet 2.3 filtering of requests and response feature. Problem Description: WebSphere is incorrectly wrappering the response and request objects for each dispatch to a resource. Recommendation: Problem Summary: According to the Servlet 2.2 Specification, Servlet Filtering should be done only on the original request and response objects. WebSphere is filtering external and internal servlet dispatches resulting in multiple filters per request and response. Problem Conclusion: Removed additional wrappering done inside of the webcontainer and streamlined the Filtering process. Test Comments: Circumvention: Temporary Fix: Comments: 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. 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: APAR: PQ69282 Version: 500 Abstract: JSP COMPILER RESOLVES CONFICTING CLASSES IN WEB-INF/LIB FIRST RATHER THAN THE CLASSES IN WAS_HOME. Error Description: The JSPBatchCompiler seems to load and use classes in the WAR files WEB-INF/lib directory rather than those for the WAS runtime. . For example if an invalid version of xerces.jar is contained in WEB-INF/lib then the JSPBatchCompliler uses that jar for it's own implementation rather than the WAS runtime classes /lib/xerces.jar Local Fix: Have to import war files without JSP precompilation. Logically Dependent Apars: Users Affected: WebSphere Application Server Developers using the JSPBatchCompiler to compile JSPs. Problem Description: WebSphere defaults to searching the webapp classloader first for classes when using the JSPBatchCompiler. Recommendation: Problem Summary: JSPBatchCompiler incorrectly defines the classloader search order for classes and resources when attempting to batch compile JSPs. Problem Conclusion: Modified the JSPBatchCompiler to allow customer to specify via command line arguments classloader search priority and whether to use single or multiple classloaders per enterprise application. Test Comments: Circumvention: Temporary Fix: temp fix created with debug.. Comments: APAR: PQ70031 Version: 500 Abstract: POST REQUEST WITH QUERY STRING TO SERVLET DOES NOT RETRIEVE PARAMETERS IN QUERY STRING BY REQ.GETPARAMETER(..). Error Description: Post request with query string to servlet does not retrieve parameters in query string by req.getParameter(..). But, req.get QueryString() retrieved the query string which has parameters passed t the servlet. Websphere 5.0 POST parametnames parameter query string Local Fix: Logically Dependent Apars: Users Affected: WebSphere Application Server users that send post data without a content type. Problem Description: WebSphere fails to add query string data to the list of request parameters when receiving a POST request with a content type of null. Recommendation: Problem Summary: User is creating a custom client (ie not using a web browser) to send post requests to WebSphere. Since the custom client is not specifying a content type, WebSphere is not parsing the request parameters properly. Problem Conclusion: Modified WebSphere's implementation of HttpServletRequest to properly handle post requests without a content type. WebSphere will now parse the query string but ignore the post data in the body of the request. Test Comments: Circumvention: Temporary Fix: Comments: APAR: PQ70055 Version: 500 Abstract: HTTP HEAD REQUEST ISN'T PASSING PARAMETERS TO RECEIVING SERVLET RUNNING IN WAS 5 Error Description: Environment: WebSphere Application Server (WAS) 5 . Description: When a HTTP HEAD request which passes parameters is performed (e.g., HEAD http://localhost:8080/HTTPHeadTest/ servlet/HeadServlet?param1=ParamValue1śm2=ParamValue2 HTTP/1.0), in WAS 5 the parameters aren't being passed to the receiving servlet. In WAS 4.0.x, this functionality worked. Local Fix: None. Logically Dependent Apars: Users Affected: WebSphere Application Server developers sending HEAD requests to the application server. Problem Description: WebSphere fails to parse query string for HEAD requests. Recommendation: Problem Summary: WebSphere fails to properly handle HEAD requests. When a HEAD request contains a query string, WebSphere does not parse the query string. This results in null values being returned when application calls HttpServletRequest.getParameter(parameterName). Problem Conclusion: Modified WebSphere's implementation of HttpServletRequest to properly handle query strings for HEAD requests. Test Comments: Circumvention: Temporary Fix: Comments: APAR: PQ70031 Version: 00W Abstract: POST REQUEST WITH QUERY STRING TO SERVLET DOES NOT RETRIEVE PARAMETERS IN QUERY STRING BY REQ.GETPARAMETER(..). Error Description: Post request with query string to servlet does not retrieve parameters in query string by req.getParameter(..). But, req.get QueryString() retrieved the query string which has parameters passed t the servlet. Websphere 5.0 POST parametnames parameter query string Local Fix: Logically Dependent Apars: Users Affected: WebSphere Application Server users that send post data without a content type. Problem Description: WebSphere fails to add query string data to the list of request parameters when receiving a POST request with a content type of null. Recommendation: Problem Summary: User is creating a custom client (ie not using a web browser) to send post requests to WebSphere. Since the custom client is not specifying a content type, WebSphere is not parsing the request parameters properly. Problem Conclusion: Modified WebSphere's implementation of HttpServletRequest to properly handle post requests without a content type. WebSphere will now parse the query string but ignore the post data in the body of the request. Test Comments: Circumvention: Temporary Fix: Comments: APAR: PQ68527 Version: 400 APAR: PQ70412 Version: 500 Abstract: WAS 4.0.2, STRINGINDEXOUTOFBOUNDSEXCEPTION CAUSED BY AN EMPTY VA LUE FOR A COOKIE NAME Error Description: Customer is getting the following error: java.lang.StringIndexOutOfBoundsException: String index out of at com.ibm.servlet.engine.srt.CookieHandler.getCookiesFromString(C ler.java(Compiled Code)) at com.ibm.servlet.engine.srt.CookieHandler.getCookiesFromString(C ler.java(Compiled Code)) at com.ibm.servlet.engine.srt.CookieHandler.getCookiesFromHeaderFie eHandler.java(Compiled Code)) at com.ibm.servlet.engine.srt.SRTServletRequest.getCookies(SRTServ t.java(Compiled Code)) . The error is being caused because a empty value is being passed into a cookie. Local Fix: none Logically Dependent Apars: Users Affected: Any users of WebSphere Application Server version 4.0 with applications using HTTP cookies. Problem Description: Empty cookie names are causing StringIndexOutOfBoundsExceptions to be thrown. Recommendation: Problem Summary: Empty cookie names will return unpredictable values for a request and the use of empty cookie names should be avoided. However, the presence of a cookie without a name should not cause a StringIndexOutOfBoundsException and result in WebSphere Application Server not completing the request. WebSphere is failing while looking for the special cookie names beginning with a "$". Problem Conclusion: A check has been placed in the code for a cookie without a name at all (null), or a cookie with a blank name (a zero length string). If either of these situations occur, we already know cookie is not one of the special "$" cookies and no further processing of the cookie name is needed. Test Comments: Circumvention: Temporary Fix: Comments: APAR: PQ70031 Version: 500 Abstract: POST REQUEST WITH QUERY STRING TO SERVLET DOES NOT RETRIEVE PARAMETERS IN QUERY STRING BY REQ.GETPARAMETER(..). Error Description: Post request with query string to servlet does not retrieve parameters in query string by req.getParameter(..). But, req.get QueryString() retrieved the query string which has parameters passed t the servlet. Websphere 5.0 POST parametnames parameter query string Local Fix: Logically Dependent Apars: Users Affected: WebSphere Application Server users that send post data without a content type. Problem Description: WebSphere fails to add query string data to the list of request parameters when receiving a POST request with a content type of null. Recommendation: Problem Summary: User is creating a custom client (ie not using a web browser) to send post requests to WebSphere. Since the custom client is not specifying a content type, WebSphere is not parsing the request parameters properly. Problem Conclusion: Modified WebSphere's implementation of HttpServletRequest to properly handle post requests without a content type. WebSphere will now parse the query string but ignore the post data in the body of the request. Test Comments: Circumvention: Temporary Fix: Comments: