eFix (APAR): pq57046 Status: efix For Release: WebSphere 4.0.2 For Edition: WebSphere AE For ContainerTypes: AEServer For Operating System: All Supersedes eFixes: PQ56429 CMVC defect: 117809 Byte size of APAR: 908,297 bytes Date: 01/29/02 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. Directions to apply efix: 1) Create temporary "efix" directory to store the zip/tar file: AIX: /tmp/WebSphere/efix Solaris/Linux: /tmp/WebSphere/efix jav Windows: c:\temp\WebSphere\efix 2) Copy zip/tar file to the directory (The zip/tar file will be created by WebSphere L2 Support. It will contain the the efix jar file, the readme.txt file, and any other standard information required by IBM) 3) Unzip/untar the file 4) Shutdown WebSphere 5) Run the jar file with the following command answering questions/prompts as they appear: java -jar -target For example: java -jar PQ56429_eFix_AEServer.jar -target c:\WebSphere\AppServer 6) Restart WebSphere 7) 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 8) The temp directory may be removed but the zip/tar 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: IMPORTANT: After WSCP is used to convert DataSources, they cannot be unconverted. However, the converted DataSources run on any 4.0.2 (or later) release, regardless of the efixes applied. 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. Trouble shooting -------------------------------------------------------------------------------------- o If an efix complains about the container type and you are sure it should match, contact WebSphere L2 Support for assistance with the -SkipContainerCheck option to the efix jar. o If the efix complains about the version of XML parser, move the file $WASROOT/jre/lib/ext/xerces.jar to a temporary location (such as c:\temp), load the efix and move the file back to it's original location. 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 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.