eFix (APAR): PQ60657 Status: efix Release: WebSphere 4.0.2, 4.0.3 Supersedes eFixes(server): PQ56389, PQ57046, PQ55897, PQ56429, PQ59006, PQ56901, PQ59756, PQ60064, PQ60796, PQ60843, PQ61172, PQ62333 Supersedes eFixes(client): PQ58248, PQ56639, PQ60772 CMVC defect: PQ60657 Byte size of APAR: Date: 07/01/2002 Abstract: In multi-node environment using remote console, EAR files fail to expand yet console indicates successful installation. Error Description: In multi-node environment When using a remote admin console to install an Ear file that is local to the adminserver the adminclient is connecting to, the final screen informs the user that the file is local to the install node and will be expanded in the installedApps directory. This however does not occur. The application is visible in the console, but will not run properly because the code has not been expanded into the installedApps directory. The error "CNTR0020E" appears when trying to start or access info on the i nstalled application. Customer receives feedback that the instal l was successful, without being told that the EARexpander has to be ran against the EAR file before the application is fully installed. This is a false positive. With this fix, expanding the EAR file will be determined only by: node on which EAR file resides and node on which EAR file is to be expanded are same, node on which admin server is running will not be a factor! As a result customer can have local console connect to local adminserver and install EAR on remote nodes in the multi-node cluster without needing to manually expand the EAR. If EAR file resides on a node other than the one intended to install on, user will need to manually expand the EAR on the intended node. This is the expected behavior of WebSphere. A console provides message to inform customer. ************************** NOTE: ************************** This fix applies to both the admin server and GUI console, as a result instances of WebSphere with eFix PQ60657 will introduce client/server incompatibilities with instances WITHOUT eFix PQ60657 when installing EAR. When applying this eFix, it is recommended customer apply it to all instances of WebSphere AE 4.0.2 in the environment. Behaviors customers can expect to see between NEW (PQ60657 applied) and OLD (no PQ60657) client/server: - NEW client remote-connect to OLD server: - install EAR on appserver located on OLD server: -> console msg indicates auto expansion, but exceptions thrown, console popup critical error - install EAR on appserver located on NEW server: -> correct console msg, installation succeeds - old client remote-connect to new server: - install EAR on appserver located on NEW server: -> console indicates success, yet no expansion - install EAR on appserver located on OLD server: ->console msg indicates manual expansion necessary, however expansion succeeds - OLD client local-connect to OLD server: - install EAR on appserver located on NEW server: -> console indicates success, yet no expansion - install EAR on appserver located on OLD server: -> working as before - NEW client local-connect to NEW server: - install EAR on appserver located on OLD server: -> console indicates auto expansion, however popup critial error, installation fails - install EAR on appserver located on NEW server: -> working as before ************************************************************ Directions to apply efix: 1) Create temporary "efix" directory to store the jar file: AIX: /tmp/WebSphere/efix Solaris/Linux: /tmp/WebSphere/efix Windows: c:\temp\WebSphere\efix 2) Copy jar file to the directory 3) Shutdown WebSphere 4) Run the jar file with the following command answering questions/prompts as they appear: java -jar 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/efix/ directories. These files are required if an efix is to be removed. 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) Change directory to the efix location (/WebSphere/AppServer/efix/). 2) Shutdown WebSphere 3) Run the backup jar file with the following command: java -jar 4) Restart WebSphere Directions to re-apply an efix: Follow the instructions for applying an efix. If the backup files still exist (from the previous efix application), you will be prompted to overwrite. Answer "yes" at the overwrite prompts. Additional Information: ------------------------------------------------------------------ This is a cumulative efix. In addition to the description above, applying this efix solves the following problems: (From PQ56429) Abstract: Must set both java.library.path and Environment Path to access .dll or .so files from a JNI Abstract: DataSource name stored as JNDI name, and java.lang. ClassNotFoundException: com.ibm.ejs.cm.CMPropertiesRefAddr occurs Description/symptom of problem: Path information set in Environment path was not added to the java.library.path (From PQ55897) Abstract: Optionally suppress ear expansion after application installation. Description/symptom of problem: When an enterprise application (.ear file) is installed on WebSphere domain, the ear file is automatically extracted (expanded) in $WAS_ROOT/installedApps directory only on that machine which the admin client is connected to and the admin server is running on. This eFix introduces an option such that the ear file is not extracted at all. The option is set in $WAS_ROOT/bin/admin.config file as com.ibm.ejs.sm.adminServer.autoExpandEarfile=false If this option is not present or set to any value other than false then the ear file is expanded. If present, and set to false then the ear file is not expanded on any node. In such a case it is deployer's responsibility to extract the ear file in $WAS_ROOT/installedApps directory (under proper directory structure using EARExpander tool) BEFORE the application is installed. (From PQ57046) Abstract: DataSource name stored as JNDI name, and java.lang. ClassNotFoundException: com.ibm.ejs.cm.CMPropertiesRefAddr occurs Description/symptom of problem: This efix fixes 2 problems. 1) In JNDI, The JNDI name of each DataSource is stored as the DataSource name, rather than the DataSource name specified. This is most apparent in the 4.0.2 Resource Analyzer, where the name of the sample DataSource is " jdbc/SampleDataSource", instead of its correct "SampleDataSource". 2) When upgrading from 4.0.1, each DataSource used is converted to a new format. Sometimes this conversion does not occur, resulting in a ClassNotFoundException: com.ibm.ejs.cm.CMPropertiesRefAddr. To fix existing datasource effected by this problem, a manual step is required. Use WSCP to execute the tcl script which was created into the /WebSphere/AppServer/bin directory; this will rebind all DataSources, which 1) fixes existing DataSources to not store the JNDI name as the DataSource name, and 2) forces all DataSources to be converted to the 4.0.2 version. For example: wscp -f rebind_datasources.tcl (From PQ56389) Abstract: Web Container failover - stopping server returns 404 errors Description/symptom of problem: While running load at a cloned application, one of the clones is stopped from the admin console. Expected behavior is that requests on the clone should complete while new requests should be routed to other servers. Actual behavior is that a series of requests return 404 errors from the stopping web container. The number of these requests depends upon how long it takes for the application server to complete its stop. (From PQ59006 ) Abstract: This fix makes the Admin Server retry starting the Application Server a specified number of times. Description/symptom of problem: If an Application Server is detected to go down, the Admin Server tries to start it again. If this attempt fails (for example, if the repository database is down), no more attempts are made to restart the Application Server. This fix makes the Admin Server retry to start the Application Server a specified number of times. The default is to retry 5 times in 60 second intervals. This can be modified by adding lines into admin.config as follows: com.ibm.ejs.sm.adminServer.nannyThread.maxRetries= com.ibm.ejs.sm.adminServer.nannyThread.waitTime= The app server start will retry forever if a negative number is set as . (From PQ56901) Abstract: eFix fix problem of not able to view deployment descriptor from admin console Description/symptom of problem: Doing an import of an xml file that contains a enterprise app. The xml file does not have the .ear extension for ear-install-directory. The import complets successfully and the app functions properly. However if you go on the console and right click on the enterpriseapp and do a view for the deployment descriptor then you will see the com.ibm.ejs.util.cache.NoSuchObjectException exception. (From PQ59756) Abstract: Under WAS AEs, the serverStopping() is called prior to the server actually stopping, but in AE, the serverStopping() is called after parts of the WebSphere server are shutdown (ORB, container). Description/symptom of problem: Under WebSphere Standard Edition (all 4.x versions) the serverStopping() method is called prior to the Server actually stopping -- that is all services and containers are still running including the EJB container, the Servlet container, and Database connections. This allows the Custom Application logic to receive notification that the server has been requested to shutdown, and then to perform any clean up needed before the server starts it's shutdown. When the servers shutdown is complete, the Custom Service is notified through the serverStopping() method. Under WebSphere Advanced Edition, the serverStopping() method appears to be being called after parts of the WebSphere Server are shutdown. This prevents the Application Logic in the Custom Service from doing the needed cleanup - this case contacting a Stateless EJB which then interacts with an Entity Bean to clean up information stored in the database. (From PQ60064) Abstract: If a 4.0.1 client (Admin Console or wscp) is connected to a 4.0.2 or later server, the DataSource password is seen in plain text. Description/symptom of problem: This eFix encodes the DataSource passwords in the repository so that clients will not be able to read the passwords. Since this change modifies persistent data, the rebind_datasources.tcl script from PQ57046 should be run to actually encode the data, although simply installing the eFix will show the password as encoded from the Admin Console and wscp. Note that this eFix is being provided for security concerns only; attaching a client from an earlier version to a server of a later version is not a supported configuration. (From PQ60796) Abstract: The subdirectory under installedApps is not removed when uninstalling an enterprise bean on AdminConsole, XML and WSCP. Description/symptom of problem: On WAS 4.0.2 using XML, WSCP, or Admin Console, deploy an Enterprise Application. . At some point the need to remove the Enterprise Application and WAS is not removing the subdirectory under /InstalledApps. It can also be removed by any of three methods (XML, WSCP, Admin Console) and you receive the same results. . This causes problems when they try to update the Application as there is old information left on their systems. (From PQ60843) Abstract: Cannot use the nodename property, the ear file not expand properly. Description/symptom of problem: For configuring WAS on a machine with multiple NIC's, add the following line to the admin.config file: com.ibm.ejs.sm.adminServer.nodeName=mydevnode Everything looks fine, the node name is mydevnode However, when I install an Enterprise Application the files do not get installed into /usr/WebSphere/AppServer/installedApps. (From PQ61172) Title: CANNOT DISABLE HP-UX JDK HOTSPOT SUPPORT FOR AN APPLICATION Abstract: Allow disable Hotspot JVM on HP-UX JDK from Admin Console with "-classic" command line and "Disable JIT" checkbox. Description/symptom of problem: This APAR completes the APAR PQ58961 problem to allow switching server's JVM mode from HotSpot to Classic on HP-UX Java. PQ58961 corrected the exceptions generated when disabling HotSpot so that the application server would start up correctly, but the fix did not enable the ability to switch from HotSpot mode to Classic mode. This APAR allows the "-classic" command line option and the "Disable JIT" checkbox to both switch the JVM mode from HotSpot to Classic. (From PQ62333) Abstract: Using WSCP with "EnterpriseApp show" command returns incorrect current state of the EnterpriseApp and same incorrect result for Module. This problem does not occur on stand alone server and only occurs when EnterpriseApp/Modules are installed on a ServerGroup . Description/symptom of problem: Error Description: Here is the test senerio: Install EnterpriseApp on a ServerGroup with multiple servers/clones. wscp> EnterpriseApp show /EnterpriseApp:intlbl/ {Name intlbl} {FullName /EnterpriseApp:intlbl/} {CurrentState Stopped} DesiredState Running} {StartTime 1021486630789} {OrigEarFile /apps/apl/intlbl/servlets/intlbl.ear} {OrigNodeName rcdaix10} The output shows stopped but the console shows Running by right click on EnterpriseApp and "showStatus". The discrepency applies to Modules as well. EnterpriseApp is in running state if at least one of the Modules it contains is running. A Module is in running state iff all of the servers it is installed on are running. (From PQ62330) Abstract: OS/390 db2390.sql Error with NumberFormatException Error Description: ERROR IN TRACE FILE: ExceptionUtil X CNTR0019E: Non-application exception occurred while method findAll: java.lang.NumberFormatException: customer use DB2 on OS/390 to hold WAS admin db. Script db2390.sql used to create was 4.0 db environment. It appears this platform and setup resulted with extra padding around numeric data (type long) in the database and caused the NumberFormatExceptions. ================================================================= Cumulative from client eFixes: (From PQ58248) Abstract: Allow creating the multiple virtual hosts with the different names but the duplicate alias lists in Admin Console and also allow deploying multiple Enterprise applications with the duplicate context root and the duplicate virtual host in the Admin Console and WSCP. Description/symptom of problem: 1. When attempting to create the virtual hosts in the AdminConsole with the different names but the duplicate alias list in Admin Console, the user would get the error message "fail to create virtual hosts" and cannot proceed. 2. When attempting to deploy the enterprise applications (web) with the duplicate context root "duplicate context root error" and cannot proceed the installation. (From PQ56639) Abstract: CAN NOT SET THE "CONNECTION CACHE MAXIMUM" FOR OBJECT REQUEST BROKER TO A VALUE HIGHER THAN 256 VIA THE ADMIN CONSOLE. Description/symptom of problem: When attempting to set the "Connection cache maximum" or "Connection cache minimum" field in the Object Request Broker property sheet to a value higher than 256, the AE admin console will display an error dialog indicating that the maximum value for the field is 256 only. (From PQ60772) Abstract: The WSCP fails to validate the user/group names on role-user/group mapping when uses the LTPA auathentication. Description/symptom of problem: 1. When using wscp, uses a short user or group name for role-user/group mapping, the install will successfully, but it will cause a 403 error (Authorization fails) when accessing the bean. 2. When using wscp, uses a full DN user or group name, application install failed.