eFix (APAR): PQ62333 Status: efix Release: WebSphere 4.0.2, 4.0.3, and 4.0.4 Supersedes eFixes: PQ56389, PQ57046, PQ55897, PQ56429, PQ59006, PQ56901, PQ59756, PQ60064, PQ60796, PQ60843, PQ61172 CMVC defect: PQ62333 Byte size of APAR: Date: 06/18/2002 Title: WSCP SHOW command reports incorrect currentState on EnterpriseApp and Modules installed on ServerGroup 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. If server accessed by remote client, eFix should be applied to both machines. 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.