This document contains the release notes for IBM WebSphere Application
Server, Version 5.0.1. For the very latest updates, view the English online
version of the Release Notes located at http://www.ibm.com/software/webservers/appserv/library/
.
Installation and uninstallation
Cannot install the pluggable client from the IBM
WebSphere Application Server client CD on a Windows system
You cannot install the pluggable client from the IBM WebSphere
Application Server client CD on a Windows system.
To
work around this problem, do one of the following:
- Copy the IBM WebSphere Application Server client CD for Windows installation
image to your local temp directory and install
it from there.
- Run the installer manually from a command line with the following options:
<cd drive>\nt\install.exe -P OrbPropertiesFileCopy.installLocation="<SUNJrePath>/lib"
Where <cd
drive> is the CD drive and <SUNJrePath> is the location
of the SUN Operating Environment JRE file installed on your machine. For example:
F:\nt\install.exe -P OrbPropertiesFileCopy.installLocation="C:/JavaSoft/JRE/1.3.1_04/lib"
Manual steps needed for
process choreographer after fix pack installation
Most of the
additional configuration steps that are required after applying the fixes
for PQ70665 and PQ71037 are integrated in a fix pack installer hook. However,
not everything could be automated. Follow these instructions after installing
WebSphere Application Server Enterprise, Version 5.0.1:
- If you did not install the intermediate fixes for PQ70665 and PQ71037
before installing Fix Pack 1:
1.1 If you did not configure Process
Choreographer before installing Fix Pack 1, no additional manual steps are
required. When you configure Process Choreographer, the updated files containing
the new enterprise beans and the new database table definitions are used.
1.2 If
you configured a Process Choreographer before installing Fix Pack 1 and use
the Cloudscape database, no additional manual steps are required. The Process
Choreographer configuration including the Cloudscape database tables is upgraded
during fix pack installation.
Note: This includes selecting
the sample Process Choreographer configuration because the sample configuration
uses the Cloudscape database.
1.3 If you configured a Process
Choreographer before installing Fix Pack 1 and use a database other than Cloudscape,
you must manually create the new database tables used by compensation by executing
a DDL file that is generated during fix pack installation:
- On Windows machines: $WAS_HOME\ProcessChoregrapher\PQ70665-dbType><-<server>.ddl
- On UNIX machines: $WAS_HOME/ProcessChoregrapher/PQ70665-dbType><-<server>.ddl
- <dbType>is the database, for example, DB2, and <server>is
the application server associated with this Process Choreographer.
- Note 1: This DDL file contains instructions describing
how to set parameters for different database configurations. Use these instructions
to update the DDL file before executing it.
- Note 2: This step can be skipped, if either the Process Choreographer
is configured using the sample configuration, or if the Process Choreographer
is configured using the Cloudscape database.
- Note 3: You must repeat this step for each application server and
each cluster where you configure Process Choreographer before installing Fix
Pack 1.
- If you installed the intermediate fixes for PQ70665 and PQ71037 before
installing Fix Pack 1:
2.1 If you did not configure Process Choreographer
before installing Fix Pack 1, no additional manual steps are required. When
you configure Process Choreographer, the updated files containing the new
enterprise beans and the new database table definitions are used.
2.2 If
you configured Process Choreographer before installing Fix Pack 1 (You must
have followed the steps in the Readme file for the intermediate fixes):
2.2.1 If
you configured Process Choreographer before installing the intermediate fixes:
2.2.1.1 If
you enabled Global Security in WebSphere Application Server, the Process Choreographer
Web Client no longer works due to a bug in Administrative Scripting.
To
work around this:
- Start the administrative console and click Applications > Enterprise
Applications > BPEContainer_<nodeName>_<serverName>
- In Additional Properties > Map security roles to users/groups,
select All Authenticated for WebClientUser and JMSAPIUser.
- Map your User ID or group to BPESystemAdministrator.
- Save your changes.
Note: You must repeat this step for each application server
and each cluster where you configured Process Choreographer before installing
Fix Pack 1.
2.2.1.2 When you use DB2 on z/OS platforms, the DDL file
generated by the bpeupgrade.jacl script misses table space creation
commands. Run the DDL file that was generated during fix pack install
instead:
- On Windows machines: $WAS_HOME\ProcessChoregrapher\PQ70665-dbType><-<server>.ddl
- On UNIX machines: $WAS_HOME/ProcessChoregrapher/PQ70665-dbType><-<server>.ddl
- <dbType>is the database, for example, DB2, and <server>is
the application server associated with this Process Choreographer.
- Note 1: This DDL file contains instructions describing
how to set parameters for different database configurations. Use these instructions
to update the DDL file before executing it.
- Note 2: You must repeat this step for each application server
and each cluster where you configure Process Choreographer before installing
Fix Pack 1.
2.2.2 If you configured Process Choreographer after installing
the intermediate fixes:
2.2.2.1 When you use DB2 on z/OS platforms,
follow the instructions in step 2.2.1.2.
2.2.2.2 When you do
no use DB2 on z/OS platforms for Process Choreographer:
The new database
tables are created by following the steps in the Readme for the intermediate
fixes. No additional manual steps are required.
In case of failure,
check the $WAS_HOME/ProcessChoreographer/bpeupgrade.log file
to see if the Process Choreographer upgrade is successful. Also, check the $WAS_HOME/logs/wsadmin.traceout file.
If you install Fix Pack 1 on the deployment manager of a cell, you
must also install the Fix Pack 1 on all servers where you have a Process Choreographer.
This is because the bpecontainer.ear files on the deployment manager
are updated with new compensation CMP EJBs which require new database tables.
These new tables can only be created on the local servers, not centrally from
the deployment manager.
Save the jdbc-resource-provider-templates.xml file
before you install the WebSphere Application Server, Version 5 Fix Pack 1
In
WebSphere Application Server, Version 5.0.1, the jdbc-resource-provider-templates.xml file
is modified to include a new DB2 Universal JDBC provider and other JDBC provider
name changes. If you have modified this configuration file in WebSphere Application
Server, Version 5, save the jdbc-resource-provider-templates.xml file
before installing the WebSphere Application Server, Version 5.0.1. Otherwise,
the new XML file overwrites the jdbc-resource-provider-templates.xml file
and your configuration data is lost.
A validation error might
appear after configuring the sample business process container
A
validation error might appear when you:
- Click Configure a Sample Business Process container during the
Enterprise installation and configuration process
- Type the following in the command-line interface:
wsadmin $AdminConfig validate
The following is a copy of the error:
WASX7195I: Severity 1; line 0; target
"WebSphere:_WebSphere_Config_Data_Display_Name=BPEDataSourceCloudscape_CF,
_WebSphere_Config_Data_Type=CMPConnectorFactory,_WebSphere_Config_Data_Id=
cells/t23/nodes/t23/servers/server1:resources.xml#CMPConnectorFactory_BPE_1";
CHKW3155E: The alias BPEAuthDataAliasCloudscape to the JAASAuthData entry,
specified for J2CConnectionFactory {2}, matches no configured JAASAuthData
entries in security.xml.
You can ignore this error because IBM Cloudscape does not require
a user ID or a password.
Using a different language
than the one set on the local machine when you install IBM WebSphere Application
Server Enterprise causes the installation to fail
When you install
IBM WebSphere Application Server Enterprise using
a different language than the one set on the local machine, the installation
might fail. For example, if the language chosen on the local system is English
and the IBM WebSphere Application Server Enterprise is installed using French,
the installation might fail with the following error:
WebSphere Application Server, Version 5 failed to install successfully.
This install will terminate.
Check the log.txt file
to verify that the following message appears:
The WebSphere 5.0 install is complete.
This message indicates that the IBM WebSphere Application Server
is installed successfully. The user can proceed with the installation of IBM
WebSphere Application Server Enterprise.
To avoid this situation, install
the IBM WebSphere Application Server Enterprise using the same language as
the local system.
Extra information
displays in the Network Deployment response file
Extra information
displays in the IBM WebSphere Application Server Network Deployment response
file. Specifically, the following line appears and always must be commented:
#-W coexistencePanelBean.useIhs="true"
Port number used by the wsadmin tool can change
during coexistence scenario
During a coexistence scenario, you
can change the port number used by the wsadmin tool. If you do change the
port number, you must invoke the wsadmin tool using the new port using one
of the following commands:
wsadmin.bat/sh -conntype RMI -port <port_number>
wsadmin.bat/sh -conntype SOAP -port <port_number>
Alternatively,
you can update the wsadmin.properties file located in the <WAS_INSTALL_ROOT>/properties directory
to contain the new port values. If you do this, you do not need to specify
the port parameter when using the wsadmin tool.
Installation requirements
for the embedded messaging component
If you want to install the embedded messaging component on IBM
WebSphere Application Server and IBM WebSphere Application Server Network
Deployment on the same machine for the Windows NT and Windows 2000 platforms,
you must install IBM WebSphere Application Server first and then install IBM
WebSphere Application Server Network Deployment. Otherwise, embedded messaging
installation fails.
Coexistence problem between embedded
messaging, IBM WebSphere Studio Application Developer Integration Edition, and IBM WebSphere Application Server
The
IBM WebSphere Studio Application Developer Integration Edition and IBM WebSphere
Application Server both include an option to install embedded messaging. The
embedded messaging option in these two products is incompatible.
To
avoid this problem, do not install embedded messaging for both products on
the same machine.
A message regarding uninstallation
needs further clarification
During uninstallation of the IBM WebSphere
Application Server Enterprise, Version 5 , the following message might display:
Please wait while uninstalling WebSphere Application Server, Version 5 fixes
In the same window, users can click
Continue or
Cancel. Even
though the message indicates that uninstallation is in progress, the IBM WebSphere
Application Server is waiting for you to click
Continue or
Cancel before
starting or cancelling the uninstallation process.
When installing IBM
WebSphere Application Server Enterprise, Version 5 on top of the Deployment
Manager, the Javadoc is missing
When you install the IBM WebSphere
Application Server Enterprise, Version 5 on top of the Deployment Manager
from IBM WebSphere Application Server Network Deployment, Version 5 , the
Javadoc for the IBM WebSphere Application Server Enterprise, Version 5 is
missing.
To work around this problem, see the IBM WebSphere Application
Server Support Web site at the following address: http://www-3.ibm.com/software/webservers/appserv/support/index.html
System calls are not restarted correctly within
the Java virtual machine
A
problem exists in the Sun Java Development Kit on the Solaris Operating Environment,
which is fixed in 1.3.1_07 (FCS Jan 2003), when the socket reads and writes
randomly thrown InterruptedIOException or java.net.SocketException exceptions.
The root problem is that system calls are not restarting as they should within
the Java virtual machine.
See bugs numbers 4425033 and 4178050 at http://developer.java.sun.com/developer/bugParade
for
further details. If previous exceptions are encountered and are having a significant
impact on your operation before availability of 1.3.1_07, contact IBM for
support.
Failed to add users error
occurs during installation
During the installation of the IBM WebSphere Application Server
and the embedded messaging feature, an error might display indicating that
users were not added prior to starting the installation process. When you
install the IBM WebSphere Application Server Enterprise and the embedded messaging
feature, the installation process might fail without indicating that the users
were not added prior to starting the installation process. In both cases,
you can check the log file in the /tmp directory
for an indication of why the installation process failed.
Prior to
installation, you must add the mqm and mqbrkrs users
and groups. For more information on adding these users and groups, see the
following article in the IBM WebSphere Application Server, Version 5 documentation:
Resources > Messaging > Installing and configuring a JMS
provider > Installing WebSphere embedded messaging as the JMS provider
Uninstalling IBM WebSphere
Application Server Enterprise might leave extraneous information in the server
registries
While uninstalling
the IBM WebSphere Application Server Enterprise on AIX systems, you encounter the following question: "Do you want
to uninstall WebSphere Application Server also"? If you answer "yes", the
server is uninstalled. However, this process of uninstalling might not clean
up all of the server registries.
To work around this problem, use the
following parameter when you uninstall the IBM WebSphere Application Server
Enterprise:
_uninstPME/uninstall -is:javaconsole
Preparing to uninstall WebSphere Application Server,
Version 5 Fix Pack 1 (with WebSphere Embedded Messaging) on Solaris
Before uninstalling WebSphere Application
Server, Version Fix Pack 1 on Solaris, complete the following steps:
- If you have a WebSphere Application Server, or WebSphere Application Server
Network Deployment installation that includes the WebSphere Embedded Messaging
Client without the Server component, complete the following steps, before
uninstaling the Version 5 Fix Pack 1 on Solaris.
Note: If you installed
WebSphere Application Server with both the WebSphere Embedded Messaging Client
and Server components, you can ignore this item because it does not apply
to your installation.
The required procedure varies slightly depending
on how you chose to install the embedded WebSphere Embedded Messaging components:
- WebSphere Application Server and Embedded Messaging Client (only) installed
- Locate and delete the mqVer.properties file in the /opt/WebSphere/DeploymentManager/properties/version/backup/external.mq/ptfs/was50_nd_fp1_solaris/components/external.mq directory.
- Manually uninstall the WebSphere embedded messaging service -/usr/sbin/pkgrm
mqm-upd03.
- Continue with uninstall of WebSphere Application Server, Version 5 Fix
Pack 1.
- WebSphere Application Server Network Deployment and Embedded Messaging
Client (only) installed
- Locate and delete the mqVer.properties file in the /opt/WebSphere/AppServer/properties/version/backup/external.mq/ptfs/was50_fp1_solaris/components/external.mq directory.
- Manually uninstall the WebSphere embedded messaging service - /usr/sbin/pkgrm
mqm-upd03.
- Continue with uninstall of Version 5 Fix Pack 1.
If you do not complete this procedure, when you uninstall the Version
5 Fix Pack 1 on Solaris, the following error messages are added to the fix
pack uninstallation log. To recover from these errors, complete the procedure,
then repeat the fix pack uninstallation.
PTF Component Activity:
=========================================================
Component Name : external.mq
Action : uninstall
Time Stamp (Start) : 2003-04-09T10:41:12-05:00
=========================================================
Log File Name : /opt/WebSphere/DeploymentManager/properties/version/log/20030
409_154112_was50_nd_fp1_solaris_external.mq_uninstall.log
Backup File Name : /opt/WebSphere/DeploymentManager/properties/version/backup/20
030409_154112_was50_nd_fp1_solaris_external.mq_undo.jar
=========================================================
Saving History ...
Saving History ... Done
Running component update ( external.mq ).
Processing MQ CSD Uninstall Script
Processing MQ CSD version information.
Performing CSD uninstall.
Failed to perform uninstall.
Exception: WUPD0246E: Fix pack update failure: An exception occurred while
preprocessing the content of fix pack was50_nd_fp1_solaris, component external.mq
Saving History ...
Saving History ... Done
Results:
=========================================================
Time Stamp (End) : 2003-04-09T10:41:14-05:00
PTF Component Result : failed
PTF Component Result Message:
=========================================================
WUPD0246E: Fix pack update failure: An exception occurred while preprocessing the
content of fix pack was50_nd_fp1_solaris, component external.mq
=========================================================
PTF Component Installation ... Done
Exception: WUPD0243E: Fix pack uninstall failure: The update for component {1} for
fix pack external.mq could not be uninstalled.
After installing the CORBA
C++ client, you cannot run the setupCorbaClient.sh file
After installing the CORBA C++ client, you cannot set up the client
due to a syntax error in the NLSPATH line within the setupCorbaClient.sh file.
To
correct this error, complete the following steps:
- Locate the setupCorbaClient.sh file in the /usr/WebSphere/AppClient/bin directory.
- Find the line beginning with NLSPATH= and
change the semicolon to a colon.
Changing the permissions in certain files to open the rule
browser
The permissions of the ruleexporter.sh, ruleimporter.sh,
and rulemgmt.sh files in the /opt/WebSphere/DeploymentManager/bin directory
are not correct.
When you use the rulemgmt.sh files is to
open the rule browser, the following error is displayed:
/opt/WebSphere/DeploymentManager/bin/rulemgmt.sh: cannot execute
looked at the files under /opt/WebSphere/DeploymentManager/bin and found
ruleexporter.sh, ruleimporter.sh and rulemgmt.sh are not executable:
-rwxr-xr-x 1 root other 1621 Nov 9 18:16 restoreConfig.sh
-rw-rw-rw- 1 root other 847 Jan 15 12:41 ruleexporter.bat
-rw-rw-rw- 1 root other 961 Jan 15 12:41 ruleexporter.sh
-rw-rw-rw- 1 root other 854 Jan 15 12:41 ruleimporter.bat
-rw-rw-rw- 1 root other 883 Jan 15 12:41 ruleimporter.sh
-rw-rw-rw- 1 root other 1262 Jan 15 12:41 rulemgmt.bat
-rw-rw-rw- 1 root other 1445 Jan 15 12:41 rulemgmt.sh
-rwxr-xr-x 1 root other 5206 Nov 9 18:19 securityProcs.jacl
To change the permissions of these files, run one of the following
commands:
'chmod +x ruleexporter.sh', 'chmod +x ruleimporter.sh',
'chmod +x rulemgmt.sh'
Or,
'chmod 755 ruleexporter.sh',
'chmod 755 ruleimporter.sh', 'chmod 755 rulemgmt.sh'
Installing the IBM Development
Kit that supports CORBA C++ on Red Hat Linux Advanced Server version 2.1 requires
an additional C++ run-time environment on Intel platforms
If you install the CORBA C++ Development
Kit on Red Hat Linux Advanced Server version 2.1, you might find some incompatibility
issues with the GNU Compiler (GCC) C++ run-time support library. IBM uses
the GCC Version 2.95.3 C++ run-time support library rather than the GCC provided
with the Red Hat Linux Advanced Server Version 2.1.
To work around this
incompatibility issue, download the GCC Version 2.95.3, build it, and use
the C++ run-time support library it provides. After building GCC Version 2.95.3,
place the C++ run-time support library in the WebSphere /lib directory.
The process of obtaining and installing this additional run-time environment
follows:
- FTP to ftp.gnu.org.
- Type cd gnu/gcc/gcc-2.95.3/
- Download the gcc-everything-2.95.3.tar.gz file.
- Create a build directory such as /gcc-2.95.3-build.
In the remaining steps, this directory is referred to as <gcc-buildtree>.
- Type cd <gcc-buildtree>
- Extract the GCC source code by executing the following tar command:
tar -xzf <location-of-gcc-tar-file>/gcc-everything-2.95.3.tar.gz
- Type cd <gcc-buildtree>/gcc-2.95.3
- Execute the following command to configure the GCC source code in preparation
for building:
./configure --prefix /compiler/gcc-2.95.3/ -enable-shared="libstdc++,libgcc"
Note: The --prefix option
specifies that the compiler installs into the /compiler/gcc-2.95.3 directory.
You can choose another location.
- Type make to compile the GCC. The compile
process might take several minutes to complete as it depending on the speed
of your computer.
- Type make install to install the compiler
in the location specified previously using the --prefix option.
- Execute the following command to copy the C++ run-time support library
to the WebSphere /lib directory:
cp /compiler/gcc-2.95.3/lib/libstdc++-libc6.2-2.so.3 <install_root>/lib
where <install_root> is the location where you installed
the WebSphere product.
Note: This release note applies to Red Hat Linux Advanced Server
2.1 on Intel platforms only.
IBM Toolbox for Java JDBC driver
WebSphere Application
Server supports the IBM Toolbox for Java JDBC driver. The IBM Toolbox for
Java JDBC driver is included with the IBM Toolbox for Java product.
IBM
Toolbox for Java is a library of Java classes that are optimized for accessing
iSeries and AS/400 data and resources. You can use the IBM Toolbox for Java
JDBC driver to access local or remote DB2 UDB for iSeries 400 databases from
server-side and client Java applications that run on any platform that supports
Java.
IBM Toolbox for Java is available in these versions:
- IBM Toolbox for Java licensed program
The licensed program is available
with every OS/400 release, Version 4 Release 2 (V4R2) or later. You can install
the licensed program on your iSeries 400 system, and then either copy the
IBM Toolbox for Java JAR file (jt400.jar) to your system or update
your system classpath to locate the server installation. Product documentation
for IBM Toolbox for Java is available from the iSeries Information Center:
http://publib.boulder.ibm.com/pubs/html/as400/infocenter.html (The documentation is located under Programming > Java > IBM Toolbox
for Java.)
- JTOpen
JTOpen is the open source version of IBM Toolbox for Java, and
is more frequently updated than the licensed program version. You can download
JTOpen from http://www-1.ibm.com/servers/eserver/iseries/toolbox/downloads.htm. Also available for download is the JTOpen Programming Guide. The guide
includes instructions for installing JTOpen, as well as information about
the JDBC driver.
The JDBC driver for both versions supports JDBC 2.0. For more information
about IBM Toolbox for Java and JTOpen, see the product Web site at http://www-1.ibm.com/servers/eserver/iseries/toolbox/index.html.
For customers using WebSphere Application Server, Version 5 on platforms
other than iSeries, the JTOpen version of the Toolbox JDBC driver is the one
to download and use.
To configure or use the jt400.jar file,
do the following:
- Download from the jt400.jar file from the JTOpen link. Place
it in a directory on your work station such as C:\JDBC_Drivers\Toolbox.
- In the WebSphere Application Server, Version 5 administrative console,
use the following links to set the WebSphere Application Server managed variable OS400_TOOLBOX_JDBC_DRIVER_PATH at
the Node level: Environment > Managed WebSphere Variables.
- Double-click OS400_TOOLBOX_JDBC_DRIVER_PATH.
- Set the value to the full directory path to the jt400.jar file
downloaded in step one. Do not include the jt400.jar file in this
value. For example, OS400_TOOLBOX_JDBC_DRIVER_PATH == "C:\JDBC_Drivers\Toolbox"
This path is referenced in the jdbc-resource-provider-templates.xml file
used to configure JDBC resource providers.
Complete the following
steps to choose a Toolbox driver from the list of possible resource providers:
- Click Resources > JDBC Providers.
- Select New.
- From the JDBC Provider list, click UDB DB2 for iSeries (Toolbox) or UDB
DB2 for iSeries (Toolbox XA).
When the provider is created, the Classpath field looks as follows: Classpath
= ${OS400_TOOLBOX_JDBC_DRIVER_PATH}/jt400.jar.
Uninstall fixes for IBM HTTP Server and MQ Series
(Embedded Messaging) before installing fix pack updates to these features
If
you have installed fixes for IBM HTTP Server or MQ Series Embedded Messaging,
you need to uninstall these fixes prior to updating these features using the
Update Installer. If you do not uninstall these fixes, the updates to IBM
HTTP Server or Embedded Messaging made during the fix pack installation might
fail or the installation might be faulty. You can choose to skip the updates
IBM HTTP Server or Embedded Messaging if they are not required during fix
pack installation. See the Update Installer documentation for more information.
Unclear message displays
when WebSphere Application Server Enterprise, Version 5 Fix Pack 1 is applied
without applying WebSphere Application Server and Network Deployment, Version
5 Fix Pack 1
If you are attempting to apply the WebSphere Application
Server Enterprise, Version 5 Fix Pack 1 on top of WebSphere Application Server
Enterprise, Version 5 and WebSphere Application Server, Version 5, the following
message displays:
There are no installable fix packs that can be applied to the currently selected product.
The correct message should have content similar to the following:
For
WebSphere Application Server:
You must install WebSphere Application Server, Version 5 Fix Pack 1 prior to installing WebSphere Application Server Enterprise, Version 5 Fix Pack 1.
For WebSphere Application Server Network Deployment:
You must install WebSphere Application Server Network Deployment, Version 5 Fix Pack 1 prior to installing WebSphere Application Server Enterprise, Version 5 Fix Pack 1.
To avoid receiving this message, apply the WebSphere Application Server,
Version 5 Fix Pack 1 before applying WebSphere Application Server Enterprise,
Version 5 Fix Pack 1.
Installation of IBM WebSphere
Application Server Enterprise, Version 5 might fail on SuSE Linux and Red
Hat Linux
In specific situations,
IBM WebSphere Application Server Enterprise, Version 5 installation with IBM
WebSphere Application Server Network Deployment fails on the SuSE Linux and
Red Hat Linux platforms. The following information describes possible scenarios
and their recommended workarounds:
Scenario 1
- Description
- You installed the following:
- IBM WebSphere Application Server, Version 5
- IBM WebSphere Application Server Network Deployment, Version 5 .
You want to install IBM WebSphere Application Server Enterprise, Version
5 on the following:
- IBM WebSphere Application Server
- IBM WebSphere Application Server Network Deployment.
- Workaround
- The workaround follows:
- Install IBM WebSphere Application Server Enterprise on IBM WebSphere Application
Server Network Deployment.
- Install IBM WebSphere Application Server Enterprise on the IBM WebSphere
Application Server.
Scenario 2
- Description
- You installed the following on the IBM WebSphere Application
Server:
- IBM WebSphere Application Server Network Deployment
- IBM WebSphere Application Server Enterprise
You want to install IBM WebSphere Application Server Enterprise on
IBM WebSphere Application Server Network Deployment.
- Workaround
- Two possible workarounds follow:
- Workaround 1
- Uninstall IBM WebSphere Application Server Enterprise from the IBM WebSphere
Application Server.
- Install IBM WebSphere Application Server Enterprise on IBM WebSphere Application
Server Network Deployment.
- Install IBM WebSphere Application Server Enterprise on IBM WebSphere Application
Server.
- Workaround 2
- Run the following rpm commands in a shell prompt:
rpm -q WSEOS07AA-5.0-0 WSESA07AA-5.0-0 WSEFC06AA-5.0-0 WSEEM05AA-5.0-0 WSECF11AA-5.0-0
This command displays whether the entries exist. It is possible
that they do not exist on your system and the installation process will work
without them. If the entries exist, the previous command produces the following
output:
WSEOS07AA-5.0-0
WSESA07AA-5.0-0
WSEFC06AA-5.0-0
WSEEM05AA-5.0-0
WSECF11AA-5.0-0
- If the entries exist, type the following to erase them from the rpm command:
rpm -e WSEOS07AA-5.0-0 WSESA07AA-5.0-0 WSEFC06AA-5.0-0 WSEEM05AA-5.0-0 WSECF11AA-5.0-0
You can ignore the following error if it appears after executing
the previous command. The error is displayed if one of the entries is not
in the rpm.
error: package WSEFC06AA-5.0-0 is not installed
- Run the following command to confirm that the entries were erased:
rpm -q WSEOS07AA-5.0-0 WSESA07AA-5.0-0 WSEFC06AA-5.0-0 WSEEM05AA-5.0-0 WSECF11AA-5.0-0
If the entries were erased, the following messages are displayed:package WSEOS07AA-5.0-0 is not installed
package WSESA07AA-5.0-0 is not installed
package WSEFC06AA-5.0-0 is not installed
package WSEEM05AA-5.0-0 is not installed
package WSECF11AA-5.0-0 is not installed
- Install IBM WebSphere Application Server Enterprise on IBM WebSphere Application
Server Network Deployment.
Scenario 3
- Description
- You installed the following on the IBM WebSphere Application
Server:
- IBM WebSphere Application Server Network Deployment
- IBM WebSphere Application Server Enterprise
When you install IBM WebSphere Application Server Enterprise on IBM
WebSphere Application Server Network Deployment, the installation fails.
- Workaround
- The workaround follows:
- Delete the _uninstPME directory created in
the IBM WebSphere Application Server Network Deployment installation directory.
- Perform workaround 1 or workaround 2 defined in scenario 2.
Port updates for co-existence require a WebSphere
Application Server installation
Port updates for co-existence require
the installation of WebSphere Application Server. This requirement affects
port updates for IBM HTTP Server co-existence. Port updates do not occur if
only the IBM HTTP Server is installed. In this case, manually update the httpd.conf files.
Configuration changes for the
WebSphere Application Server client
This section describes several
configuration changes for the WebSphere Application Server client.
Note:
These changes only apply to a client installation and are not required on
WebSphere Application Server.
- The <WAS_HOME>/properties/soap.client.props file does not
get updated with the location of your WebSphere Application Server client
installation path. To correct the problem, do the following:
- Edit the soap.client.props file.
- Two lines that contain the string $(WASROOT):
Replace $(WASROOT) in
those two lines with the path to your WebSphere Application Server client
installation. For example:
Original line:
com.ibm.ssl.keyStore=$(WASROOT)/etc/DummyClientKeyFile.jks
Correct
line:
On Windows platforms:
com.ibm.ssl.keyStore=C:/WebSphere/AppClient/etc/DummyClientKeyFile.jks
On
UNIX platforms:
com.ibm.ssl.keyStore=/usr/WebSphere/AppClient/etc/DummyClientKeyFile.jks
- Save the file.
- The <WAS_HOME>/bin/setupClient command shell contains two
errors. To correct the errors, do the following:
- Edit the setupClient.bat file on the Windows platforms or the setupClient.sh file
on the UNIX platforms.
- The CLIENTSOAP environment variable is incorrect. To correct
this, do the following:
- Find the following line:
On Windows platforms:
set CLIENTSOAP=Dcom.ibm.SOAP.ConfigURL=file:/%WAS_HOME%/properties/
sas.client.props
On UNIX platforms:
CLIENTSOAP=Dcom.ibm.SOAP.ConfigURL=file:/$WAS_HOME/properties/
sas.client.props
- Remove the first "/" character after the file. The line looks like this:
On
Windows platforms:
set CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:%WAS_HOME%/properties/sas.client.props
On
UNIX platforms:
CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:$WAS_HOME/properties/sas.client.props
- For the pluggable client, the WAS_BOOTCLASSPATH environment variable
is incorrect. To correct this problem:
On Windows platforms:
- Find the pluggable section of the setupClient.bat file.
- Find the line that sets the WAS_BOOTCLASSPATH environment variable.
- Add %JAVA_HOME%\lib\ext\ibmorb.jar; to the beginning of list
of the JAR files. After the modification, the line should look like:
set WAS_BOOTCLASSPATH=%JAVA_HOME%\lib\ext\ibmorb.jar;%WAS_HOME%\java\jre\lib\ext\ibmorb.jar;%WAS_HOME%\java\jre\lib\ext\ibmext.jar;%WAS_HOME%\java\jre\lib\ext\ibmjcefw.jar;%WAS_HOME%\java\jre\lib\ext\ibmjceprovider.jar;%WAS_HOME%\java\jre\lib\ext\iwsorbutil.jar;%WAS_HOME%\java\jre\lib\ext\ibmjlog.jar;%WAS_HOME%\java\jre\lib\ext\ibmjsse.jar;%WAS_HOME%\java\jre\lib\ext\ibmpkcs.jar;%WAS_HOME%\properties
On UNIX platforms:
- Find the pluggable section of the setupClient.sh file.
- Find the two lines that set the WAS_BOOTCLASSPATH environment
variable.
- Add $JAVA_HOME/lib/ext/ibmorb.jar: to both lines at the beginning
of the list of the JAR files. After modification, the lines should look like:
case $PLATFORM in
SunOS | HP-UX)
WAS_BOOTCLASSPATH=$JAVA_HOME/lib/ext/ibmorb.jar: ......
*)
WAS_BOOTCLASSPATH=$JAVA_HOME/lib/ext/ibmorb.jar: .......
- Save the file.
The administrative console, or the adminconsole.ear file,
does not function properly when com.ibm.websphere.sendredirect.compatibility is
set to true
If you need to create a Java virtual machine
(JVM) com.ibm.websphere.sendredirect.compatibility custom property
and set it to true, create an additional server and install the application
on the new server. The administrative application does not function properly
when the com.ibm.websphere.sendredirect.compatibility property is set to true.
The administrative application fails because the login URL is modified
by adding a second /admin.
To work around this problem, delete
the second /admin from the URL in the browser.
You must restart the server after a configuration
change
If you make any changes to the configuration, restart the
server as noted in the messages section of the administrative console.
A core dump might occur when running WebSphere
Application Server with DB2 V7.2 FP8 client in AIX 5.2
A core dump might occur when you are running WebSphere Application
Server with DB2 V7.2 FP8 client in AIX 5.2 having all of the following configurations:
- You installed WebSphere Application Server in 64-bit AIX 5.2.
- You installed 64-bit DB2 V7.2 FP8.
- You created a 32-bit client instance to connect to the DB2 server.
- You installed applications which use DB2 data source in WebSphere Application
Server.
A java core dumped error displays when you start the WebSphere
Application Server. This is due to a DB2 problem. A defect has been opened
to DB2.
To solve this problem, rename the libdb2lai.a file
on your DB2 client machine as follows:
- Change to the /usr/lpp/db2_07_01/lib directory.
- Rename the file libdb2lai.a to libdb2lai.a.orig.
Stop the deployment manager
before uninstalling WebSphere Application Server Enterprise on WebSphere Application
Server Network Deployment
Stop the deployment manager before uninstalling
WebSphere Application Server Enterprise on WebSphere Application Server Network
Deployment.
To stop the manager, execute the stopManager.bat command
on Windows machines or the stopManager.sh command on UNIX machines.
Migration
Changes are made to the Java Database Connectivity
providers in WebSphere Application Server Fix Pack 1
The following
changes are made to the Java Database Connectivity (JDBC) providers in WebSphere
Application Server Fix Pack 1:
- Fix Pack 1 provides a new JDBC provider for DB2. Use this JDBC provider
to test the new DB2 Universal JDBC type 4 driver. This provider only supports
5.0 datas ource in WebSphere Application Server, Version 5.0.1. To distinguish
between this new jdbc provider and the existing DB2 type 2 jdbc provider,
Fix Pack 1 changes the name of the provider in thejdbc-resource-provider-templates.xml file
to match the provider with the name.
- Fix Pack 1 merges both Oracle thin and oci drivers into one single Oracle
provider because there are no property differences between these two drivers.
Fix Pack 1 also marks the old jdbc providers as deprecated.
- The old Cloudscape and Sybase JDBC providers have version numbers in the
names. To support new versions under the same JDBC driver provider in the
future, Fix Pack 1 removes the version numbers. Fix Pack 1 also adds two Cloudscape
and Sybase JDBC providers. Fix Pack 1 marks the old Cloudscape and Sybase
JDBC providers as deprecated.
The removeNode
command removes clusters from configuration
When migrating from
a previous IBM WebSphere Application Server version to IBM WebSphere Application
Server Network Deployment, you must first migrate each of the nodes and then
use the addNode command to federate the WebSphere base product nodes
into the Network Deployment environment. Later, the removeNode command
can be used to remove the WebSphere base node from the Network Deployment
environment.
But, the removeNode command removes the configuration
entries from the clusters.xml file for the node. When you attempt
to install an application on the cluster no members are found because the removeNode command
deleted the entries.
To work around this problem, if you execute the removeNode command
on a node that contains servers that are part of a cluster, you need to explicitly
create new cluster member servers on that node if you want to add the node
to the cell again.
Note:There are no functional changes, Fix Pack
1 only changes the names for usability reason.
The changed providers are:
| Data source |
JDBC providers in Version 5 |
JDBC providers in Version 5.0.1 |
| DB2 |
DB2 JDBC provider (deprecated) |
DB2 legacy CLI-based type 2 JDBC driver |
| |
DB2 JDBC provider (XA )(deprecated) |
DB2 legacy CLI-based type 2 JDBC driver (XA) |
| |
|
DB2 Universal JDBC driver provider (type 4 only) |
| Oracle |
Oracle JDBC thin driver (deprecated) |
Oracle JDBC driver |
| |
Oracle JDBC thin driver (XA) (deprecated) |
Oracle JDBC driver (XA) |
| |
Oracle JDBC oci8 driver (deprecated) |
Oracle JDBC driver |
| |
Oracle JDBC oci8 driver (XA) (deprecated) |
Oracle JDBC driver (XA) |
| Cloudscape |
Cloudscape JDBC provider 5.0 (deprecated) |
Cloudscape JDBC provider |
| |
Cloudscape JDBC provider 5.0 (XA) (deprecated) |
Cloudscape JDBC provider (XA) |
| Sybase |
Sybase 12.0 JDBC driver (deprecated) |
Sybase JDBC driver |
| |
Sybase 12.0 JDBC driver (XA) (deprecated) |
Sybase JDBC driver (XA) |
For a complete description of supported JDBC driver providers, required
JDBC driver files and data source properties, see the Vendor specifications
file (rdat_minreq) in the InfoCenter.
What do these changes mean to you?
If you use the Java command language Jacl to create a JDBC provider and
data source and your script references those names (for example, you use the
createUsingTemplate API to create a jdbc provider), you might have to change
your Jacl to use the new name. Since the old names are deprecated, we recommend
you change the names as soon as possible.
XMLConfig utility and migration integration
Migration
uses the XMLConfig utility to save the WebSphere Application Server Advanced
Edition, Version 4.0 configuration as part of migration. There are some fixes
available to the IBM WebSphere Application Server Advanced Edition, Version
4.0 XMLConfig utility that you can apply if problems are occurring during
the call to this utility during migration including:
PQ52555 - XMLConfig does not export clone property configuration
PQ55064 - XMLConfig does not export enterprise bean to DataSource level mappings
PQ58038 - Performing an XMLConfig export produces an extra CRLF
PQ62103 - XMLConfig full export fails with NullPointerException in a Multi-Node Environment
PQ62471 - Security AdminRoles are not getting exported during XML export
PQ63815 - "=" is not a valid character for the value string in XMLConfig
The WASPostUpgrade
migration tool fails
You might receive an error in either of the
following situations:
- The IBM WebSphere Application Server migration tools are run manually
in an IBM WebSphere Application Server Network Deployment environment in which
there are Network Deployment nodes. These migration tools are provided to
move configurations from previous versions of the IBM WebSphere Application
Server.
- The IBM WebSphere Application Server Enterprise is installed in an IBM
WebSphere Application Server Network Deployment environment in which there
are Network Deployment nodes.
The errors, which display either on the command-line or in the
Migration panel of the installation program, will be similar to the following:
MIGR0122E: Unable to read configuration file /opt/WebSphere/DeploymentManager/config/cells/
ws-sunfish2Network/nodes/
at com.ibm.websphere.migration.postupgrade.TransformBaseConfiguration.resolveDirectory
(TransformBaseConfiguration.java:690)
at com.ibm.websphere.migration.postupgrade.TransformBaseConfiguration.initializeDataModel
(TransformBaseConfiguration.java:587)
at com.ibm.websphere.migration.postupgrade.TransformBaseConfiguration.doIt
(TransformBaseConfiguration.java:1145)
at com.ibm.websphere.migration.postupgrade.Restore.doIt(Restore.java:153)
at com.ibm.websphere.migration.postupgrade.Restore.<init>(Restore.java:93)
at com.ibm.websphere.migration.postupgrade.WASPostUpgrade.restore(WASPostUpgrade.java:196)
at com.ibm.websphere.migration.postupgrade.WASPostUpgrade.main(WASPostUpgrade.java:665)
at java.lang.reflect.Method.invoke(Native Method)
at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:94)
com.ibm.websphere.migration.exceptions.WASUpgradeInvalidConfigurationException:
MIGR0122E: Unable to read configuration file /opt/WebSphere/DeploymentManager/config/cells/
ws-sunfish2Network/nodes/.
To work around this problem, invoke the WASPostUpgrade migration
tool after installation is complete. You must specify the -nodeName parameter
with the deployment manager node when you use the WASPostUpgrade command.
For more information on the WASPostUpgrade command, see the article
entitled, "WASPostUpgrade command " in the IBM WebSphere Application Server,
Version 5 documentation.
The maxSendSize and maxReceiveSize variable
values do not migrate from IBM WebSphere Application Server, Version 4 to
Version 5
After migrating to IBM WebSphere Application Server, Version
5, the maxSendSize and maxReceiveSize variable values, which are included
in the WorkArea Service, are set to the Version 5 default values. These variables
are not correctly mapped from Version 4 to Version 5.
To work around
this problem, use the Customer Services section of the administrative
console to update these variables with their Version 4 values.
The IBM WebSphere Application
Server Enterprise, Version 5 installer might display the migration panel when
migration is not possible
The
IBM WebSphere Application Server Enterprise, Version 5 installer might display
the migration panel when it is not possible to migrate to Version 5. If you
select the migration option when migration is not possible, errors display.
Migration is supported for IBM WebSphere Application Server installations
when you have a IBM WebSphere Application Server, Version 3.5 or Version 4
administration server installed.
To work around the problem, do not
select (or clear) the Migration option on the Migration panel.
If the migration option is specified without a previous version of the administration
server installed, the status panel indicates that migration failed. You can
ignore this error and continue to install IBM WebSphere Application Server
Enterprise, Version 5 .
System administration
System performance degrades when you configure
the nodeagent failover with a certain script
If you configure the nodeagent failover
with the script created by {WAS_HOME}/bin/startServer.sh nodeagent
-script startnodeagent.sh -background script, the system performance
degrades. A message similar to the following displays:
Feb 28 14:48:37 wastst12 init: Id "was" respawning too fast: disabled for 5 minutes
Configure the nodeagent failover with the script created by {WAS_HOME}/bin/startServer.sh
nodeagent -script startnodeagent.sh to work around the problem.
IBM WebSphere Application
Server errors occur after uninstalling Enterprise
After uninstalling
the IBM WebSphere Application Server Enterprise and restarting the server,
the following errors might occur:
- Enterprise resources fail to bind
- The addNode command fails
If you have an Enterprise cell and you want to uninstall Enterprise
from one of the nodes within the cell, you must remove the node from the cell
prior to uninstalling Enterprise. If you do not remove the node first, the
cell manager might push the Enterprise configuration back to the node and
cause errors when you try to start the application server of the node. If
this occurs, you must uninstall and reinstall the IBM WebSphere Application
Server.
Cannot use a server
name that is a member of one cluster in another cluster
You cannot
use a server name assigned to a cluster member elsewhere in the cell. For
example, Cluster1 can have multiple members named server1, but no server in
the cell outside the cluster can have the name server1. Otherwise, lookups
which resolve to an object on a cluster, or a single server involved in the
name conflict can fail. To work around the problem, assign unique names to
cluster members.
Plugin-cfg.xml
files on federated nodes can be overwritten
Because the
plugin-cfg.xml file
on a Network Deployment machine is stored in the configuration repository,
the
plugin-cfg.xml file is overwritten on all federated nodes in
your network whenever the Network Deployment machine updates the configuration
repository on these federated nodes. If you customize the
plugin-cfg.xml files
on your federated nodes, change the name of
plugin_cfg_custom.xml and
httpd.conf files
in the Web server to point to the new file name. In a Windows environment,
you must edit the Windows NT registry to update the plugin-cfg key to point
to the new
plugin-cfg.xml file for Domino and Internet Information
Services (IIS) Web servers.
Issuing the addNode command
can replace the plugin-cfg.xml file
After
federating the Node, the addNode command backs up the plugin-cfg.xml file
from the <install_root>/config/cells directory to
the config/backup/base/cells directory. The addNode command
in Fix Pack 1 regenerates a new plugin-cfg.xml file at the Deployment
Manger and the nodeSync operation copies the files to the node level. You
might experience a Web server failure due to the wrong directory name in the
new plugin-cfg.xml file.
Wrong directory
name in the Network Deployment plugin-cfg.xml file
When
you regenerate the plugin-cfg.xml file through the network deployment
manager, the resulting file contains path information specific to the Network
Deployment installation. This file is replicated to the node level. Or, you
can copy this file to a remote Web server. If the directory names do not
match the product installation directory, the Web server cannot start. Edit
the plugin-cfg.xml file and replace all occurrences of network_deployment_install_root with
websphere_application_server_install_root.
For example, if
you installed IBM WebSphere Application Server into the directory C:\WebSphere\DeploymentManager,
replace all occurrences of C:\WebSphere\DeploymentManager with C:\WebSphere\AppServer.
Use any text editor to change and edit any file locations.
For exmaple,
the plugin-cfg.xml file has a line:
<Log LogLevel="Error" Name="/opt/WebSphere/DeploymentManager/logs/http_plugin.log"/>
which needs to change to
<Log LogLevel="Error" Name="/opt/WebSphere/AppServer/logs/http_plugin.log"/>
WebSphere
Application Server Version 5 Fix Pack 1 has a new feature to retain the directory
names you have changed in the plugin-cfg.xml file. If you want to
regenerate the new plugin-cfg.xml file with the default values, delete
the current plugin-cfg.xml file before generating the new file.
The -stopservers option
on the syncNode utility does not work correctly
The -stopservers option
on the syncNode utility does not work correctly if the node agent server
is running. The syncNode tool is not needed if the node agent is running.
The node agent
autoRestart feature depends on functional multicast protocol
The
node agent monitors running application servers and other managed processes,
and automatically restarts the process if it crashes or becomes non-responsive.
This feature depends on the multicast IP protocol functioning between the
node agent and the managed processes. If there is a problem with multicast
protocol functioning on the system, or if it is desired to disable multicast
support in the subnet where the system is running, the node agent autoRestart
feature does not work correctly.
Servers can restart by mistake if multicast
protocol is not working. In this situation, it is recommended to disable node
agent autoRestart for the affected servers, and rely on the native operating
system monitoring feature instead. The native operating system monitoring
involves configuring the server as a Windows service on Windows operating
systems, or creating an inittab entry for the rc.was script
on UNIX operating systems. Information on setting up native operating system
monitoring is in the documentation.
Unsynchronized
system clocks cause failure
The security system requires system
clocks across a secure cell to be synchronized. When running in a secure Network
Deployment environment and the clocks of the systems in the cell are not synchronized,
administrative operations fail because of authorization failures due to expired
LTPA tokens.
See the article entitled, "Security considerations specific
to a multi-node or process Network Deployment environment" for more information.
Empty NetworkDeploymentCell
directory is left in the configuration directory
When you install
IBM WebSphere Application Server, and you run addNode then removeNode, sometimes
an empty NetworkDeploymentCell directory is left in the configuration directory
making wsadmin think there are two cells configured.
The WebSphere product
cannot delete the directory because the directory is locked by another application.
The most common reason for this situation is that another application uses
that directory or its subdirectory as the current working directory, or another
application opens a file under that directory or subdirectory. This problem
is most commonly seen on Windows platforms, but it can happen on other platforms.
To
work around this problem, manually delete the empty directory structure, then
restart the servers that use this configuration directory.
Accessing First Steps items on Linux 390 systems
When you select the following features from
the First Steps GUI, the Web browser window does not open:
- WebSphere InfoCenter
- Register the Product
- Samples Gallery
- Administrative Console
To access these features:
- Open a Web browser window on another machine.
- Type the browser URL that displays in the First Steps status window into
the address field of the Web browser.
- Click Enter to open the page in the Web browser.
The Domino Server plug-in fails to configure on
Solaris Operating Environment
During installation, a dsapi_stderr.txt file
is created in the logs directory and you can get
the following error messages:
lotus.notes.NotesException: Could not load dll for system name SUNOS
at lotus.notes.NotesThread.load(NotesThread.java:210)
at lotus.notes.NotesThread.<clinit>(NotesThread.java:24)
java.lang.UnsatisfiedLinkError: NnotesInitThread
at lotus.notes.NotesThread.NnotesInitThread(Native Method)
at lotus.notes.NotesThread.initThread(NotesThread.java:99)
at lotus.notes.NotesThread.run(NotesThread.java:133)You
can configure the IBM WebSphere Application Server or Domino Server plug-in
manually using the Domino Server Web administration tool. The workarounds
are as follows:
- Start the Domino Server.
- Enter the URL for the Domino Server Web Administration site using a browser.
For example, http://<hostname>/names.nsf.
Enter the administrator user name and password.
- Double-click Server-Servers.
- Double-click WebServer to configure.
- Double-click Edit Server.
- Double-click Internet Protocol.
- Add the IBM WebSphere Application Server DSAPI plug-in to the DSAPI field.
For example, /opt/WebSphere/AppServer/bin/libdomino5_http.so
Note: If
there are already DSAPI filter files specified, use a space to delimit the
WebSphere plug-in file.
- Double-click Save and Close.
- Restart the Domino Server.
Cluster state
not always updated when using Windows Services
When starting and stopping application servers that are part of
a cluster using the Windows Services facility, the cluster state does not
always get updated correctly. For example, when a cluster is running and you
stop a cluster member through the Services GUI, the cluster state remains
as "Started" even though the server is no longer running.
Administrative console
All platforms
Administrative Console - Netscape browser
All
platforms
Cannot map the extended
messaging service resource reference using the administrative console
You
cannot map the extended messaging service resource reference using the administrative
console. To install this mapping capability, use the Application Assembly
Tool (AAT), use the wsadmin command, or complete the following steps:
On
Windows platforms:
- Stop the IBM WebSphere Application Server if it is running.
- Unzip the <install_root>\installableApps\CMMResRefBind.war file
into the <install_root>\installedApps\<cell_name>\adminconsole.ear\adminconsole.war directory.
- Set the WAS_PLPR_ROOT environment variable to <install_root>\installedApps\<cell_name>.
- Run the PluginProcessor.bat -restore command from the <install_root>\bin directory.
- Copy and use the <install_root>\installedApps\<cell_name>\adminconsole.ear\adminconsole.war\WEB-INF\web.xml file to overwrite the <install_root>\config\cells\<cell_name>\applications\adminconsole.ear\deployments\adminconsole\adminconsole.war\WEB-INF directory.
On UNIX platforms:
- Stop the IBM WebSphere Application Server if it is running.
- Unzip the <install_root>/installableApps/CMMResRefBind.war file
into the <install_root>/installedApps/<cell_name>/adminconsole.ear/adminconsole.war directory.
- Set the WAS_PLPR_ROOT environment variable to <install_root>/installedApps/<cell_name>.
- Run the PluginProcessor.sh -restore command from the <install_root>/bin directory.
- Copy and use the <install_root>/installedApps/<cell_name>/adminconsole.ear/adminconsole.war/WEB-INF/web.xml file to overwrite the <install_root>/config/cells/<cell_name>/applications/adminconsole.ear/deployments/adminconsole/adminconsole.war/WEB-INF directory.
Where:
<install_root> is
the location where you installed the IBM WebSphere Application Server
<cell_name> can be found by typing <install_root>\bin\setupCmdLine.bat on
Windows platforms and <install_root>/bin/setupCmdLine.sh on
UNIX platforms. Locate the line that says WAS_CELL=<CELLNAME>.
Adding a secured
remote node through the administrative console
Adding a secured
remote node through the administrative console is not supported. You can either
disable security on the remote node before performing the operation or perform
the operation from the command line using the addNode script.
Administrative console does not support browser
Back and Forward mechanisms
The administrative console does not
support using the browser Back and Forward mechanisms. Use of
these mechanisms can cause intermittent problems. Use Back or Cancel on
the administrative console panels instead.
Enabling the cookies in the browser
You
must enable the cookies in the browser to have the administrative console
work correctly.
Do not change the name of the JDBC provider after
it is created
When using the administrative console, do not change
the name of the JDBC provider if you create it by selecting an existing JDBC
provider from the menu. If you use a custom JDBC provider, for which you supply
the provider information, this restriction does not apply.
Error occurs when
accessing the Cluster topology panel
If your first action after
logging into the console is to click Servers > Cluster Topology and
then click on a link to a cluster, the message ServletException in:/secure/layouts/detailTitleLayout.jsp]
null displays at the top of the panel instead of the bread crumb links
and the panel description.
To work around this problem, access any other
panel in the administrative console first and then access the Cluster topology
panel.
Resolve the administrative console port conflict
If
the administrative console port is in conflict with an application already
running on the machine, you can change this port in the following files:
- <install_root>/config/cells/<cellname>/nodes/<nodename>/servers/<servername>/server.xml
- <install_root>/config/cells/<cellname>/virtualhosts.xml
Change all occurrences of port 9090 (or whatever port was selected during
installation time in an IBM WebSphere Application Server coexistence scenario)
to the desired port for the administrative console.
Alternatively, shut
down the other application using this port before starting the IBM WebSphere
Application Server.
The addNode command
does not remove the administrative console transport port
If you
configured the IBM WebSphere Application Server administrative console transport
port to a setting other than the 9090 default, federating the node using the addNode command
does not remove this nondefault transport from the server1 configuration.
If you use the same transport number for the IBM WebSphere Application Server
Network Deployment administrative console, you cannot start the application
server because of a port conflict. You can remove this unused transport port
using the IBM WebSphere Application Server Network Deployment administrative
console before starting server1.
Installing the Business Process
Container using the Install option does not map resource references
to the jms/BPECFC resource
If you use Install on the administrative
console to install the Business Process Container instead of the Business
Process Container Wizard, the resource references do not map to the jms/BPECFC
resource.
To work around this problem, you must create an additional
custom property. Follow the steps that are most appropriate to your point
in the installation process.
Before installing the Business Process
Container:
- Click Custom Properties from the Business Process Container panel
by clicking Servers > Application Servers > server > Business Process
Container > Custom Properties.
- Click New.
- Enter MQClusterQCF in the Name field
and your Queue Connection Factory JNDI Name in the Value field.
- Click OK.
- Return to the Business Process Container panel and click Install.
If you used the Install option to install the container
without first creating the custom property described previously:
- Click Applications > Enterprise Applications on the administrative
console.
- Click the BPE Process Container application.
- Click Map resource references to resources.
- Locate the resources with jms/BPECFC in the Reference
Binding field and specify your Queue Connection Factory JNDI name.
- Click OK.
Resizing the Netscape browser results in an error
If
you resize your Netscape browser, you could get a "Data Missing" error.
The
error message disappears in 60 seconds.
Enabling Netscape Version 4.7 to display
double-byte character set correctly
When using Netscape on AIX platforms without the translated package,
the English version of Netscape is available for all locale environments as
the default package. However, the English version of Netscape does not display
double-byte character set (DBCS) characters on the browser radio buttons and
title bars because the fonts are mismatched.
To work around this problem,
you can install the message resource to make the translated version of Netscape
available on a DBCS environment. Use the translated version of Netscape to
display the corrupted DBCS correctly. Change the locale from English to the
expected DBCS locale before starting Netscape. For example, issue the following
commands to display the Japanese contents on Ja_JP (AIX Shift JIS locale):
$ export LANG=Ja_JP
$ netscape&
How to check the installed package
For
the AIX platform:
- Execute the lslpp -aL | grep Netscape.msg command.
- Check the language and locale information using Netscape.msg package.
For example, the result of the command executed in step 1 is as follows for
the system having Japanese-translated Netscape:
# lslpp -aL | grep Netscape.msg
Netscape.msg.Ja_JP.communicator.rte
Netscape.msg.ja_JP.communicator.rte
For the Red Hat Linux Version 7.2 platform:
Execute the rpm-ql
netscape-common command to get the list of installed files.
In case
of Netscape Version 4.78 on Red Hat Linux Version 7.2, the translated packages
for seven languages including four DBCS languages (Japanese, Korean, Simplified
Chinese, and Traditional Chinese) are included in a common package.
How
to install the package
For the AIX platform:
Install the Netscape.msg.%L.communicator.rate package where %L is
the locale information for the System Management Interface Tool (SMIT) or
SMITTY to use. This message resource is provided by the Bonus Pack CD or the
Expansion Pack CD for AIX platform, which provides the Netscape common package.
Perform
the following steps to install the package:
- Set the media which has the Netscape installation image. For AIX 5L platform,
set the Expansion Pack media.
- Go to the directory which has the Netscape installation package. For AIX
5L platform Expansion Pack, go to the installp/ppc directory.
- Start SMIT or SMITTY.
- Click System Environments > Manage Language Environment > Change/Show
Applications for a Language > Add Language for Application Already
Installed.
- In the Add Language for Application Already Installed field select
a language (locale) from the drop-down menu list for the Language translation
to install field.
- Click OK.
- In the Add Language for Application Already Installed field enter
the directory location. Enter "." for the current directory or /cdrom/installp/ppc for
the full path as input directory for the software. Do not select cdrom as
the input device because the installation package does not exist on the root
directory of the CD-ROM.
- Click OK.
- Click List to check if the configuration is correct. The configuration
is correct if Netscape is on the list of installed application. Execute the
installation now.
- Click OK.
- Exit SMIT or SMITTY.
For Red Hat Linux Version 7.2 platform:
The default Netscape
installation can install each translated resource as part of the common package.
There is no way to install the translated package individually. However, TrueType
fonts (TTF packages) require installation for each language to correctly display
the translated resources on Netscape. Use the following to check if the required
font files are correctly installed:
$ rpm -qa | grep ttf
resources.0-4
ttfm-0.9.1-8
ttfonts-ja-1.0-6
ttfonts-ko-1.0-10
ttfonts-zh_CN-2.11-5
ttfonts-zh_TW-2.11-5
Resizing the Netscape browser causes an error
404 message
When connecting to the IBM WebSphere Application
Server administrative console from a Netscape browser, resizing the browser
can cause an error 404 message to occur. This
situation occurs because the browser reloads the frame when resizing the window.
To
avoid getting the error message, you can refrain from resizing the Netscape
browser window, or you can connect to the IBM WebSphere Application Server
administrative console using an Internet Explorer browser.
Using Netscape Version 4.79 on a Solaris Operating
Environment causes problems
Using
Netscape Version 4.79 on a Solaris Operating Environment to access the administrative
console causes problems with some key text translations with the zh_TW.EUC locale.
This situation is not a problem when you use Netscape Version 4.7. The officially
supported version of Netscape on a Solaris Operating Environment is Version
4.79, but in this case the workaround is to use Netscape Version 4.7.
Limitations occur when using Netscape with Solaris
Operating Environment
If
you click Troubleshooting > Logs and Trace > <server> > Diagnostic
Trace > Modify, the window that pops up allowing you to select the Components
and Groups to trace might not display a scroll bar, preventing you from
viewing all the components and groups.
The text area displaying the
selected components, groups, and trace levels does not have a vertical scroll
bar. This omission is a limitation of Netscape on a Solaris Operating Environment.
To
work around this problem, refresh the window to show the scroll bar.
Netscape screen blanks out while using the administrative
console
While working with the right-hand panel of the administrative
console to do regular administrative tasks, the browser screen blanks out
intermittently.
To work around this problem, do one of the following:
- After the problem occurs, close the Netscape browser, log in again, and
continue working.
- Use the Internet Explorer browser from a Windows machine.
- Use Netscape 7.x, Mozilla 1.x, Opera 5, or Konquerer browsers on the platform,
depending on which is available. Although there is not formal support for
these browsers, they have all been used successfully with the product and
in many cases work better than the previous 4.7.x series of Netscape browsers.
Resizing Netscape Version 4.7 causes errors
You
receive the following error messages when resizing Netscape Version 4.7:
Error 0
An error occurred while processing request: http://localhost:9090/admin/upload.do
message:
Details
com.ibm.webshpere.servlet.error.ServletErrorReport:
at java.lang.Class.newInstance0(Native Method)
... After resizing Netscape 4.7, Netscape has to reload
the page just as it initially loads the page on the first request. For pages
that do not expect POST data, it is not a problem. But for pages that do,
Netscape 4.7 cannot retain the data.
Databases-DB2
All Platforms
Illegal conversion occurs on any VARCHAR FOR
BIT DATA column in a container-managed persistent bean
When enterprise
beans with container-managed persistent (CMP) types that have any VARCHAR
FOR BIT DATA columns defined on a DB2 table are deployed in the DB2 universal
JDBC type 4 driver to persist the data, an SQLException of illegal conversion
is thrown at run time.
This exception only occurs when you use the DB2
universal JDBC type 4 driver and with the deferPrepares property
being set to true. When the deferPrepares property is set to true,
the DB2 universal JDBC type 4 driver uses the standard JDBC data mapping.
Currently,
the generated deployed code does not follow the standard JDBC specification
mapping. The failure at execution time is because of a problem in the tool
that prepared the enterprise beans for execution.
To avoid receiving
this exception, choose one of the following options:
- Set the deferPrepares property to false in the data
source configuration.
- Do not use the DB2 universal JDBC type 4 driver if your table has any
VARCHAR FOR BIT DATA or LONG VARCHAR FOR BIT DATA columns. Use the DB2 legacy
CLI-based JDBC driver to persist the data.
Refer to DB2 V8.1 readme for more details.
Incorrect user ID or password can result in
an error message
At the DB2 FP7 level, when configuring a 4.0 data
source for EJB 1.1 and 1.1 container-managed persistence (CMP) beans, and
the user ID or password is incorrect, you can get the following error message
in the SystemOut.log file while starting the application:
[7/22/02 17:37:13:547 CDT] 2827798b ConnectionPoo E CONM6009E: Failed to get connection to database from datasource (DB2PolicyDataSource).
[7/22/02 17:37:13:609 CDT] 2827798b JDBCPersister W CNTR0031W: Error starting CMP bean Life Insurance MD#lipolicy11.jar#IDTable:com.ibm.ejs.persistence.EJSPersistenceException: ; nested exception is:
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] SQL1403N The username and/or password supplied is incorrect. SQLSTATE=08004
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] SQL1403N The username and/or password supplied is incorrect. SQLSTATE=08004
To
work around this problem, verify the user ID or password and restart the application.
Mismatched user IDs causes a table not found or
object undefined exception from DB2
You can experience a
table not found or object undefined exception
from DB2, when the user ID that is used for the connection does not match
the user ID used to create a table.
If you use getConnection (user ID,
password) to get a connection and the user ID (for example, user ID2) is different
from the one (for example, user ID1) that is defined in the data source, then
user ID2 replaces user ID1 as the default in the data source. When your application
tries to get another connection without using the user ID and password, the
database uses user ID2 by default to get the connection. If you try to access
an object created by user ID1, the exception occurs.
To avoid receiving
the exception, do not use the user ID and password to get a connection. If
your application needs to connect this way, every getConnection() method should
always use the user ID and password to get a connection.
This problem
is fixed in DB2 V8.1 FP2
Using the administrative console to create a DB2
JDBC provider for a zSeries server causes an exception to occur
When
you use the administrative console to create a DB2 390 JDBC provider or a
DB2 390 JDBC provider (XA), an exception occurs with the message Name
is not a valid entry.
To work around this problem, choose the normal
DB2 JDBC provider to create a JDBC provider since they both use the same implementation
class. When you create a data source under this provider, change the data
store helper value from DB2DataStoreHelper to DB2390DataStoreHelper. Otherwise,
your database access does not work.
DB2 Universal JDBC type 4 driver is supported
DB2
Universal JDBC type 4 driver is supported in WebSphere Application Server,
Version 5.0.1. The minimum fix pack level is DB2 V8.1 FP1. This driver does
not support XA transaction. It is only supported in WebSphere Application
Server, Version 5.0.1 data source.
There is a known problem on mapping StaleConnectionException.
When you see the following exception stack, it is mapped to StaleConnectionException:
Error Code = 0
SQL State = null
com.ibm.db2.jcc.b.DisconnectException: A communication error has been detected. Communication protocol being used: {0}. Communication API being used: {1}. Location where the error was detected: {2}. Communication function detecting the error: {3}. Protocol specific error codes(s) {4}, {5}, {6}. TCP/IP SOCKETS Agent.sendRequest() OutputStream.flush() Connection reset by peer: socket write error * 0
at com.ibm.db2.jcc.c.a.a(a.java:329)
at com.ibm.db2.jcc.c.a.u(a.java:302)
The problem has been fixed in DB2 V8.1 FP2.
Prepared statement cache size
setting causes memory corruption when running IBM WebSphere Application Server
with DB2
When running IBM WebSphere Application Server, Version
5 with DB2 V7.2, your memory can corrupt (core dump on UNIX systems and Dr.
Watson on Windows NT machines). The problem occurs only if the prepared statement
cache is set greater than 0. This problem is fixed in DB2 V7.2 FixPak 8 and
DB2 V8.1
Do one of the following to work around the problem:
- Set the statementCacheSize to 0 in
the resources.xml file, for example, statementCacheSize=0
- Move to DB2 V7.2 FP8 or DB2 V8
Accessing
two different rows in a table might cause deadlock
Deadlock results
from accessing two different rows in a DB2 table when the next key is not
locked for all INSERT and DELETE statements.
To eliminate the deadlock,
set the DB2_RR_TO_RS environment variable from the DB2 command line window.
Setting this environment variable causes the following:
- If RepeatableRead (RR) is your chosen isolation level, it is essentially
downgraded to Read Stability (RS).
- If you chose a different isolation level and the DB2_RR_TO_RS environment
variable is turned on, scans of the database skip rows that are deleted but
not committed. This activity occurs even if the row qualified for the scan.
The skipping behavior affects the RR, RS, and Cursor Stability (CS) isolation
levels.
Possible scenario
Transaction A deletes the row
with column1=10 and transaction B does a scan
on column1>8 and column1<12.
With DB2_RR_TO_RS=OFF, transaction B waits for
transaction A to commit or roll back. If transaction A rolls back, the row
with column1=10 is included in the result set
of the transaction B query. With DB2_RR_TO_RS=ON transaction B does
not wait for transaction A to commit or roll back. It immediately receives
query results that do not include the deleted row.
As a workaround,
set the DB2_RR_TO_RS enviroment variable to ON by typing DB2_RR_TO_RS=ON on
the command line.
Information about the StaleConnectionException
on Linux systems
The StaleConnectionException
SQl1224 is related to the extension shared memory attachment. Linux systems
have a semaphore problem causing the DB2 SQL1224 error.
To work around
the problem, set the loopback for your database. For example, if your database
is WAS, host name is LHOST, database service port number is 50000, issue the
following commands from the DB2 command-line window:
db2 catalog TCPIP node RHOST remote LHOST server 50000
db2 catalog db WAS as WASAlias
db2 uncatalog db WAS
db2 catalog db WASAlias as WAS at node RHOST
Verify this information by issuing the following commands from
the DB2 command-line window:
db2 connect to WAS user xxx
passwd: xxx
where xxx is the user
name or password
Setting connection autoCommit to false does
not work correctly in a global transaction or a local transaction when you
use the DB2 Universal JDBC provider driver
Setting connection autoCommit
to false does not work correctly in a global transaction or a local transaction
when you use the DB2 Universal JDBC provider driver.
In a global transaction:
When
you call a connection.setAutoCommit(false) in a global transaction, an incorrect
exception DSRA9350E: Operation setAutoCommit is not allowed during a
global transaction is thrown.
In a local transaction:
When
you call cconnection.setAutoCommit(false), you can do work to the connection
and call connection.setAutoCommit(false) again on the same connection. The
second connection.setAutoCommit(false) commits the previous work. This behavior
is the same as the behavior of the native DB2 universal JDBC driver but is
not consistent with the behaviors when you use other JDBC drivers in WebSphere
Application Server. The correct WebSphere Application Server behavior is
that the second connection.setAutoCommit(false) does not commit the previous work.
Apply
interim fix PQ73523 to solve this problem.
SQL1224N exception is thrown
when you run process choreographer applications which use compensation using
DB2/390 server with a DB2 V8.1 client
When you run an application
using compensation functionality that connects to a DB2/390 server with a
DB2 version 8.1 client, the following exception is thrown:
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] SQL1224N A database agent could not be
started to service a request,or was terminated as a result of a database system shutdown or a
force command. SQLSTATE=55032
To fix this problem, use a DB2 V7.2 client to connect to the DB2/390
server.
This problem does not appear using the older client. If
DB2 V7.2 client is not available, you can increase the value of MAXAGENTS
in the client database manager (DBM) configuration. This reduces the likelihood
of this problem.
Databases- IBM Cloudscape
Application table lock can occur in IBM Cloudscape
when using RepeatableRead
When your application uses a new Version
5 data source on the IBM Cloudscape database, your application can acquire
a table lock when the application tries to use a RepeatableRead isolation
level to select a row in a table for update.
In IBM Cloudscape Version
5.0, the "Select..ForUpdate" statement with a RepeatableRead isolation level
locks the entire table. Another transaction is blocked when it tries to access
the same table. The transaction remains blocked until either the transaction
holding the table lock releases the lock by committing or aborting the transaction,
or when the lock wait times out. If the lock wait results in a deadlock condition,
one transaction aborts and the other transaction continues.
To work
around this problem, take the following action:
- Beans using bean-managed persistence (BMP) or JDBC application:
Define
an index or a key and change the select query to have the "of column" clause,
where the columns are not key fields in the index or key. For example:
create table foo (a int, b int);
create index foo_index on foo (a);
// create a cursor using of column clause to get a row lock
select * from foo where a=100 for update of b;
- Beans using container-managed persistence (CMP):
Avoid using the access
intent of wsPessimisticUpdate profile. This profile results in a RepeatableRead
isolation level on a connection.
The locale JAR files for IBM Cloudscape are available
IBM
WebSphere Application Server now ships the locale JAR files for IBM Cloudscape.
The files are located in the <install_root>lib/cloudscape directory.
To use a specific language, add the respective locale JAR file to the class
path in both the system class path and the administrative console. The class
path of the system is needed for the IBM Cloudscape GUI, for example, cview.
The administrative console is needed for the error messages thrown when running
IBM WebSphere Application Server.
Running IBM WebSphere Application Server with
IBM Cloudscape causes errors
When running IBM WebSphere Application
Server with IBM Cloudscape, you can see the following exception:
SQLException Info: ErrorCode=20000, State=XJ055,
Message: This connection is not attached to any transaction, make sure it has not been ended by the XAResource.
To
fix this problem, verify the statement cache size is 0 on the data
source. The default value is 0.
IBM Cloudscape is not licensed for use in a production
environment
IBM WebSphere Application Server provides a copy of
the IBM Cloudscape database for development use. IBM Cloudscape is a small
footprint database written entirely in the Java language for platform independence.
Developers can use IBM Cloudscape to test Web applications that need to access
data.
IBM Cloudscape is not licensed for use in a production environment.
For
information about IBM Cloudscape, visit the IBM Cloudscape Web site at: http://www.ibm.com/software/data/cloudscape/pubs/collateral.html
Non-English locale of cview does not display
the information tab
When you use cview in a non-English locale,
IBM Cloudscape has a problem displaying the contents of the information tab.
To
work around this problem, view the system information by issuing the command
line version. The command-line version, called sysinfo.bat or sysinfo.ksh, ships with IBM WebSphere Application
Server. If you plan to use the command-line, set the respective locale JAR
file in your class path.
Set JAR file names on class path to use cview
During
IBM WebSphere Application Server installation, the setEmbeddedCP.bat file
is not installed, therefore you cannot use cview.bat or cview.ksh to set the JAR files to the class path.
In order to use cview.bat or cview.ksh,
you need to set the following JAR files on the class path:
<install_root>/lib/db2j.jar
<install_root>/lib/db2jcview.jar
<install_root>/lib/db2jtools.jarSee the setEmbeddedCP.bat file for an example of how to set
these files.
When the IBM WebSphere Application
Server starts, error messages appear in the SystemErr.log file
When
the IBM WebSphere Application Server starts and the IBM Cloudscape database
is used, error messages, which are similar to the following, are written to
the SystemErr.log file:
- Cloudscape is attempting to boot the database /opt/WebSphere/AppServer/installedApps/BRBeansSamples.ear/MovieSampleDB even though Cloudscape may still be active. Only one instance of Cloudscape
should boot a database at a time. Severe and non-recoverable corruption can
result and may have already occurred.
- Could not find plug-in ID or pluginContextRoot in pageContext. Omitting
help icon.
- Help for configProbs does not exist in the mapping file.
- Cloudscape is attempting to boot the database /opt/WebSphere/AppServer/installedApps/TechnologySamples.ear/Database/TechSamp even though Cloudscape may still be active. Only one instance of Cloudscape
should boot a database at a time. Severe and non-recoverable corruption can
result and may have already occurred.
- Cloudscape is attempting to boot the database /opt/WebSphere/AppServer/installedApps/BRBeansSamples.ear/MovieSampleDB even though Cloudscape may still be active. Only one instance of Cloudscape
should boot a database at a time. Severe and non-recoverable corruption can
result and may have already occurred.
The IBM Cloudscape database creates the
db.lck file
to make sure that two Java virtual machines do not start the same database
instance.
For more information and possible solutions, search the IBM
Cloudscape Web site for the frequently asked question entitled, "Why do I
get an error saying other Cloudscape instances are accessing my database?"
WebSphere Process Choreographer
using an IBM Cloudscape database might return a deadlock exception
When
you use the WebSphere Process Choreographer with an IBM Cloudscape database,
a deadlock exception can occur. These deadlock exceptions occur more frequently
on multiprocessor machines.
To work around this problem, retry the
action on the client that caused the exception or re-send your request in
your application.
When IBM Cloudscape rolls back a transaction,
the IBM WebSphere Application Server might display an XANOTA exception
When
IBM Cloudscape rolls back a transaction, it might throw an XANOTA exception,
which the IBM WebSphere Application Server displays.
You can ignore
this exception.
Databases-Informix
An XA exception is thrown during an XA recovery
This
section describes the restriction and solution for a multi-bit flag sent to
an XA recovery.
An XA exception is thrown during an XA recovery due
to Informix defect 161882. This exception can be caused by one of the following
conditions:
- A shutdown of WebSphere Application Server with an application still running
XA transactions.
- A WebSphere Application Server crashes.
An example of the exception is as follows:
33433c9f XARminst F WTRN0017W: The transaction service encountered an error on an xa_recover operation. The resource was CMXAResourceInfo: DataSource Properties [com.informix.jdbcx.IfxXADataSource]: {user=informix;password=XXXXXXXX;description=DataSource for LifeInsApp;portNumber=1527;databaseName=ann;ifxIFXHOST=ifxHost;serverName=ol_ifxHost;}. The error code was XAER_INVAL.
The exception stack trace
follows:
javax.transaction.xa.XAException
at com.informix.jdbcx.IfxXAResource.recover(IfxXAResource.java:310)
at com.ibm.ejs.jts.jta.XARminst.recover(XARminst.java:126)To
avoid this error, delete the WebSphere Application Server transaction log
in the /<WAS_HOME>/tranlog directory before bringing the WebSphere
Application Server on-line.
Informix JDBC driver incorrectly handles escaped
newline character
Informix JDBC driver incorrectly handles inserting
quoted ANSI control characters into column types CHAR and LVARCHAR. The control
characters stored into the column might not be correctly retrieved.
Informix JDBC driver incorrectly handles ANSI
control characters in a SELECT statement
Informix JDBC driver incorrectly
handles ANSI control characters in a SELECT statement. A statement like "SELECT
* FROM TABLE1 WHERE TESTCOL = '\n'''" produces the following SQLException:
SQL State: IX000
Error Code: -282
java.sql.SQLException: Found a quote for which there is no matching quote.
The Informix JDBC provider produces errors when
writing character data to a Character Large Object file
When attempting
to write character data to a Character Large Object (CLOB) field using the
setCharacterStream method on the Informix JDBC provider, the following exception
occurs:
java.sql.SQLException: Can't convert fromnull
at com.informix.util.IfxErrMsg.getSQLMinorException(IfxErrMsg.java:511)
at com.informix.jdbc.IfxObject.fromCharacterStream(IfxObject.java:856)
at com.informix.jdbc.IfxValue.makeInstance(IfxValue.java:1091)
at com.informix.jdbc.IfxPreparedStatement.setCharacterStream(IfxPreparedStatement.java:3202)
at JDBCDriverTest.main(JDBCDriverTest.java:69)This problem
has been reported to Informix.
Exception thrown when running an XA transaction
When
running an XA transaction involving two connections to the same database,
the following pattern results in an exception:
get XA connection 1
get XA connection 2
start XA resource for connection 1
start XA resource for connection 2
Connection 1: insert a new record into a table T1
Connection 2: update an existing record in the same table --> exception is thrown here
You
get the following exception:
java.sql.SQLException: ISAM error: record is locked.
java.sql.SQLException: Could not do a physical-order read to fetch next row.
at com.informix.jdbc.IfxSqli.addException(IfxSqli.java:3021)
at com.informix.jdbc.IfxSqli.receiveError(IfxSqli.java:3335)
at com.informix.jdbc.IfxSqli.dispatchMsg(IfxSqli.java:2288)
at com.informix.jdbcx.IfxXASqli.receiveMessage(IfxXASqli.java:119)
at com.informix.jdbc.IfxSqli.executeCommand(IfxSqli.java:720)
at com.informix.jdbc.IfxResultSet.executeUpdate(IfxResultSet.java:317)
at com.informix.jdbc.IfxStatement.executeUpdateImpl(IfxStatement.java:838)
at com.informix.jdbc.IfxPreparedStatement.executeUpdate(IfxPreparedStatement.java:269)
at InfXATest.run2(InfXATest.java:289)
at InfXATest.main(InfXATest.java:11)Currently, there
is no work around for this problem. The problem has been reported to Informix.
OUT parameters not supported in Informix
Dynamic Server 9.3
The Informix Dynamic Server 9.3 does not support
multiple OUT parameters in functions or procedures as required by the JDBC
2.0.
PTS#154442 has been opened with Informix to resolve this problem.
LOCATE function not supported in Informix
Dynamic Server 9.3
The Informix Dynamic Server 9.3 does not support
the locate function as required by the JDBC 2.0.
Two-phase commit transactions cause Informix
Dynamic Server 9.3 to crash
Two-phase commit transactions sometimes
cause Informix Dynamic Server 9.3 to crash. This problem is addressed in Informix
bugs 158717 and 158860.
Prepared statement cache does not work
with two-phase commit and Informix Dynamic Server (IDS) 9.3 data sources
Prepared
statement caching does not work with two phase commit and Informix Dynamic
Server 9.3 data sources. This will be addressed in a future release of IDS.
INOUT parameters not supported in Informix
Informix
Dynamic Server does not support INOUT parameters in functions or procedures
as required by the JDBC 2.0.
PTS#159522 has been opened with Informix
to resolve this problem.
Binary Large Object not supported in
Informix
Informix Dynamic Server does not support Binary Large Objects
(BLOBS) in the DISTINCT clause of a SELECT statement as required by the JDBC
2.0.
PTS#159333 has been opened with Informix to resolve this issue.
Importing a business rule
XML file can cause a BusinessRulesBeansException error when used with a JDBC
XA Driver
If the Informix JDBC XA driver is configured and the Business
Rule Beans rules browser is used to import an XML file, a BusinessRuleBeansException
error might occur when you attempt to create a rule.
When you use Business
Rule Beans with an Informix database, use the Informix JDBC connection pool
driver.
Databases-Microsoft SQL Server
Connect JDBC
All platforms
Microsoft JDBC Driver for SQL Server 2000
All
platforms
Use the proper DataStoreHelper class to configure
data sources for the Connect JDBC driver
If you use the WebSphere
Embedded Connect JDBC driver for Microsoft SQL Server, you must use the proper
DataStoreHelper class. If you use an incorrect DataStoreHelper class, either
of the following exceptions might occur:
java.sql.SQLException: [IBM][SQLServer JDBC Driver]This driver is locked for use with embedded applications.
at com.ibm.websphere.jdbc.base.BaseExceptions.createException(Unknown Source)
at com.ibm.websphere.jdbc.base.BaseExceptions.getException(Unknown Source)
at com.ibm.websphere.jdbc.base.BaseConnection.validatedUnlocked(Unknown Source)
java.sql.SQLException: [IBM][SQLServer JDBC Driver]?}???h???C?o???A?????????A?v???P?[?V?????????g?p?????b?N???????E?B
at com.ibm.websphere.jdbc.base.BaseExceptions.createException(Unknown Source)
at com.ibm.websphere.jdbc.base.BaseExceptions.getException(Unknown Source)
at com.ibm.websphere.jdbc.base.BaseConnection.validatedUnlocked(Unknown Source)
The correct DataStoreHelper class for the WebSphere Embedded Connect
JDBC driver for Microsoft SQL Server and WebSphere Embedded Connect JDBC driver
for Microsoft SQL Server (XA) providers is com.ibm.websphere.rsadapter.WSConnectJDBCDataStoreHelper.
Connect JDBC drivers earlier
than Version 3.1 causes errors when they are used with Business Rule Beans
All
ConnectJDBC drivers earlier than Version 3.1, including the Microsoft driver
and embedded WebSphere Connect JDBC driver, can cause an error when they are
used with Business Rule Beans (BRBeans) or in any JDBC application using the
MSSQLServer type TEXT:
java.sql.SQLException: [IBM][SQLServer JDBC Driver]ResultSet can not re-read row data for column 1.
This error is due to a bug in the ConnectJDBC driver where
values returned in a ResultSet cannot read out of sequence if one of the columns
is of MSSQLServer type TEXT.
To work around this problem:
- If the error occurs with BRBeans, no work around is possible.
- If you are using the embedded WebSphere ConnectJDBC driver or the DataDirect
ConnectJDBC driver, update to Version 3.1.
- If you are using the Microsoft driver, open a case with Microsoft to have
the bug fixed.
If the error occurs in a JDBC application, perform the following
steps:
- Change the database table so it does not define any columns of type TEXT.
- Change the JDBC application to reads fields only in sequence.
- Change the JDBC application to retrieve the row whenever the data is needed
out of sequence.
MDAC 2.6 SP1 is a prerequisite for SequeLink Server
5.3
MDAC 2.6 SP1 is a prerequisite for SequeLink Server 5.3. You
can download this prerequisite from the Microsoft Web site at http://www.microsoft.com
.
Microsoft SQL Server 7 error occurs when using
UPDLOCK hint
When running SequeLink 5.3 against SQLServer 7 and
setting ResultSet concurrency = CONCUR_UPDATABLE, ResultSet type
= TYPE_SCROLL_SENSITIVE, the following error occurs when executing a statement
containing the UPDLOCK locking hint:
SQL State: 42000
Error Code: 16940
java.sql.SQLException: [IBM][SequeLink JDBC Driver][SQL Server]Cannot specify UPDLOCK or TABLOCKX with READ ONLY or INSENSITIVE cursors.
This error is caused by a bug in Microsoft SQL Server 7. The SequeLink
5.3 driver provides the following workaround for this problem:
- Open the Microsoft Management Console for SequeLink 5.3 ( %SL53%\admin\sladmin53.msc ).
- Expand SLAgent53 > SequeLink Services > SLSQLServer53 > Configuration > Data
Source Settings > Default.
- Right-click Default and then click New > Attribute.
- Click DataSourceMSSCursortype and fill in a value of Clientside.
- Click OK to add the attribute and then select the yellow check
mark box at the top of the console to save the changes.
- The property appears in the Advanced folder under the Default
data source, if you want to change or delete it later.
Instructions for installing the SequeLink 5.3
server
The WebSphere Application Server, Version 5 InfoCenter does
not include documentation for installing the SequeLink 5.3 server that ships
with WebSphere Application Server. Visit the following Web page of DataDirect
Technologies driver for instructions on installing the SequeLink 5.3 server:
ftp://ftp.software.ibm.com/software/websphere/info/tools/DataDirect/datadirect.htm
The DataDirect Technologies SequeLink 5.3 JDBC
driver can ignore local transactions
The DataDirect Technologies
SequeLink 5.3 JDBC driver contains a bug which can ignore local transaction
rollbacks after a connection is used in a global transaction. DataDirect
Technologies has provided a patch for this problem, which you can download
from:
ftp://ftp.software.ibm.com/software/websphere/info/tools/DataDirect/datadirect.htm
Do not use DBUser and DBPassword
Do
not use DBUser and DBPassword or HUser and HPassword data source properties
for SequeLink 5.3. User names and passwords specified this way are exposed
in WebSphere traces and XML files. Instead, specify this information by creating
an alias for the data source.
Additionally, even if you are not concerned
about exposed passwords and DBUser and DBPassword are specified, SequeLink
does not honor the values used, so this method of specifying user names and
passwords is unreliable.
The DataDirect Technologies SequeLink JDBC
driver hangs when running in two-phase commit mode
The DataDirect
Technologies SequeLink JDBC driver can hang when it runs in two-phase commit
mode against Microsoft SQL Server 7. Case 15005170 is open with DataDirect
Technologies for this problem.
To work around this problem, take one
of the following actions:
- Using the DataDirect Technologies Connect JDBC driver connect to the Microsoft
SQL Server 7 instead of the SequeLink.
- Upgrade to Microsoft SQL Server 2000 and continue using the SequeLink
JDBC driver to connect.
- Use a SequeLink data source enabled for one-phase commit mode and recode
your application to use only one-phase commit mode.
- When a patch becomes available from DataDirect Technologies, download
a corresponding patch for the WebSphere Application Server embedded SequeLink
driver from the DataDirect Technologies driver update download page. The
URL for this page is: ftp://ftp.software.ibm.com/software/websphere/info/tools/DataDirect/datadirect.htm
The Microsoft JDBC driver for Microsoft
SQL Server 2000 fails
The Microsoft JDBC driver for Microsoft SQL
Server 2000 fails with a java.lang.NoClassDefFoundError when DataSource.setLogWriter is used, spyAttributes are
specified, or IBM WebSphere Application Server tracing is enabled.
The
problem occurs because Microsoft does not include the spy.jar file
in its JDBC driver for Microsoft SQL Server 2000 despite the fact that the
driver requires classes found in the file spy.jar to
function properly. Consequently, the Microsoft driver fails with the NoClassDefFoundError when
IBM WebSphere Application Server tracing is enabled. Workaround options follow:
- Open a problem report with Microsoft.
- Use the embedded WebSphere ConnectJDBC driver instead of the Microsoft
driver.
- Obtain a compatible spy.jar file from some
other source. Neither of the spy drivers which ship with the IBM WebSphere
Application Server (intended only for use with the WebSphere embedded drivers)
are compatible with the Microsoft driver.
- Avoid all uses of DataSource.setLogWriter, spyAttributes, and IBM WebSphere Application Server
tracing.
The Microsoft driver for Microsoft SQL Server
2000 ignores setAutoCommit(true) during a local
transaction
The Microsoft driver for Microsoft SQL Server 2000 does
not honor setAutoCommit(true) during a local transaction.
The driver continues to operate as though autoCommit is false while reporting
a value of autoCommit = true. This behavior can cause unexpected activity
since it is inconsistent with the JDBC specification. According to the JDBC
specification, setting autoCommit to true during a local transaction
implicitly commits any outstanding local transaction and changes the connection
to autoCommit enabled (true) mode.
Perform one of the following
steps to work around the problem:
- Open a problem report with Microsoft.
- Use the embedded WebSphere ConnectJDBC driver instead of the Microsoft
driver.
- Do not rely on the use of setAutoCommit(true) to
end local transactions.
Databases-Oracle
All platforms
Oracle JDBC driver memory leak
If you
use Oracle 9i R2, you can encounter memory leaks when using the Oracle XA
JDBC driver.
To fix this problem, visit the Oracle Metalink Web site
and download Oracle Patchset 92020.
Oracle rollbacks fail with bean-managed persistence
and unshareable mode
When running a Global transaction with an unshareable
mode where two or more connections are created as part of the Global transaction,
Oracle throws the exception "ora-02051: another session
in same transaction failed" when doing a rollback or commit on the Global
transaction.
Use Sharable mode when running a bean-managed persistence
(BMP) or servlet to work around the problem as follows:
- BMP:
Set the res-sharing-scope tag to Sharable in the ejb-jar.xml file,
which is found in the META-INF directory of the yourbean.jar file. For example:
<res-sharing-scope>Shareable</res-sharing-scope>
- Servlet:
Set the res-sharing-scope tag to Sharable in the web.xml file,
which is found in the WEB-INF directory of the .war file. For example:
<res-sharing-scope>Shareable</res-sharing-scope>
This situation is a recognized Oracle problem. The Oracle bug
number is 2511780.
Error message displays when inserting or updating
a LOB data type
When using the LOB columns (BLOBS and CLOBS) with
Oracle 8i, you cannot use setCharacterStream or setBinaryStream to set BLOBS
and CLOBS when the size of the LOB columns is greater than 4k.
You receive
one of the following error messages when inserting or updating a LOB (BLOBS
and CLOBS) that are greater than 4k, depending on the Oracle release:
"Data size bigger than Max size for this type: xxxx. SQL State = <null>, Error Code = 17,070"
"java.sql.SQLException: Io exception: End of TNS data channel SQL State: null Error Code: 17002"
Oracle
has lifted the restriction in the 9i R2 OCI driver (thick driver). If you
have one of these error messages or you know that your data exceeds 4k, update
to Oracle 9i R2 and use the OCI driver when connecting to Oracle server. If
you cannot update to Oracle 9i R2, contact Oracle Support.
Setting the correct value for autoCommit in
the connection of the OracleXADataSource
When your application tries
to use the OracleXADataSource to run in an autoCommit enabled mode, set the
autoCommit value to TRUE once a connection is obtained from the OracleXADatasource.
The default autoCommit value for every connection from the XA data source
is FALSE. This value is different from the OracleConnectionPoolDataSource,
which has the default autoCommit value of TRUE.
If your application
runs in a global transaction, set the autoCommit value to FALSE to
start a global transaction.
Bug#2618770 has been accepted by Oracle
for this problem.
Using OCI drivers requires 32-bit Oracle libraries
If
you are using the OCI drivers, you must use 32-bit Oracle libraries.
Set
the OCI driver on Oracle as follows:
- (Optional, might already exist) Update entries in the listener.ora file
on the server side. You can find the DESCRIPTION_LIST and SID_LIST in the $ORACLE_HOME/network/admin directory.
Modify the entries in the << >>.
Add the following to the DESCRIPTION_LIST entry:
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP) (HOST = <<host_name>>) (PORT = 1521))
)
Add the following to the SID_LIST:
(SID_DESC =
(GLOBAL_DBNAME = <<database_name >>)
(ORACLE_HOME = <<oracle_home>> )
(SID_NAME = <<database_name>>)
)Note: An example of <<database_name>> is "was".
An example of <<oracle_home>> is E:\Oracle\Ora81.
- Update entries in the tnsnames.ora file located
in $ORACLE_HOME/network/admin directory. You are
modifying the entries in the << >>.
Add the following to the tnsnames.ora file:
tnsname =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP) (HOST = <<server_name>>) (PORT = 1521) )
)
(CONNECT_DATA =
(SERVICE_NAME = <<database_name >>)
)
)Note: An example of <<database_name>> is "was".
- Add the location where Oracle is installed in the .profile export,
for example ORACLE_HOME:<oracle_root_install>.
- Add the following to the Native Library Path in the administrative console:
For
AIX systems:
export LD_LIBRARY_PATH=$ORACLE_HOME/lib32
For
Solaris Operating Environment and other platforms:
export PATH=$ORACLE_HOME/lib32
For
Hewlett Packard environment:
export SHLIB_PATH=$ORACLE_HOME/lib32
- Add the following to the class path of the administrative console:
export CLASSPATH=$ORACLE_HOME/jdbc/lib/classes12.zip: $ORACLE_HOME/jdbc/lib/nls_charset12.zip
- Set the URL inside the administrative console using the following format:
jdbc:oracle:oci8:@<tnsname>
where <tnsname> is
what is defined in the tnsames.ora file
Oracle XA driver displays an error when using an
autoCommit true value followed by a global transaction
When running
the IBM WebSphere Application Server against an Oracle driver, problems occur
when the Oracle XA driver uses autoCommit with a value of true, followed
by a global transaction.
If you encounter this problem, set autoCommit
to false before starting the global transaction on the same connection.
TAR
2603121.995 has been opened with Oracle to resolve this problem.
Using PreparedStatement.setObject fails for some
types with ClassCastException
Using PreparedStatement.setObject
fails for some types with ClassCastException when using Oracle.
The
following incorrect uses of setObject fail with ClassCastException instead
of successfully updating the table:
// Test use the following tables
create table Bit_Tab (MAX_VAL SMALLINT, MIN_VAL SMALLINT, NULL_VAL SMALLINT NULL);
create table Decimal_Tab (MAX_VAL DECIMAL(30,15),MIN_VAL DECIMAL(30,15), NULL_VAL DECIMAL(30,15) NULL);
create table Bigint_Tab (MAX_VAL NUMBER(19,0), MIN_VAL NUMBER(19,0), NULL_VAL NUMBER(19,0) NULL);
create table Timestamp_Tab (IN_TIME DATE, NULL_VAL DATE NULL);
// Tests use the following prepared statements
pstmt1i = con.prepareStatement("insert into Bit_Tab VALUES(?, ?, ?)");
pstmt2i = con.prepareStatement("insert into Decimal_Tab VALUES(?, ?, ?)");
pstmt3i = con.prepareStatement("insert into Bigint_Tab VALUES(?, ?, ?)");
pstmt4i = con.prepareStatement("insert into Timestamp_Tab VALUES(?, ?)");
pstmt5i = con.prepareStatement("insert into Decimal_Tab VALUES(?, ?, ?)");
// failing code snippets
// Test 1 - Boolean
pstmt1i.setBoolean(1,true);
pstmt1i.setBoolean(2,true);
java.math.BigDecimal decimalVal = new java.math.BigDecimal(1);
Boolean minDecimalVal=new Boolean(decimalVal.toString());
pstmt1i.setObject(3,minDecimalVal,java.sql.Types.DECIMAL,2);
pstmt1i.executeUpdate();
// Test 2 - Float
pstmt2i.setFloat(1,2.1F);
pstmt2i.setFloat(2,2.2F);
String stringVal = "1.1";
Float floatVal = new Float(stringVal);
pstmt2i.setObject(3,floatVal,java.sql.Types.DECIMAL,15);
pstmt2i.executeUpdate();
// Test 3 - Long
pstmt3i.setFloat(1,3.1F);
pstmt3i.setFloat(2,3.2F);
Long val = new Long(1);;
String stringValLing = new String(val.toString());
Long longVal = new Long(stringValLing);
pstmt3i.setObject(3,longVal,java.sql.Types.CHAR);
pstmt3i.executeUpdate();
// Test 4 - Timestamp
pstmt4i.setTimestamp(1, new Timestamp(System.currentTimeMillis()));
pstmt4i.setTimestamp(2, new Timestamp(System.currentTimeMillis()));
Timestamp getTSval = new Timestamp(System.currentTimeMillis());
String stringValTs = getTSval.toString();
Timestamp timeStampVal = Timestamp.valueOf(stringValTs);
pstmt4i.setObject(2,timeStampVal,java.sql.Types.DATE);
pstmt4i.executeUpdate();
// Test 5 - BigDecimal
pstmt5i.setFloat(1, 5.1F);
pstmt5i.setFloat(2, 5.2F);
String stringValBd = "1.1";
stringValBd = stringValBd.trim();
java.math.BigDecimal bigDecimalVal = new BigDecimal(stringValBd);
pstmt5i.setObject(3,bigDecimalVal,java.sql.Types.CHAR);
pstmt5i.executeUpdate();To avoid getting the exception, change
the code to avoid using setObject.
This problem is being addressed by
Oracle in the bug report 2640294.
Oracle fails to throw SQLExceptions
Oracle
fails to throw an SQLException when the incorrect type of SQL statement is
used on either the PreparedStatement.executeUpdate() or PreparedStatement.executeQuery()
methods.
Only use SQL statements returning a count with the executeUpdate()
method, and only use SQL statements returning a single result set with the
executeQuery() method.
The database generates an SQLException if an
SQL statement fails to meet the requirement it passes to either executeUpdate
or executeQuery. When using Oracle, executeUpdate and executeQuery return
successfully when passed by an SQL statement that fails to meet the requirement.
When
running with Oracle, the following code snippet does not return SQLException:
pstmt1 = con.prepareStatement("select * from Bit_Tab");
pstmt2 = con.prepareStatement("insert into Bit_Tab VALUES(?, ?, ?)");
//Test 1 - executeUpdate using select
try
{
pstmt1.executeUpdate();
}
catch (SQLException e)
{
System.out.println("SQLException occurred");
}
// Test 2 - executeQuery using insert
try
{
pstmt2.setBoolean(1,true);
pstmt2.setBoolean(2,true);
pstmt2.setBoolean(3,true);
ResultSet rs = pstmt2.executeQuery();
}
catch (SQLException e)
{
System.out.println("SQLException occurred");
}TAR 2688461.999 has been opened with Oracle to resolve this
problem.
CONM6021W messages appear when an Oracle
9.2.0.2 server and a 2511780 patch are used
If you use an Oracle
9.2.0.2 server, apply the 2511780 patch, and create the transactionBranchesLooselyCoupled
custom property for a 4.0 data source, the CONM6021W messages appear
every time a 4.0 data source connection is created.
The CONM6021W message
is similar to the following example:
CONM6021W: An Oracle JDBC provider property (TransactionLooselyCoupled) has been set. Oracle patch 2511780 must be applied before setting this property.
You can see this message frequently in the server SystemOut.log file.
Oracle does not support the three-argument version
of the locate function in the Solaris Operating Environment J2EE compliance
test suite
While running
the IBM WebSphere Application Server in the Solaris Operating Environment
J2EE Compliance test suite against Oracle, the three-argument version of the
locate function is not supported by Oracle. The two-argument version is supported
by Oracle. According to Oracle, the three-argument version of the locate function
is not part of the J2EE specifications.
Oracle thin driver does not support null user
ID and password and this causes an SQLException
When you run WebSphere
Application Server with Oracle, if you do not set the J2C authentication alias
or you do not use getConnection (user ID and, password ), a null is passed
to Oracle for user ID and password. Since Oracle thin does not support null
user ID and password, Oracle throws the following exception:
java.sql.SQLException: invalid arguments in call
To
work around the problem, set the J2C authentication alias on the data source
and restart the server.
Databases-Sybase
Executing the DatabaseMetaData.getBestRowIdentifier()
method in an XA transaction causes errors
Executing the DatabaseMetaData.getBestRowIdentifier()
method while in an XA transaction causes the following errors:
SQL Exception: The 'CREATE TABLE' command is not allowed within a
multi-statement transaction in the 'tempdb' database. Calling
DatabaseMetaData.getBestRowIdentifier()
Currently, this method
fails when using Sybase. This problem occurs with other methods as well, including:
- getBestRowIdentifier();
- getVersionColumns();
- getTablePrivileges();
- getProcedureColumns();
- getPrimaryKeys();
- getIndexInfo();
- getImportedKeys();
- getExportedKeys();
- getCrossReference();
- getColumns();
- getColumnPrivileges();
Case 10880427 has been opened with Sybase to resolve this problem.
Sybase requirements for using the escapes and DatabaseMetaData
methods
To use the escapes and DatabaseMetaData methods, you must
install stored procedures on the Adaptive Server Enterprise or Adaptive Server
Anywhere database where you want to use these methods. These stored procedures
are also required by some of the connection methods.
To check for the
presence of LOCATE ():
- Open a Sybase isql command prompt.
- Type the command use master.
- Type the command go.
- Type the SQL command and select * from jdbc_function_escapes.
- Type the command go.
The following appears:
escape_name
map_string
----------------------------------------
----------------------------------------
abs
abs(%1)
acos
acos(%1)
asin
asin(%1)
atan
atan(%1)
atan2
atn2(%1, %2)
ceiling
ceiling(%1)
:::::::::::::::::::
:::::::::::::::::::
locate
charindex ((convert (varchar, %1)), (convert (varchar, %2)))If
the function does not exist, upgrade jConnect to at least Version 5.2 EBF
10635 and run the following command:
java IsqlApp -U sa -P -S jdbc:sybase:Tds:<hostname>:4100 -I %JDBC_HOME%\sp\sql_server12.sql -c go
Database deadlocks and XA_PROTO errors
occur when using Sybase
When using Sybase with the IBM WebSphere
Application Server, do one of the following to prevent database deadlocks
and errors:
- Change the transaction isolation level on the connection to TRANSACTION_READ_COMMITTED.
Set the isolation level on the connection for unshareable connections or,
for shareable connections, define the isolation levels in the resource reference
for your data source using the Application Assembly Tool (AAT).
- Modify Sybase by doing one of the following:
Executing a stored procedure containing a SELECT
INTO command causes exception
An attempt to execute a stored
procedure containing a SELECT INTO command results in the following
exception:
SVR-ERROR: SQL Exception SELECT INTO command not allowed within multi-statement transaction
Case
10868947 has been opened with Sybase to resolve this problem.
Error is incorrectly reported about IMAGE
to VARBINARY conversion
The following error is incorrectly reported:
com.sybase.jdbc2.jdbc.SybSQLException: Implicit conversion from data type 'IMAGE' to 'VARBINARY' is not allowed.
Use the CONVERT function to run this query.
The error is about
a VARBINARY column only and causes confusion if you also have an IMAGE column.
Do
one of the following to work around this problem:
- Use a PreparedStatement.setBytes() method instead of a PreparedStatement.setBinaryStream()
method
- Use a LONG VARBINARY for the column type if you want to continue using
the setBinaryStream() method. You might want to make this change because the
size limit for VARBINARY is 255 bytes.
For example:
// ***************CORRECTION*****************************
// setBinaryStream fails for column type of VARBINARY , use setBytes() instead
//stmt4.setBinaryStream(8,new java.io.ByteArrayInputStream(tempbyteArray),tempbyteArray.length);
stmt4.setBytes(8,tempbyteArray);Java Database Connectivity 1.0 standard methods
are not implemented and generate a SQL exception when used
The following
Java Database Connectivity (JDBC) 1.0 standard methods are not implemented
and generate a SQL exception when used:
- ResultSetMetaData.getSchemaName()
- ResultSetMetaData.getTableName() (implemented only for text and image
datatypes)
- ResultSetMetaData.getCatalogName()
Sybase transaction manager fails after trying
to alleviate a deadlock error
If an application encounters a deadlock,
Sybase detects the deadlock and throws an exception. Because of this detection,
the transaction manager calls an xa_end with a TMFAIL in it.
The call succeeds, but causes
another Sybase exception, XAERR_PROTO. This exception
only appears in the error log and does not cause any functional problems.
All applications should continue to run, therefore no workaround is necessary.
Case
10869169 has been opened with Sybase to resolve this problem.
Starting an XA transaction when the autoCommit
value of the connection is false causes error
The exception
thrown is javax.transaction.xa.XAException with
stack trace similar to the following:
at com.sybase.jdbc2.jdbc.SybXAResource.sendRPC(SybXAResource.java:711)
at com.sybase.jdbc2.jdbc.SybXAResource.sendRPC(SybXAResource.java:602)
at com.sybase.jdbc2.jdbc.SybXAResource.start(SybXAResource.java:312)This
problem affects you when you do both local and global transactions. If, in
a local transaction, the autoCommit default value is set to false,
and a global or XA transaction starts (either a user transaction started by
you, or a container transaction started by a container), the exception occurs.
This
problem is a Sybase bug as the start() method can fail unexpectedly, regardless
of the value of autoCommit. Currently, there is no workaround for this problem,
therefore it is not recommended that you mix local and global transactions.
Case 10880792 has been opened to resolve this problem.
Sybase does not throw an exception when an incorrect
database name is specified
Verify that your database name is correctly
entered on the data source properties.
Most databases (DB2, Oracle,
Informix , MS SQL Server and Cloudscape) throw an exception when the database
specified does not exist. But Sybase does not throw an exception when an incorrect
database name is specified. Sybase generates an SQL warning and then connects
to the default database. If you misspell the requested database name, Sybase
connects you to the master or the default database where the table you requested
is not found.
Interoperability
Interoperability of the handle
formats in WebSphere Application Server, Version 5 and Version 5.0.1
Applications
that attempt to persist handles to enterprise beans and EJBHome needed
to subclass ObjectInputStream in WebSphere Application Server, Version 5.
This action was required so that the subclass ObjectInputStream could utilize
the context class loader to resolve the classes for enterprise beans and EJBHome
stubs.
In addition, handles created and persisted in WebSphere Application
Server, Version 5 only work with objects that have an unchanged remote interface.
If the remote interface is changed, the handle is no longer valid because
the stub is serialized inside the handle and its serial Version UID changes
if the remote interface changes.
This release introduces a new handle
persistence mechanism that avoids the implementation drawbacks of the previous
version. However, if handles are used for this WebSphere Application Server
deployment, you should consider the following issues when applying this update,
future WebSphere Application Server Fix Packs and EJB Container cumulative
fixes for WebSphere Application Server, Version 5.
If a WebSphere Application
Server, Version 5 persisted handle or home handle is encountered by a WebSphere
Application Server, Version 5.0.1 system, it can be read and utilized. In
addition, it will be converted to WebSphere Application Server, Version 5.0.1
format if it is re-persisted. The WebSphere Application Server, Version 5.0.1
format cannot be read by a WebSphere Application Server, Version 5 system
unless PQ72184 is applied.
Problems arise when handles are persisted
and shared across systems that are not at the WebSphere Application Server,
Version 5.0.1 level or later. However, a Version 5 system can receive a handle
from Version 5.0.1 remotely through a call to get a handle on an enterprise
bean or a getHomeHandle on an EJBHome. The remote call will succeed,
however, any attempt to persist it on the Version 5 system will have the same
limitations regarding the use of ObjectInputStream and changes in remote interface
invalidating the persisted handle.
When your application stores handles
persistently and shares this persistence with multiple clients or application
servers, apply WebSphere Application Server, Version 5.0.1 or PQ72184 to both
the client and server systems at the same time. Failure to do so can result
in the inability of these systems to read the handle data stored by upgraded
systems. Also, handles stored by the WebSphere Application Server, Version
5 can force the applications of the updated system to still subclass ObjectInputStream.
Applications using the WebSphere Application Server Enterprise, Version 5
scheduler and process choreographer, are affected by these changes. These
users should update their Version 5 systems at the same time with either Version
5.0.1 or PQ72184.
If the applications store handles in the session context,
or locally in a file on the same system, that is not shared by other applications,
on different systems, they might be able to update their systems individually,
rather than all at once. If Client Container and thin client applications
do not share persisted handle data, they can be updated as needed as well.
However, handles created and persisted in WebSphere Application Server, Version
5, Version 4.0.3 and later (with the property flag set), or Version 3.5.7 and
later (with the property flag set) are not usable if either the home or the
remote interface changes.
If any WebSphere Application Server, Version
3.5.7 or Version 4.0.3 and later enables the system property com.ibm.websphere.container.portable
to true, any handles to objects on that server have the same interoperability
limitations. In addition, if any WebSphere Application Server, Version 3.5.7
and later or Version 4.0.3 applications store a handle obtained from a WebSphere
Application Server, Version 5 or Version 5.0.1, the same restrictions apply,
regarding the need to subclass ObjectInputStream and the usability of handles
after a change to the remote interface is made.
Secure interoperability between WebSphere Application
Server, Version 5 and WebSphere Application Server, Version 5.0.1 fails when
the Lightweight Directory Access Protocol base distinguished name in not correctly
normalized in the WebSphere Application Server, Version 5 configuration
In
WebSphere Application Server, Version 5.0.1, the distinguished name is normalized
according to the Lightweight Directory Access Protocol (LDAP) specification.
In WebSphere Application Server, Version 5, the normalization of the distinguished
name is not done. The normalization consists of removing spaces in the base
distinguished name before or after commas and equal symbols.
An example
of a non-normalized base distinguished name is "o = ibm, c = us" or "o=ibm,
c=us". .
An example of a normalized base distinguished name is "o=ibm,c=us".
It
is preferred that the distinguished name is manually normalized when you enter
the base distinguished name in the configuration. In WebSphere Application
Server, Version 5.0.1 and higher version, the normalization occurs automatically
at the run time.
When a WebSphere Application Server, Version 5.0.1
system, which always has a normalized distinguished name, sends a security
token to a WebSphere Application Server, Version 5 system that contains a
non-normalized distinguished name, the request is rejected due to the mismatched
distinguished names during authorization. A common example of a request that
fails is when a WebSphere Application Server, Version 5 node is synchronizing
the configuration from a WebSphere Application Server, Version 5.0.1 deployment manager.
Another example is that a request fails when a WebSphere Application Server,
Version 5.0.1 servlet or enterprise bean makes a downstream request to a WebSphere
Application Server, Version 5 enterprise bean. However, a request going from
a WebSphere Application Server, Version 5 system to a WebSphere Application
Server, Version 5.0.1 system does not fail.
To ensure the interoperability
between WebSphere Application Server, Version 5 and Version 5.0.1, manually
normalize the base distinguished name in the LDAP configuration on a WebSphere
Application Server, Version 5.0 system by removing all the spaces before and
after the commas and equal symbols.
WebSphere Application Server
Enterprise process choreographer interoperability issues
Java
Authentication and Authorization Service (JAAS) dependency
The WebSphere
Application Server Enterprise, Version 5 process choreographer cannot continue
navigation of running business processes after the JAAS implementation (the jaas.jar file)
on the application server machine is replaced or modified. Business processes
started after interim fix PQ72742 or Fix Pack 1 is applied, are not affected.
If you have to replace the jaas.jar file, confirm that no running
business processes are created before applying interim fix PQ72742 or Fix
Pack 1.
Mixed platforms in cluster not supported by process choreographer
The
WebSphere Application Server Enterprise, Version 5 process choregrapher does
not support mixed platforms in a cluster. To enable a cluster with mixed
platforms, apply interim fix PQ72742 or Fix Pack 1. If you plan to run a
mixed platform cluster environment, confirm that no business processes are
running are started before applying interim fix PQ72742 or Fix Pack 1.
Mixed
versions not supported by process choreographer
Business processes
started with the WebSphere Application Server Enterprise, Version 5 with interim
fix PQ72742 or Version 5.0.1 using process choreographer do not run on Version
5 without interim fix PQ72742. A cluster must not contain servers that are
not interoperable.
Asynchronous beans interoperability
issues
The WebSphere Application Server Enterprise, Version 5 asynchronous
beans service has interoperability problems that affect how the dependent
services behave in a clustered environment. The issues are related to mixed
versions and platforms of the WebSphere Application Server product.
Asynchronous
beans allow taking snapshots of Java 2 Platform, Enterprise Edition (J2EE)
contextual information from the current servlet or EJB method. This information
can include security information which can be stored using the WorkManager.create(Work
r) method to get a serializable WorkWithExecutionContext object.
If
this WorkWithExecutionContext object is serialized and stored with customer
data, the following information must be reviewed to determine if any steps
must be taken to avoid problems:
- Affected products
- Problem description: security
- Problem description: interoperability
- Recovery and interoperability procedures
- General recovery procedures
Affected products
Both the scheduler and process choreographer
services included with WebSphere Application Server Enterprise, Version 5
are affected by the problems described in this document. Review each service's
respective sections in the Version 5.0.1 release notes or in one of the following
interim fix options for further information:
- PQ72885: Scheduler 5.0 interoperability issues
- PQ72886: Process choreographer 5.0 interoperability issues
Problem description: security
The asynchronous beans
WorkWithExecutionContext object created with the Version 5 asynchronous beans
stores security information incorrectly, which causes deserialization errors
and ASYN9999E errors to display in the WebSphere Application Server
log files. This happens if the interoperating versions of WebSphere Application
Server have different implementations of Java Authentication and Authorization
Service (JAAS). This error can occur when interoperating between two different
platforms or on the same platform, if the JAAS implementation is updated on
any of the servers.
Security information is stored with the WorkWithExecutionContext
object only when the following conditions are true:
- The WorkManager resource used to create the WorkWithExecutionContext object
has the security context policy attribute enabled.
- Global Security is enabled on WebSphere Application Server.
If either of the previous conditions are false, there should not be
an interoperability issue.
If the JAAS implementation JAR files are
updated or changed such that all servers are already experiencing ASYN9999E errors,
apply the original version of the JAAS implementation JAR files used to serialize
the WorkWithExecutionContext data. Or, follow the General recovery procedures
section in this document on each platform that is having the problem. Running
the General Recovery Procedures confirms all data is reserialized to the correct
version.
Problem description: interoperability
To avoid
further problems between releases or platforms of asynchronous beans, the
serialization mechanisms within asynchronous beans are updated. After the
update, a Version 5 asynchronous beans WorkWithExceptionContext object is
not able to deserialize a WorkWithExecutionContext object serialized with
a Version 5.0.1 release or later.
Recovery and interoperability procedures
If
any of the conditions described in the Problem description: security section
of this document are true, all data with a serialized 5.0 WorkWithExecutionContext
object must be re-serialized with the updated format.
Regardless of
whether or not any of the conditions described in the Problem description:
security section of this document are true, apply interim fix PQ72742 to all
WebSphere Application Server Enterprise, Version 5 servers that expect to
interoperate with Version 5.0.1 and later servers. Or, apply interim fix PQ72742
to all Version 5 servers that interoperate with other Version 5 servers that
have PQ72742 applied.
Servers with interim fix PQ72742 or Version 5.0.1
applied are able to read WorkWithExecutionContext data serialized with the
Version 5. Version 5 servers are not able to read data serialized in the PQ72742
or Version 5.0.1 format. If this occurs, the following error displays:
ASYN9999E: Unexpected Exception Occurred: java.io.OptionalDataException
General recovery procedures
- Apply interim fix PQ72742 or Fix Pack 1 to update all affected servers
to the Version 5.0.1 WorkWithExecutionContext level. At this point, all servers
are functioning normally, assuming that the security problems outlined in
this document are not true.
- If any of the conditions described in the Problem description: security
section of this document are true, re-serialize all data. For example, modify
the existing enterprise bean or servlet used to serialize the WorkWithExecutionContext,
so that it rewrites the object using a java.io.ObjectOutputStream:
ObjectInputStream ois = new ObjectInputStream(...);
ObjectOutputStream oos = new ObjectOutputStream(...);
Object in = ois.readObject();
oos.writeObject(in);
oos.flush();
Scheduler interoperability
issues between WebSphere Application Server, Version 5 and Version 5.0.1
The
WebSphere Application Server Enterprise, Version 5 scheduler service has several
interoperability problems that affect how the scheduler behaves in a clustered
environment with mixed WebSphere Application Server versions and mixed platforms.
The
following two issues cause the interoperability problems:
- The EJB HomeHandle format is changed between WebSphere Application Server,
Version 5 and Version 5.0.1. See interim fix PQ72184 or the Interoperability
section of the Version 5.0.1 Release Notes for details.
- The asynchronous beans serialization mechanism is changed between WebSphere
Application Server, Version 5 and Version 5.0.1. See interim fix PQ72742
or the asynchronous beans section of the Version 5.0.1 Release Notes for details.
To avoid the interoperability problems between WebSphere Application
Server, Version 5 and Version 5.0.1 or higher, you must first apply the Version
5 Fix Pack associated with interim fix PQ72184 and interim fix PQ72742, and
remove all the scheduled tasks that were created prior to applying the fix
pack.
Be aware that removing all the scheduled tasks involves removing
data from your scheduler databases. Follow these procedures for each scheduler
instance defined on the affected server:
- Recreating scheduler tasks
- Deleting all scheduler tasks
- Recreating all scheduler tables
Recreating scheduler tasks:
Use this method if you want
to programmatically recreate your scheduled tasks. This step requires advanced
knowledge of writing J2EE applications and the scheduler programming interfaces.
Do
the following steps to recreate all scheduler tasks:
- Use the administrative console to locate each scheduler resource that
was used in WebSphere Application Server, Version 5. For each scheduler resource,
note the Java Naming and Directory Interface (JNDI) name.
- Back up the scheduler database.
- Create a new or modify an existing enterprise bean or servlet J2EE application.
Use the enterprise bean or servlet as a method for the scheduler update program.
- Create a method similar to the following example. This action finds all
existing scheduler tasks, deletes them and creates new ones with the
same parameters. Note: If global security is enabled in the WebSphere
Application Server and the security context is enabled on the Work Manager referenced
by the scheduler resource, the current security context is used,
as well as all other J2EE contexts that are enabled on the created enterprise
bean or servlet thread.
public void recreateTasks(String schedulerJNDIName)
throws Exception
{
InitialContext ctx = new InitialContext();
Scheduler s = (Scheduler)ctx.lookup(schedulerJNDIName);
Iterator tasks = null;;
try
{
tasks = s.findTasksByName("%");
}
catch (SchedulerNotAvailableException e)
{
e.printStackTrace();
throw e;
}
// Iterate through each task and recreate it.
while(tasks.hasNext())
{
TaskInfo curTask = (TaskInfo) tasks.next();
int retries=0;
boolean deleted=false;
TaskStatus status=null;
// It's best to include each cancel/create
// in it's own transaction (not shown here).
while(!deleted && retries < 5)
{
try
{
// Delete the task.
s.cancel(curTask.getTaskId(), true);
deleted = true;
// Create a new one.
int createRetries = 0;
boolean created = false;
while(!created && createRetries<5)
{
try
{
s.create(curTask);
created = true;
}
catch (Exception e)
{
++createRetries;
Thread.sleep(5000);
}
}
if (!created)
{
System.out.println("Task Not Created: " + curTask.getTaskId());
}
}
catch (Exception se)
{
++retries;
Thread.sleep(5000);
}
}
if (!deleted)
{
System.out.println("Task Not Deleted: " + curTask.getTaskId());
}
}
}
Deleting all scheduler tasks:
Use this method
if you want to remove all of your scheduler tasks and recreate them manually.
- Use the administrative console to locate each scheduler resource that
was used in WebSphere Application Server, Version 5. For each scheduler resource,
write down the following:
- Java Database Connectivity (JDBC) data source JNDI name
- Table prefix
- Use the administrative console to locate each JDBC data source and write
down the connection and location parameters.
- Back up the scheduler database.
- Using the native database utilities, remove all of the records for each
scheduler resource for each database written down in steps 1 and 2. The following
SQL query template can be used to remove all records (substitute the table
prefix for <TBLPFX>): DELETE FROM <TBLPFX>TASK
Once the tasks are deleted, new tasks can be created immediately.
In addition, the scheduler service can be active while executing the DELETE
SQL command in step 3. However, the operation might take longer to execute
or might time out if the scheduler has database records that are locked.
Recreating
all scheduler tables
Use this method to drop and recreate the scheduler
tables.
- Use the administrative console to locate each scheduler resource that
was used in WebSphere Application Server, Version 5. For each scheduler resource,
note the following:
- JDBC DataSource JNDI Name
- Table prefix
- Use the administrative console to locate each JDBC data source, and note
the connection and location parameters.
- Back up the scheduler database.
- For each database and table prefix identified in the previous steps,
execute the dropSchemaXXX.ddl and createSchemaXXX.ddl scripts
located in the %install_root%/Scheduler directory of your WebSphere
Application Server where %install_root% is the directory where the
application server is installed. Each DDL script has instructions
on how to edit and execute each script located at the beginning of the respective
script in the form of a comment.
Internationalization service interoperability
issues between WebSphere Application Server, Version 5 and Version 5.0.1
The
WebSphere Application Server Enterprise, Version 5 internationalization service
has an interoperability problem that affects how dependent services and customer
applications behave when deserializing internationalization context across
interoperating WebSphere Application Server, Version 5 and Version 5.0.1 products.
Internationalization
context created by the internationalization service causes an InvalidClassException
when deserialized within the WebSphere Application Server runtime environment.
This is true whenever:
- Internationalization context created by Version 5 and deserialized within
the V5.0.1 runtime environment.
- Internationalization context is created by Version 5.0.1 and deserialized
within the V5 runtime environment.
Because internationalization service documentation does not instruct
customers towards the manual serialization or deserialization of internationalization
context, you should rarely, if ever, directly encounter this problem within
your applications. However, it can manifest indirectly when interoperating
between Version 5 and Version 5.0.1 releases of WebSphere Application Server
Enterprise services that process Java 2 Platform, Enterprise Edition (J2EE)
contextual information. The following services are affected by interim fix
PQ73371:
- Internationalization
- Asynchronous beans
- Scheduler
- Process choreography
To categorically avoid this problem, install the interim fix PQ73371
in all Version 5.0.1 server environments. The following section describes
the specific problematic behaviors.
Problem description: internationalization
When
attempting to deserialize internationalization context imported on an incoming
EJB (RMI/IIOP) method request between interoperating Version 5 and Version
5.0.1 releases of WebSphere Application Server Enterprise, the internationalization
service displays a message indicating an unexpected exception, InvalidClassException,
and then scopes the default locale and time zone of the local Java virtual
machine (JVM) as the caller internationalization context of the EJB method.
Because the internationalization application programming interface (API) provides methods
to set invocation internationalization context, not caller internationalization
context, this behavior is immutable.
This problem appears whenever the
following three conditions exist:
- An EJB method request is invoked between interoperating Version 5 and
Version 5.0.1 releases of WebSphere Application Server Enterprise.
- The internationalization service is enabled in the invoking client or
server environment.
- The internationalization service is enabled in the target server environment.
To avoid this problem, install the interim fix for PQ73371 to all
Version 5.0.1 server environments.
Problem description: asynchronous
beans
Asynchronous beans allow taking snapshots of Java 2 Platform,
Enterprise Edition (J2EE) contextual information from the current servlet
or EJB method. Such a snapshot is taken when using the WorkManager.create(Work
r) method to obtain an instance of WorkWithExecutionContext - a serializable
object that can be stored for future use. An instance of WorkWithExecutionContext
contains internationalization context whenever:
- The WorkManager resource used to create the instance has the com.ibm.ws.i18n context
policy attribute enabled, and
- The internationalization service is enabled.
Due to the internationalization service interoperability problem described
above, deserializing WorkWithExecutionContext objects containing internationalization
context created on the other version fails with an SerialDeserialException.
This is true for:
- Version 5 WorkWithExecutionContext objects containing Internationalization
context are deserialized on V5.0.1.
- Version 5.0.1 WorkWithExecutionContext objects containing Internationalization
context are deserialized on V5.
In the event that asynchronous beans serialization mechanisms process
an inoperable internationalization context within a WorkWithExecutionContext,
and that interim fix PQ72742 is installed in the server environment, asynchronous
beans display a message in the service logs that indicates an unexpected exception
occurred involving the internationalization service:
ASYN9999E: Unexpected Exception Occurred: com.ibm.websphere.asynchbeans.SerialDeserialException: Exception while deserializing a saved service. Service=com.ibm.ws.i18n.
When an asynchronous beans WorkManager begins executing a WorkWithExecutionContext
instance with an invalid or missing internationalization context, and the
internationalization service is enabled, the asynchronous beans scopes the
default locale and time zone of the host JVM to the Work rather than the current
invocation internationalization context.
To avoid this problem, install
the interim fix for PQ73371 to all Version 5.0.1 server environments, and
follow the directions prescribed in section PQ72742.RN.
Problem description:
scheduler
The scheduler service employs the asynchronous beans serialization
mechanisms when persisting a newly created task, and hence, is likewise affected
by the interoperability problem involving internationalization context within
the asynchronous beans WorkWithExecutionContext object.
While preparing
to run a task, if the scheduler service (that is, asynchronous beans serialization)
fails to deserialize the internationalization context, and the internationalization
service is enabled, the scheduler service scopes the default locale and time
zone of the host JVM to that task rather than the current invocation internationalization
context. See "Problem description: asynchronous beans" for error messages
and further details.
To avoid this problem, install the interim fix
for PQ73371 to all Version 5.0.1 server environments, and follow the directions
prescribed in section PQ72742.RN.
Problem description: process choreography
The
process choreographer service employs the asynchronous beans serialization
mechanisms when creating and executing interruptible flows. If a flow is
unable to deserialize the internationalization context, and the internationalization
service is enabled during execution, both compensating tasks and the flows
themselves incorrectly use the default locale and time zone of the local JVM
rather than the current invocation internationalization context. See "Problem
description: asynchronous beans" for error messages and further details.
To
avoid this problem, install the interim fix for PQ73371 to all Version 5.0.1
server environments, and follow the directions prescribed in section PQ72742.RN.
WebSphere Application Server,
Version 5 failed transactions in the transaction log cannot be recovered in
Version 5.0.1
Before applying Fix Pack 1 to an Enterprise node,
recover all failed transactions or delete the contents of the install_root\tranlog directory
before you start WebSphere Application Server. This is generally true. You
must always recover failed transactions in any version of WebSphere Application
Server before applying a fix or fix pack, or before migrating to a new version.
One version of WebSphere Application Server cannot recover a transaction that
failed in another version.
J2EE resources
Misleading scope when installing RAR file at the
server level
When installing a RAR file, by clicking Resources > Resource
Adapters > Install RAR, the scope you define on the Resource
Adapters page has no effect on where the RAR file gets installed. You can
only install RAR files at the node level.The scope on the Install RAR page
determines the node to install. However, the scope you set on the resource
adapters panel determines the scope of the new Resource Adapters, which you
can install at the server, node, or cell level.
Embedded Java Messaging Service provider installation
fails
It is possible for the embedded Java Messaging Service (JMS)
provider installation to fail without any visible warning. This situation
can occur as a result of the JMS provider prerequisite checker returning an
error that the IBM WebSphere Application Server installation is not expecting.
The IBM WebSphere Application Server installation completes, but the JMS provider
is not installed.
If the JMS installation fails, look for details in
the mq_prereq.log file in the /tmp directory and in the create_mq.log and mq_install.log files
in the $WAS_HOME$/log directory. When you have corrected the situation,
install the embedded JMS provider separately by clicking the Custom installation then
selecting either one or both of the following options, as required: Embedded
Messaging Server and Embedded Messaging Client. For more information
about installing the embedded JMS provider, see the InfoCenter article "Installing
WebSphere embedded messaging as the JMS provider".
In the single server environment, the embedded
Java Messaging Service server and IBM WebSphere Application Server run on
the same single Java virtual machine
The embedded Java Messaging
Service (JMS) server and the IBM WebSphere Application Server run on the same
single Java virtual machine. Due to this architecture, if the MQ process (such
as amq*.exe - not JMS process but MQ native proces) dies and restarts while
the JMS server is running, you must restart the IBM WebSphere Application
Server (ordinarily named "server1") manually. This shutdown also can affect
other installed applications.
In the distributed server environment,
the JMS server and the application server run in separate processes. Therefore,
the JMS server is not required to restart the application server.
To
work around this problem, restart the application server (server1).
Selecting the Java Messaging Service resources
when deploying the WAR file
When you deploy a WAR file and select
the JMS resources that you defined, you receive a warning message without
selecting the JMS resources.
Information you should know about using
server-side and client-side selectors
The default behavior for the
internal JMS broker is to use server-side selectors. The default behavior
for external brokers is to use client-side selectors. The reason for the latter
is that not all brokers support server-side filtering. Those that do, are
not all JMS compliant in their implementation process.
Stopping the queue manager while running
the embedded Java Messaging Service provider stops the IBM WebSphere Application
Server
When you run the embedded Java Message Service (JMS) provider
and the queue manager stops, IBM WebSphere Application Server is also stopped.
To
recover the queue manager and IBM WebSphere Application Server, you must start
the application server.
Limited connection caching available
for servlets
Caching of connection handles across servlet
methods is limited to JDBC and Java Message Service (JMS) resources. Other
non-relational resources, such as Customer Information Control System (CICS)
or IMS, currently cannot have their connection handles cached in a servlet.
This limitation only applies to single-threaded servlets since multithreaded
servlets do not allow caching of connection handles.
To work around
this problem, you need to get, use, and close the connection handle within
each method invocation.
Problems with Xerces versions that are not J2EE
compliant
Programs containing the Xerces parser routine that work
on IBM WebSphere Application Server, Version 4.0.x might not work on IBM WebSphere
Application Server, Version 5.
Versions of Xerces prior to 2.0.0, including
the versions shipped with IBM WebSphere Application Server, Version 4.0.x,
were not J2EE1.3 compliant. To meet J2EE1.3 certification constraints (DOM2/SAX2/JAXP1.1
(and no higher)), IBM WebSphere Application Server, Version 5 requires XML4J4.0.0
(Xerces 2.0 bug fixes).
In Xerces versions prior to 2.0.0 and Xalan
versions prior to 2.2, the DOM, SAX, and JAXP APIs were bundled inside of
the xerces.jar and xalan.jar files.
In the most recent versions, these non-Apache XML APIs have moved into a separate
JAR file in the XML common apache project. These common XML APIs are required
by the specifications and contained within the IBM WebSphere Application Server,
Version 5 j2ee.jar file.
The cause of the
problem is that the class loader behavior mixes the classes that are required
by J2EE1.3 with those of the older Xerces implementation.
To work around
this problem, use the version that ships with IBM WebSphere Application Server,
Version 5.
National Language Version issues and limitations
Locale
improperly set during the WebSphere Application Server Enterprise installation
on HP platforms where the language is set to Japanese
On HP platforms
where the language is set to Japanese, during the WebSphere Application Server
Enteprise installation, the product configures the <was>/bin/setupCmdLine.sh shell
scripts to include an incorrect locale in the LANG environment variable.
When
running these shell scripts, for example, <was>/bin/versionInfo.sh,
you can get the following warning message:
Warning! One or more of your selected locales are not available.
Please invoke the commands "locale" and "locale -a" to verify your
selections and the available locales.
Continuing processing using the "C" locale.
To avoid receiving the
warning message, perform the following steps:
- Edit the file <was>/bin/setupCmdLine.sh.
- Find the line LANG=ja_JP.sjis.
- Replace the line LANG=ja_JP.sjis with LANG=ja_JP.SJIS.
Patches needed for correct character display
of the installation panel on Asian language platforms
If the installation panel displays garbled characters
on Asian language platforms, including Korean, traditional Chinese, Japanese,
and simplified Chinese, on the HP-UX 11i platform, make sure that you have
the following patches installed on your HP-UX 11i machine:
| Name |
Brief Description |
| B6848BA |
Ximian GNOME 1.4 GTK+ Libraries for HP-UX 11.00 and
11i |
| BUNDLE11i |
Required Patch Bundle for HP-UX 11i, February 2001 or
later |
| PHSS_26974(for 11.0) or PHSS_26973 (for 11i) |
Korean TrueType fonts |
| PHSS_24937(for 11.0) or PHSS_26977 (for 11i) |
Traditional Chinese TrueType fonts |
| PHSS_26972(for 11.0) or PHSS_26971 (for 11i) |
Japanese TrueType fonts |
| PHSS_26976(for 11.0) or PHSS_24975 (for 11i) |
Simplified Chinese TrueType fonts |
| PHSS_25091(for 11.0) or PHSS_25092 (for 11i) |
Common TrueType fonts |
These patches can be found at the following URL: http://www.hp.com/products1/unix/java/infolibrary/font_info.html.
Cannot display newly created Windows domain
users during application management for the non-English locales only )
The
newly created domain users are not retrieved when you perform application
management. The newly created groups are displayed correctly and the newly
created local users are also displayed correctly. If you map users to roles
by clicking A Role > Choose Users > Find Users, only users created
on Primary Domain Controller, before adding the client machine to the
domain are displayed. If a new user is created while the client machine is
already on the domain, the getUser function does not retrieve the
new users created on Primary Domain Controller. The getUser API
works correctly for the English locales but does not work correctly for the
non-English locales.
Help search does not return hits for Latin-1
terms with diacritical markings
The help search in the administrative
console does not return search results for Latin-1 terms that contain diacritical
markings (for example, German "fur", where the "u" includes an umlaut). To
work around this problem, use the decimal representation of the character
in the search term (for example, "für").
Cannot access readme and PDF installation files
for Traditional Chinese and German languages through the LaunchPad
You
can view these files through any Web browser.
The readme file for Traditional
Chinese is located at:
<cd drive>\readme\readme_zh_tw.html
The
installation PDF file for Traditional Chinese is located at:
<cd drive>\doc\installguide_zh_tw.pdf
The
readme file for German is located at:
<cd drive>\readme\readme_de.html
The
installation PDF file for German is located at:
<cd drive>\doc\installguide_de.pdf
Avoid missing characters in license agreement
Before
installing the IBM WebSphere Application Server on a Traditional Chinese AIX
machine, type the following to avoid missing characters within the license
agreement:
cd /usr/lib/nls/loc/iconv/
mv IBM-eucTW_CNS11643.1986-1 IBM-eucTW_CNS11643.1986-1.save
mv big5_CNS11643.1986-1 big5_CNS11643.1986-1.save
Help links for Application Assembly Tool, Application
Resource Client Tool and Tivoli Performance Viewer bring up the English files
To
work around this problem, change the path to the preferred language version
to display the appropriate language (include list for languages if possible)
list separately if the paths are not the same.
Product registration displays as English when
installing in Brazilian Portuguese
When registering your product
from the installation in Brazilian Portuguese, the product registration page
displays in English.
To view the registration page in Brazilian Portuguese,
you can enter the following URL, <install_root>\prt\PRT_Welcome_ptb.html or
register the product using FirstSteps in Brazilian Portuguese.
Running servers
in different code pages within a single cell is not supported
Both
the IBM WebSphere Application Server Network Deployment node and the IBM WebSphere
Application Server nodes must be on the same code page.
The Java virtual machine can not translate coded
Character Set Identifier used by the embedded messaging queue manager
When
running the IBM WebSphere Application Server with global security enabled
the embedded messaging provider can fail to start with message MSGS0504E and
an UnsupportedEncodingException:
MSGS0504E: JMS Server Security Service Thread received Socket Exception:
java.io.UnsupportedEncodingException: Cp5050
This message
indicates that the Java virtual machine (JVM) cannot translate the Coded Character
Set Identifier (CCSI) used by the embedded messaging queue manager.
To
work around this problem, set a locale and language value that maps to a code
page supported by the JVM. Refer to the WebSphere MQ messaging platform-specific
books Web site at http://www-3.ibm.com/software/ts/mqseries/library/manualsa/manuals/platspecific.html
for
a "WebSphere MQ Platform Quick Beginnings V5.3" manual that is relevant to
your platform. Look for a table in the manual with a list of locale and language
to CCSI mappings supported by the queue manager. Then, select a locale and
language that maps to a CCSID that is supported by the JVM. Set the selected
locale and language, and restart the IBM WebSphere Application Server.
Insufficient prerequisites cause warning messages
during installation with AIX 4.3.3
When
installing the Simplified Chinese version of the IBM WebSphere Application
Server on AIX 4.3.3, warning messages display because of insufficient prerequisites.
The error message indicates that the file levels X11.fnt.ucs.ttf, X11.fnt.ucs.ttf_TW, and X11.fnt.ucs.ttf_KR do
not match the level of file X11.fnt.ucs.ttf_CN.
The latter file has a level of 4.3.3.25, while the others have the level 4.3.3.
To
work around this problem, force the installation by modifying the prereqChecker.xml file
to the required file level.
Japanese not recommended on Red Hat Advanced Server
Version 2.1
The Red Hat Advanced
Server Version 2.1 GUI language selection menu displays two selections for
Japanese: Japanese (eucJP) and Japanese (SJIS).
Click Japanese
(eucJP) to install and run the IBM WebSphere Application Server in a Japanese
environment. Using Japanese (SJIS) is not recommended.
For reference
see the Red Hat Japanese Web site at http://www.jp.redhat.com/support/7.2/sla/rh72faq.html
.
Evaluating the product on National Language Version
operating systems
The following steps are work arounds to evaluate IBM WebSphere
Application Server and IBM WebSphere Application Server Network Deployment,
Version 5 on National Language Version operating systems.
- Windows NT platform:
- Open Regional Settings from the Windows NT Control Panel.
- Change the setting to English (United States) on Regional Settings,
and then select set as system default locale check box.
- Add English (United States) on Input Locales, and set the
default input locale to English.
- Click OK on the Regional Settings Properties window.
- Restart the machine with the English locale settings.
- Install the IBM WebSphere Application Server, Version 5.
Note: Do not change locale settings to original non-English settings
until you finish the evaluation.
- Windows 2000 platform:
- Open Regional Options from the Windows 2000 Control Panel.
- Change the setting Your locale (location): to English (United
States) on General, click Default Settings, and then change
the system locale to English (United States).
- Add English (United States) on Input Locales, and set the
default input locale to English.
- Click OK on the Regional Options window.
- Restart the machine with the English locale settings.
- Install the IBM WebSphere Application Server, Version 5.
Note: Do not change locale settings to original non-English settings
until you finish the evaluation.
- AIX 4.3.3 or AIX 5.1:
Open Terminal and run the following command
before you install the IBM WebSphere Application Server, Version 5:
# export LANG=en_US
Note: Every time that
you open a new terminal, you need to invoke the above command.
- Solaris Operating Environment 8:
Open Terminal and run the following
command before you install the IBM WebSphere Application Server, Version 5:
# LANG=en_US
# export LANG
Note: Every time you open a new terminal, you need
to invoke the above command.
Process Choreography
Process templates are saved
in the process choreographer database even though the installation of the
enterprise application is cancelled
When you install an enterprise
application containing business processes modules, for example, FAR files,
the process templates are written to the process choreographer database.
If you cancel the installation by not saving your configuration changes, the
enterprise application is not installed but the templates remain in the database.
This occurs if you:
- Click Cancel on the Save to Master Configuration panel when
you have used the administrative console to install the application. Or
- Reset wsadmin configuration changes by typing $AdminConfig reset if
you have used wsadmin $AdminApp to install the application.
When you try to install the same enterprise application again, the
following error message is displayed : :
The following exception was logged com.ibm.bpe.plugins.DeploymentDuplicateProcessModel
Exception:
BPED0000E: The process model with name 'ProcessModelName' and valid from date 'Tue 2002-01-01 12:00:00.000' already exists.
To work around this problem, do not cancel the installation by not
saving your configuration changes. If you decide that you do not want to install
the application, save your changes and uninstall the application.
If
you have already cancelled the installation, remove the leftover templates
from the table PROCESS_TEMPLATE_T in the process choreographer database
by performing the following steps:
- Connect to your process choreographer database. The default name is BPEDB.
- Determine the application name that you have used before to install the
enterprise application:
Select distinct APPLICATION_NAME from
the table PROCESS_TEMPLATE_T where NAME='<ProcessModelName>' and VALID_FROM='<validFrom>'.
The
format of the <validFrom> column depends on your locale. The
best way to find out the value is by doing another query:
Select VALID_FROM from
the table PROCESS_TEMPLATE_T where NAME='<ProcessModelName>'.
- Use the resulting application name from the query in step 2 to delete
all templates from the database that are associated with this application
name:
Delete from the table PROCESS_TEMPLATE_T where APPLICATION_NAME='<application_name>'.
The SQL statements described above are valid for DB2 and Cloudscape.
Statements might be different for other database systems. You must prefix
the table name with a schema_name, for some database systems, for example:
USER_A.PROCESS_TEMPLATE_T.
Setting the database back-end
before installing the business process container
When you configure
the business process container using the administration console Install option
or the Installation Wizard (found at Application Servers > serverN
> Business Process Container), set the database back-end type prior to
installation if you:
- set Use Metadata from binaries to Yes in at least one of
your business process container enterprise applications; or
- set Use Metadata from binaries to No (default) in your
business container enterprise, and select DB2 for z/OS or Oracle V8 or Oracle
V9 as the database system.
Note: If you select DB2 for z/OS as the database system, the wrong database
back-end type is set. If you select Oracle V8 or Oracle V9 as the database
system, the wrong version of the compensation enterprise beans are used.
To
set the database back-end type and to make sure the appropriate version of
the compensation enterprise beans are used, complete the following steps:
- Make a backup copy of the business process container EAR file (bpecontainer.ear).
This file is found under the $WAS_HOME/installableApps directory.
- Change the directory to $WAS_HOME/ProcessChoreography.
- On your UNIX Shell or Windows command prompt, type the following command
syntax to run the patchDatabaseBackendId.jacl script.
wsadmin -conntype NONE -f patchDatabaseBackendId.jacl <database> <version> <driver>
where <database> <version> <driver> is one
of the following:
- Cloudscape
- DB2
- zOS-DB2 6
- zOS-DB2 7
- Sybase 12.0
- Sybase 12.5
- Oracle 8
- Oracle 9 OCI8
- Oracle 9 thin
- iSeries-DB2
This script creates a new EAR file with the patched back-end ID
attribute in the $WAS_HOME/installableApps directory.
The name of the generated EAR file depends on the database and version that
you use. For example, wsadmin.sh -f patchDatabaseBackendId.jacl
Sybase 12.5 creates the <WAS_HOME>/installableApps/bpecontainer_SybaseV12.5.ear file.
- Copy the output of previous steps to the $WAS_HOME/installableApps/bpecontainer.ear file.
For
example, copy the $WAS_HOME/installableApps/bpecontainer_SybaseV12.5.ear
$WAS_HOME/installableApps/bpecontainer.ear file.
Once this procedure is complete, continue with your installation.
During installation, the
administrative console does not enable you to choose the workflow module in
the EAR file
During installation, the administrative console does
not enable you to choose the workflow module in the EAR file. A process application
or EAR file consists of both File and Archive (FAR) files and at least one
enterprise bean JAR or WAR file. The FAR files (or process modules) do not
appear on any of the application installation panels and, in particular, they
do not appear on the module-to-server-mapping panel. The FAR files are installed
on each standalone application server or cluster where the WAR files or enterprise
bean JAR files of the application are installed.
Note: You can specify
where to install the enterprise JAR files and WAR files. However, FAR files
are automatically installed on all the servers and clusters where the enterprise
bean JAR files and WAR files are installed.
To avoid multiple deployment
of FAR modules, ensure all of the modules in the EAR file of a business process
application are installed on the same application servers or clusters. To
split the modules across servers or clusters, package the Web modules in a
separate EAR file that does not contain business process modules.
Processes that are terminated
using the Web client or APIs are not compensated
Top-level processes
terminated using the Web client or the API are not compensated. The process
termination capabilities provided with IBM WebSphere Application Server Version
5 implement a "force Terminate" behavior. The process is immediately terminated
without waiting for the outstanding activities to complete.
Use the
process termination capabilities as a last resort. For example, you can use
these capabilities to remove failed process instances that are still in a
"running" state. This example might result from an invoked application that
failed and that did not return to a dormant state. Authorization to terminate
processes is limited to the process administrator.
WebSphere Application Server
might crash or hang when you run interruptible processes with DB2 USB 8.1
and no fix pack installed
WebSphere Application Server might crash
or hang when you run interruptible processes with DB2 USB 8.1 and no fix pack
installed.
To work around this problem, either use DB2 UDB 8.1 with
FP1 (or higher) or use DB2 UDB 7.2.
The workflow application
does not start after a transaction timeout
Compensation fails with
an exception when both of the following situations occur:
- Compensation is pending during the start of the IBM WebSphere Application
Server.
- The IBM WebSphere Application Server starts the BPEContainer enterprise
application before starting the client enterprise application that it will
compensate.
To work around this problem, you must manually update the compensation
database tables and have the IBM WebSphere Application Server reattempt the
compensation activity.
Note: Take extreme caution completing the following
workaround process to avoid encountering additional difficulties.
- Stop the Business Process Container so that it is not restarted in step
5 of these directions. To stop the Business Process Container, use the administrative
console, select Enterprise Applications, select the check box next
to BPE_Container_<nodename>_<servername>, and click Stop.
- Stop the IBM WebSphere Application Server.
- Manually update the STANDARDEXECUTOR table in the BPEDB database. Change
any rows in the database whose EXECUTORSTATEFLD column is set to 4 to
a value of 3. The following is an example of an SQL command used to
update the STANDARDEXECUTOR table:
UPDATE
SCHEMA.STANDARDEXECUTOR
SET EXECUTORSTATEFLD = 3
WHERE
EXECUTORSTATEFLD = 4
- Manually update the CONTEXTUALPROCLET table in the BPEDB database. Change
any rows whose PROCLETSTATE column is set to 4 to a value of 2.
The following is an example of an SQL command used to update the CONTEXTUALPROCLET
table:
UPDATE
SCHEMA.CONTEXTUAL
SET PROCLETSTATE = 2
WHERE
PROCLETSTATE = 4
- Start the IBM WebSphere Application Server.
- Start all of the applications that use the Business Process Container.
- Start the Business Process Container. This reattempts compensation for
the processes modified in step 3. To start the Business Process Container,
use the administrative console, select Enterprise Applications, click
the check box next to BPE_Container_<nodename>_<servername>,
and click Start.
Performance problems when running
compensation in the service choreography.
You might experience performance
problems on AIX 5.2 with DB2 V8.1-FP1 database configured and installed on
the same machine. This problem happens when running compensated workflow application
that loops one single step in the flow for many times.
To work around
this problem, install and configure the business process container database
(default name is BPEDB) in a separate machine.
The MQ
server fails when a message that is larger than the maximum TCP segment size
is sent to the MQ server
The MQ server fails when a message that
is larger than the maximum TCP segment size is sent to the MQ server (for
example, by the BPE container), and the WebSphere Application Server throws
an exception similar to the following:
3/5/03 18:46:50:242 EST] 5f952ac4 WASLogger E CLASSNAME METHODNAME rollback failed [3/5/03 18:46:50:376 EST] 5f952ac4 JMSExceptionL E WMSG0018E: Error on JMSConnection for MDB ProcessContainer MDB , JMSDestination jms/BPEIntQueue : javax.jms.JMSException: MQJMS1025: failed to browse message.
To solve this problem, you can download the fix at the following Web site:
https://www6.software.ibm.com/dl/wsmqcsd/wsmqcsd-p
Note: You need to register before downloading the fix.
You can receive a no
unique ID for: <user ID> exception in the log file if you delete
the user ID of the process starter in your user registry while the process
instance exists
You cannot delete the user ID of the process starter
from your user registry while the process instance exists. If you do so, the
navigation of this process cannot continue and you can receive the following
exception in the system log file:
no unique ID for: <user ID>
To
allow the process to continue the navigation, recreate the user ID of the
process starter in your user registry and replay the navigation message from
the hold queue.
Samples
All platforms
Correct instructions for
reinstalling the client Samples before renaming the original Samples directory
The
correction instructions for reinstalling the client Samples is as follows:
The
instruction asks you to rename the original Samples directory to samples_50 and
rename the samples50_fp1 directory to Samples. When you do this,
the CORBA C++ and PlantsByWebSphereXJBClient Samples are not in the Samples
directory any more because they were not changed in the Fix Pack 1 and are
not in the samples50_fp1 directory. The following instructions need
to be added before the renaming.
These directories from the original
Samples directory need to be copied to the new samples50_fp1 directory
before renaming the directory as is described in the Samples Readme file:
- Copy the WebSphere\AppClient\samples\docs\CppsdkClient directory
to the WebSphere\AppClient\samples50_fp1\docs\CppsdkClient directory.
- Copy the WebSphere\AppClient\samples\src\cppsdk directory to
the WebSphere\AppClient\samples50_fp1\src\cppsdk directory.
- Copy the WebSphere\AppClient\samples\bin\PlantsByWebSphereXJBClient directory
to the WebSphere\AppClient\samples50_fp1\bin\PlantsByWebSphereXJBClient directory.
- Copy the WebSphere\AppClient\samples\docs\PlantsByWebSphereXJBClient directory
to the WebSphere\AppClient\samples50_fp1\docs\PlantsByWebSphereXJBClient directory.
WebSphere Application Server Enterprise,
Version 5.0.1 Dynamic Query Sample update
To run the Dynamic Query
Sample with WebSphere Application Server Enterprise, Version 5.0.1, you must
upgrade to the Version 5.0.1 Sample. Note that the Version 5 Dynamic Query
Sample does not run on WebSphere Application Server Enterprise, Version 5.0.1.
Instructions for uninstalling the Version 5 Dynamic Query Sample and
reinstalling the Version 5.0.1 Sample are located in the samples50_fp1 directory.
This directory is located off of the root directory of where WebSphere Application
Server Enterprise is installed. The file name is EEreadme.pdf.
These
directories from the original Samples directory need to be copied to the new samples50_fp1 directory
before renaming the directory as is described in the Samples Readme file:
- Copy the WebSphere\AppClient\samples\docs\CppsdkClient directory
to WebSphere\AppClient\samples50_fp1\docs\CppsdkClient directory.
- Copy the WebSphere\AppClient\samples\src\cppsdk directory to
the WebSphere\AppClient\samples50_fp1\src\cppsdk directory.
- Copy the WebSphere\AppClient\samples\bin\PlantsByWebSphereXJBClient directory
to WebSphere\AppClient\samples50_fp1\bin\PlantsByWebSphereXJBClient dicrectory.
- Copy the WebSphere\AppClient\samples\docs\PlantsByWebSphereXJBClient directory
to WebSphere\AppClient\samples50_fp1\docs\PlantsByWebSphereXJBClient directory.
WebSphere Application Server Enterprise,
Version 5.0.1 AccountReport Scheduler Sample update
A Version 5.0.1
AccountReport Scheduler Sample is available with WebSphere Application Server
Enterprise, Version 5.0.1 that contains minor updates. Either the Version
5 or Version 5.0.1 of this Sample runs on WebSphere Application Server Enterprise,
Version 5.0.1. Therefore, upgrading the Sample to its Version 5.0.1 is optional.
Instructions
for uninstalling the Version 5 AccountReport Scheduler Sample and reinstalling
the Version 5.0.1 Sample are located in the samples50_fp1directory.
This directory is located off of the root directory of where WebSphere Application
Server Enterprise is installed. The file name is EEreadme.pdf.
The WebSphere Trader Applet
client fails with a Java applet plug-in
The WebSphere Trader Applet
client is supported in both Netscape and Microsoft Internet Explorer browsers
when you use the native Java virtual machine only. Alternative Java Runtime
Environment plug-ins are not supported.
The WebSphere Trader Sample
TickerStreamer Autostart fails
The documentation for the asynchronous
bean Sample, WebSphere Trader, in the Samples Gallery describes how to start
the Price Generation and Ticker Streamer servers automatically when the application
starts.
When the Ticker Streamer server is enabled to automatically
start, the following error is written in the system output logs and the WebSphere
Trader sample fails to start:
WebSphereTrader: TickerStreamBootstrapBean.start(): Exception starting app:
To avoid this error, do not follow steps 4 through 6 in the
"Configuring the Sample servers to start automatically" section of the "Configure
and Run" page of the documentation. If you come to steps 4 through 6, the
Sample does not start, and the previous error message is written to the system
output logs, follow these steps:
- Open the install_root/installedApps/cell_name/WebSphereTrader.ear/TickerStreamer.prop file
in a text editor, where <cell_name> is the name of the cell where your
application is installed.
- Change the line tickstream.autostart=false to tickstream.autostart=true
- Save the file.
- Start or restart the IBM WebSphere Application Server.
The CORBA Samples do not work
with the node name chosen
The COBRA Samples do not work if the node
name chosen is different from the default host name.
To work around
this problem, modify the appropriate properties file for your C++ client from
the following list:
| Sample name |
Properties file |
| Enterprise bean sample |
WSEJBClient.props |
| Valuetypes sample |
VTClient.props |
Complete the following steps:
- Change the com.ibm.CORBA.bootstrapHostName node
name to com.ibm.CORBA.bootstrapHomeName=<new_nodename>
- Add a line to the TCP/IP host file using the following format that includes
the node name you included in the previous step:
<ip_address_of_the_machine> <new_nodename>
When you run the Sample, the new node name resolves back to the
actual host name and then finds the enterprise bean in the naming structure.
Starting a CORBA C++ client
application from a WebSphere Application Server client machine without DB2
installed fails
Starting a CORBA C++ client application, for example,
ValuetypeSample, from a WebSphere Application Server client machine without
DB2 installed fails since the CORBA C++ client application cannot find the
DB2 library.
To work around this problem, perform the following steps:
- On Windows platforms:
- Change to the install_root\bin directory.
- Copy wasorism.dll to wasorirm.dll.
- On Solaris Operating Environment:
- Change to the install_root/lib directory.
- Copy libwasoris.so to libwasorir.so.
- On HP-UX platforms:
- Change to the install_root/lib directory.
- Copy libwasoris.sl to libwasorir.sl.
- On Linux platforms:
- Change to the install_root/lib directory.
- Copy libwasoris.so to libwasorir.so.
- On AIX platforms:
- Change to the install_root/lib directory.
- Copy libwasoris.a to libwasorir.a.
The AccountReport Scheduler
Sample throws exceptions in the SystemOut.log file
If
you uninstall the Scheduler Sample EAR file without removing the thread daemon,
the thread daemon cannot find the configured database because it has been
destroyed. As a result, the AccountReport Scheduler Sample throws exceptions
that are recorded in the SystemOut.log file.
To
work around this problem, complete the following procedures to permanently
remove the AccountReport Scheduler Sample from the IBM WebSphere Application
Server. Start the application server and open the application server administrative
console before starting these procedures.
Deleting the AccountReport
scheduler
- Using the navigation tree on the left side of the administrate console,
expand Resources, click Scheduler configuration > Node scope > Apply.
- Delete the AccountReportScheduler Scheduler configuration by selecting AccountReportScheduler
> Delete.
- Save the configuration.
Deleting the Scheduler_AccountReport data source
- Using the navigation tree on the left side of the administrative console,
expand Resources, click JDBC Providers > Server scope > Apply.
- Click Cloudscape JDBC Provider on the JDBC Providers page.
- Click Data Sources on the Cloudscape JDBC Driver page.
- Delete the Scheduler_AccountReport data source by selecting the check
box next to Scheduler_AccountReport and clicking Delete.
- Save the configuration.
Uninstalling the AccountReport application
- Using the navigation tree on the left side of the administrative console,
expand Applications and click Enterprise Applications.
- Stop the AccountReport application by selecting the check box next to AccountReport and
clicking Stop.
- Uninstall the AccountReport application by selecting the check box next
to AccountReport and clicking Uninstall.
- Save the configuration.
The Scheduler Sample is now removed.
Note: To reinstall the
Sample, use the WebSphere Application Server Enterprise installation program.
Manual instructions for installing the Sample are not provided.
Samples Gallery font in languages other than English
can appear small
The Samples Gallery font in languages other than
English can appear small, depending on the browser you use. To work around
this problem, increase the browser font settings.
The WebSphere Trader Applet
client produces errors on the Linux SuSE Version 7.3 platform
The WebSphere Trader Applet client is unsupported
on the SuSE Linux Version 7.3 platform. When you run the IBM WebSphere Application
Server on the SuSE Linux platform, use a browser from a different supported
platform (such as Microsoft Windows 2000) to run the Sample.
The correct translation documentation
for setting up the current directory for the Linux and HP-UX platforms for
the CORBA SDK EJB Client and Valuetype samples
This section provides the correct translation documentation for
the two CORBA samples in the Samples Gallery.
If you have WebSphere
Application Server Enterprise installed with CORBA samples, you can access
the documentation in a browser at http://<hostname>/:9080/WSamples.
From Enterprise Extensions in the Sample Gallery, click CORBA C++
SDK and then click Build It Yourself under C++ Client with an
Enterprise Bean or C++ Client using valuetypes.
The following
is the current text:
4. Update your library environment variable to
include the full path to your current directory (LIBPATH for AIX, LD_LIBRARY_PATH for
Solaris, or PATH for Windows).
The following is the correct
text:
4. Update your library environment variable to include the full
path to your current directory (LIBPATH for AIX, LD_LIBRARY_PATH for
Linux, SHLIB_PATH for HPUX, LD_LIBRARY_PATH for Solaris, or PATH for
Windows).
$AdminApp installation documentation describes
the -deployejb.dbtype option incorrectly
The documentation for $AdminApp
installation describes the -deployejb.dbtype option as CLOUDSCAPE_V50. The
correct option is CLOUDSCAPE_V5.
The following command is an example
of its usage. The command deploys an application using IBM Cloudscape with
the correct database type:
wsadmin -conntype none -c "$AdminApp install TechnologySamples.ear
{-appname TechnologySamples -usedefaultbindings -node <node> -deployejb
-deployejb.dbtype CLOUDSCAPE_V5}"Uninstallation of the ValuetypeSample
application fails because the application name does not match the documentation
The
uninstallation of the ValuetypeSample application fails because the application
name does not match the documentation. The sample is installed using the
application name of ValueTypeSample but the documentation has the correct
application name of ValuetypeSample.
To work around this uninstallation
failure, remove the sample EAR file and then reinstall the sample application.
- Perform the following steps to remove the sample EAR file:
- Change to the install_root/bin directory.
- Type the following commands to uninstall the application:
On Windows
platforms:
wsadmin -conntype none -c "$AdminApp uninstall ValueTypeSample"
On
UNIX platforms:
wsadmin.sh -conntype none -c "$\AdminApp uninstall
ValueTypeSample"
- Complete the following steps to reinstall the sample application:
- Change to the install_root/samples/src/cppsdk/valuetypesamp directory.
- Locate the ValuetypeSample.ear file.
- Type the following commands:
- On Windows platforms:
wsadmin -conntype none -c "$AdminApp install
ValuetypeSample.ear {-usedefaultbindings -deployejb -node <node> -appname
ValuetypeSample}"
where <node> is the name of node
on which to install the sample.
- On UNIX platforms:
wsadmin.sh -conntype none -c "$\AdminApp install
ValueTypeSample.ear {-usedefaultbindings -deployejb -node <node> -appname
ValuetypeSample}"
where <node> is the name of node
on which to install the sample.
- Change to the install_root/bin directory.
- Stop the application server by issuing the following commands:
- On Windows platforms: stopServer.bat server1
- On UNIX platforms: ./stopServer.sh server1
- Start the application server by issuing the following commands:
- On Windows platforms: startServer.bat server1
- On UNIX platforms: ./startServer.sh server1
Back to Samples
Back to Known problems and workarounds
Security
All platforms
An error message occurs in the native_stdout.log
file when enabling security on HP- UX 11i platforms
After you enable security on HP-UX 11i platforms, the
following error in the native_stdout.log file occurs, along with
a core dump and WebSphere Application Server does not start:
Java HotSpot(TM) Server VM warning: Unexpected Signal 11 occurred under user-defined signal handler 0x7895710a
To work around this error, apply fixes recommended by HP for Java
at the URL: http://www.hp.com/products1/unix/java/infolibrary/patches.html.
getCallerPrincipal() returns a realm/realm/user format
when you specify a Domain Qualified User Name
When you specify Domain
Qualified User Name from the Security > Global Security configuration
panel, the runtime call to getCallerPrincipal() from an enterprise
bean returns the qualified name with the realm prepended twice. For example,
the format return is realm/realm/user. You can strip the first realm
from the returned value when making API calls. The servlet API getUserPrincipal() works
correctly.
Test connection fails for data sources with
newly added J2C authentication data alias
If you create or update
a data source that points to a newly created J2C authentication data alias, Test
Connection fails to connect until you have restarted the deployment manager
so that the J2C authentication data is reflected in the run-time configuration.
Any changes to the J2C authentication data fields require a deployment manager
restart for the changes to take effect.
WebSphere Application Server security help
files incorrectly mapped
Some of the links from the following WebSphere
Application Server security windows to their corresponding help files are
incorrectly mapped:
Environment > Naming > CORBA Naming Service
Users
Environment > Naming > CORBA Naming Service Users > Add
Environment
> Naming > CORBA Naming Service Groups
Environment > Naming >
CORBA Naming Service Groups > Add
System Administration > Console
Groups > Add
Note: In the System Administration > Console
Groups > Add window, the links to the help located next to Group Description and Role
Description are correct. However, the link to the help text at the top
of the help window is incorrect.
If you access a help file that does
not correspond to the appropriate WebSphere Application Server window, use
the following table to locate the correct help information. When you access
the incorrect help file, find the listing of help files located under Core
Console on the left side of your current help file window and click the
appropriate link.
| Window path |
Correct Help file |
| Environment > Naming > CORBA Naming Service Users |
CORBA Naming Service users settings |
| Environment > Naming > CORBA Naming Service Users
> Add |
CORBA Naming Service users settings |
| Environment > Naming > CORBA Naming Service Groups |
CORBA Naming Service groups |
| Environment > Naming > CORBA Naming Service Groups
> Add |
CORBA Naming Service groups |
| System Administration > Console Groups > Add |
Console groups settings |
Java Authentication and Authorization
Service configuration setting for Java client program
You must invoke
Java client programs that use Java Authentication and Authorization Service
(JAAS) for authentication with a JAAS configuration file specified. The WebSphere
product supplies the default JAAS configuration file, wsjaas_client.conf under
the <install_root>/properties directory.
This configuration file is set in /<install_root>/bin/launchClient.bat file
as:
set JAAS_LOGIN_CONFIG=-Djava.security.auth.login.config=%WAS_HOME%\properties\wsjaas_client.conf
If launchClient.bat file is not used to invoke Java client
programs, make sure the appropriate JAAS configuration file is passed to the
Java virtual machine with the
-Djava.security.auth.login.config flag.
Default Secure Sockets
Layer alias of the cell is used to create HTTPS transport
On the
IBM WebSphere Application Server Network Deployment installation, the Secure
Sockets Layer alias of the default cell is used for the HTTPS transport when
creating a new server.
The javax.security.auth.Subject.getSubject(java.security.AccessControlContext)
method does not work within the AccessController.doPrivileged() method
You
can retrieve the subjects in a Subject.doAs() block with the Subject.getSubject()
call. However, this procedure does not work if there is an AccessController.doPrivileged()
call within the Subject.doAs() block. In the following example, s1 is
equal to s, but s2 is
null:
AccessController.doPrivileged() not only truncate the Subject propagation, also reduce the
permissions, it does not includes the JAAS security policy defined for the principals in the Subject.
Subject.doAs(s, new PrivilegedAction() {
public Object run() {
System.out.println("Within Subject.doAsPrivileged()");
Subject s1 = Subject.getSubject(AccessController.getContext());
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
Subject s2 = Subject.getSubject(AccessController.getContext());
return null;
}
});
return null;
}
});See the documentation for information on how to use the
WSSubject class instead of the Subject object to associate IBM WebSphere Application
Server credentials to the thread of context.
The IBM Java Secure Socket Extension is not
supported within applets
The IBM Java Secure Socket Extension (JSSE)
is currently not supported within applets.
The shadow password file must exist for the local
operating system security to work
For the IBM WebSphere Application Server local operating system
security registry to work on Linux systems and a Solaris Operating Environment,
a shadow password file must exist. The shadow password file is named shadow
and is in the /etc directory. If the shadow password
file does not exist, an error occurs after enabling global security and configuring
the user registry as local operating system.
To create the shadow file,
run the pwconv" command (with no parameters). This command creates
an /etc/shadow file from the /etc/passwd file.
After creating the shadow file, you can configure local operating system security.
The grant entries in the app.policy and was.policy files must have a code base
Grant
entry specified in the app.policy and was.policy files
must have a code base defined. If there are grant entries specified without
a code base, the policy files are not loaded properly and the application
can fail.
If the intent is to grant the permissions to all applications,
then use file:${application} as a code base in
the grant entry.
SecurityManager does not check modifyThread
and modifyThreadGroup permission for non-system threads
When Java
2 Security is enabled in the Global Security settings, the installed SecurityManager
does not currently check modifyThread and modifyThreadGroup permissions for
non-system threads.
You can use Web applications and EJB application
code to create threads and access to the following thread class methods: stop,
suspend, resume, setPriority, setName, and setDaemon.
Allowing Web and
EJB application code to create or modify a thread can have a negative impact
on other components of the container and can affect the capability of the
container to manage enterprise bean life cycles and transactions.
Information you should know about the Java Authentication
and Authorization Service login configuration updates in the Security Center
The
Java Authentication and Authorization Service (JAAS) login configuration entries
in the Security Center are propagated to the server run time when they are
created, not when the configuration is saved.
However, the deleted JAAS
login configuration entries are not removed from the server run time. To remove
the entries, save the new configuration, then stop and restart the server.
Web client certificate authentication is not currently
supported with the local operating system authentication mechanism
Web
client certificate authentication is not currently supported when using the
local operating system (LocalOS) user registry. However, Java client certificate
authentication does work with LocalOS. Java client certificate authentication
maps the first attribute of the certificate domain name to the user ID in
the LocalOS user registry.
Even though Java client certificates work
properly, the following error displays in the SystemOut.log file:
SECJ0337E: The mapCertificate method is not supported
The error is intended for Web client certificates, but also displays
for Java client certificates. You can ignore this error for Java client certificates.
Identity assertion fails when basic authentication
is not selected
When specifying identity assertion on the CSIv2
Authentication Outbound panel, you must also select basic authentication as
supported or required on the CSIv2 Authentication Outbound panel. This action
allows the server identity to be submitted, along with the identity token,
so that the receiving server can trust the sending server. Without
specifying basic authentication as supported or required, trust is not established
and the identity assertion fails.
Access denied
in mixed security configuration
If your security configurations
are not consistent across all servers, you get access denied errors.
When
enabling or disabling global security in a Network Deployment environment,
it is important that your new security setting is propagated to all the nodes
before restarting the deployment manager and node agents to change the new
security policy.
Configuration changes such as this are generally propagated
using configuration synchronization. If auto-synchronization is enabled, you
can wait for the automatic synchronization interval to pass or you can force
synchronization before the synchronization interval expires. If you use manual
synchronization, you must synchronize all nodes.
If the cell is in a
configuration state, where the security policy is mixed with nodes that have
security enabled and nodes that have security disabled, you can use the syncNode
utility to synchronize the nodes where the new settings were not propagated.
Refer
to the article entitled, "Enabling and removing global security" in the Network
Deployment version for more detailed information about enabling security in
a distributed environment.
Do not use forward slash character in the JAAS
login configuration alias name
Do not use the forward slash character
(/) in the alias name when defining JAAS login configuration entries. The
JAAS login configuration parser cannot handle the forward slash character.
Exposing the JAAS Subject object and WSPrincipal
interface
Several release notes follow that relate to how IBM WebSphere
Application Server, Version 5 exposes the JAAS Subject object and WSPrincipal
interface.
- The Subject object that is generated by the WSLoginModuleImpl instance
and WSClientLoginModuleImpl instance contains a principal that implements
the WSPrincipal interface. The getCredential() method of a WSPrincipal object
returns an object that implements the WSCredential interface. You can also
find the WSCredential object instance in the PublicCredentials list of the
subject instance. It is recommended that you retrieve the WSCredential object
from the PublicCredentials list instead of using the getCredential() method.
- The getCallerPrincipal() method of the WSSubject class returns a String
representing the caller security identity. Note that the return type is different
from that of the getCallerPrincipal method of the EJBContext interface, which
is java.security.Principal. The article entitled, "Java 2 Connector security",
under the heading "J2C mapping module programming reference", incorrectly
states that the WSSubject getCallerPrincipal() method returns a com.ibm.websphere.security.auth.WSPrincipal
object. Incorrect information is also in the related article entitled, "Developing your
own J2C principal mapping module."
- The Subject object generated by the J2C DefaultPrincipalMapping module
contains a resource principal and a PasswordCredentials list. In the present
implementation the resource principal represents the caller. See the article
entitled, "Java 2 Connector security."
NO_PERMISSION returned during lookup request
If
a NO_PERMISSION error is returned to the IBM WebSphere
Application Server, Version 5 client during a lookup request, apply PQ67441
for IBM WebSphere Application Server for z/OS, Version 4.0 to securely interoperate
with an IBM WebSphere Application Server, Version 5 client.
Authentication fails for
asynchronous beans when the subject is deserialized
When using asynchronous
beans, the following exception might occur after the subject is attempted
to be deserialized for use again:
[3/28/03 0:27:12:493 CST] 554758f7 LdapRegistryI E SECJ0336E: Authentication failed
for user user1 because of the following exception
com.ibm.websphere.security.PasswordCheckFailedException: The userId and/or password is empty
at com.ibm.ws.security.registry.ldap.LdapRegistryImpl.checkPassword
This is fixed in the latest cumulative security fix for WebSphere
Application Server, Version 5.0.1. You can download the fix at the following
Web site:
http://www-3.ibm.com/software/webservers/appserv/was/support/.
From the main page, click All code fixes and support tools in
the Software downloads section. This takes you to the page to search
for a specific fix.
NullPointerException might
occur during authorization of a scheduler enterprise bean
When using
scheduler with security enabled, you might receive the following NullPointerException:
java.lang.NullPointerException
at com.ibm.ejs.models.base.bindings.applicationbnd.impl.SubjectImpl.hashCode(SubjectImpl.java:88)
at java.util.HashMap.get(HashMap.java(Compiled Code))
at com.ibm.ejs.models.base.bindings.applicationbnd.impl.AuthorizationTableImpl.initializeTheTables(AuthorizationTableImpl.java:119)
at com.ibm.ejs.models.base.bindings.applicationbnd.impl.AuthorizationTableImpl.getRolesForSubject(AuthorizationTableImpl.java:51)
at com.ibm.ws.security.core.WSAccessManager.isEveryoneGranted(WSAccessManager.java:635)
at com.ibm.ws.security.core.WSAccessManager.checkAccess(WSAccessManager.java:390)
at com.ibm.ws.security.core.SecurityCollaborator.ejbCheckAuthorization(SecurityCollaborator.java:696)
at com.ibm.ws.security.core.SecurityCollaborator.performAuthorization(SecurityCollaborator.java:397)
at com.ibm.ws.security.core.EJSSecurityCollaborator.preInvoke(EJSSecurityCollaborator.java:167)
at com.ibm.ejs.container.EJSContainer.preInvokeForStatelessSessionCreate(EJSContainer.java:2649)
at com.ibm.ejs.container.EJSContainer.preInvoke_internal(EJSContainer.java:2358)
at com.ibm.ejs.container.EJSContainer.preInvoke(EJSContainer.java:2277)
at com.ibm.ejs.container.EJSContainer.preInvoke(EJSContainer.java:2262)
at com.ibm.websphere.scheduler.testfw.EJSRemoteStatelessInvokerTxRequiresNewHome_ea23b5d8.create(Unknown Source)
at com.ibm.websphere.scheduler.testfw._EJSRemoteStatelessInvokerTxRequiresNewHome_ea23b5d8_Tie.create(_EJSRemoteStatelessInvokerTxRequiresNewHome_ea23b5d8_Tie.java:153)
at com.ibm.websphere.scheduler.testfw._EJSRemoteStatelessInvokerTxRequiresNewHome_ea23b5d8_Tie._invoke(_EJSRemoteStatelessInvokerTxRequiresNewHome_ea23b5d8_Tie.java:78)
This is fixed in the latest cumulative security fix for WebSphere
Application Server, Version 5.0.1. You can download the fix at the following
Web site:
http://www-3.ibm.com/software/webservers/appserv/was/support/.
From the main page, click All code fixes and support tools in
the Software downloads section. This takes you to the page to search
for a specific fix.
The location of the SOAP security properties file
is incorrect in the setupClient.bat and setupClient.sh files
Note: This section applies to the application clients installation
of WebSphere Application Server, Version 5 Fix Pack 1.
The setupClient.bat file
on Windows platforms and the setupClient.sh file on UNIX platforms
incorrectly specify the location of the SOAP security properties file.
In
the setupClient.bat file, the correct location should be:
set CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:%WAS_HOME%/properties/soap.client.props
In the setupClient.sh file, the CLIENTSOAP variable
should be:
CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:$WAS_HOME/properties/soap.client.props
In
the setupClient.bat and setupClient.sh files, complete the
following steps:
- Remove the leading / after file:.
- Change sas to soap.
Web services
Preserving an existing
Web Services Gateway configuration when installing the fix pack
The
update installer installs the enterprise applications for the Web Services
Gateway in the /installableApps directory of WebSphere Application
Server Network Deployment. To deploy the enterprise applications across the
cell, complete the following steps:
- Back up the following gateway configuration files to a secure location,
for later restoration. You can find these files on each application server
on which the gateway has been installed.
- WAS_HOME /installedApps/node_name/wsgwsoap1.ear/wsgwsoap.war/DeployedServices.ds
- WAS_HOME/installedApps/node_name/wsgwsoap1.ear/wsgwsoap.war/wsgwsoap.channelname.cfg
- WAS_HOME/installedApps/node_name/wsgwsoap2.ear/wsgwsoap.war/DeployedServices.ds (if
installed)
- WAS_HOME/installedApps/node_name/wsgwsoap2.ear/wsgwsoap.war/wsgwsoap.channelname.cfg (if
installed)
- WAS_HOME/installedApps/node_name/wsgw.ear/wsgw.war/wsgw.cfg
where WAS_HOME is the root directory for each installation
of the application server (by default WebSphere/AppServer).
- Install all fix packs for all WebSphere Application Server products by
following the instructions in the product documentation article: "Installing
fixes and fix packs."
- Use the WebSphere Application Server administrative console to stop and
remove the following enterprise applications:
- wsgw
- wsgwsoap1
- wsgwsoap2 (if installed)
- Complete the installation of the gateway by following the instructions
in the product documentation article: "Web Services Gateway - Completing the
installation."
- Stop the wsgw, wsgwsoap1, and wsgwsoap2 (if installed) applications.
- Restore the gateway configuration files that you backed up in step 1,
by copying them back to their original locations. Replace any files of the
same name that were created when the enterprise applications started.
- Restart the wsgw, wsgwsoap1, and wsgwsoap2 (if installed) applications.
Installing the Web
Services Gateway into a deployment manager cell
If you are installing
to your first remote server, complete the following steps:
- Follow the instructions given in the article entitled, "Installing the
gateway into a deployment manager cell".
- Use FTP to copy the WSGWResourceBundles.jar file from the WebSphere_DeployMgr_root/lib directory
(by default WebSphere/DeploymentManager/lib) to the /lib directory
of the remote server (by default WebSphere/AppServer/lib).
For subsequent servers, complete the following steps:
- Use the IBM WebSphere Application Server Network Deployment administrative
console to map the new server to each existing gateway application (in the
administrative console click the required application, then click Map modules
to application servers, highlight the required servers and apply them
to the required modules).
- Use FTP to copy the WSGWResourceBundles.jar file
from the WebSphere_DeployMgr_root/lib directory
(by default WebSphere/DeploymentManager/lib) to
the /lib directory of the remote server.
- Stop, then restart the application servers.
Two class libraries are
available for Universal Description, Discovery, and Integration 4J
Universal
Description, Discovery, and Integration 4J (UDDI4J) is a class library that
provides an API used to interact with a UDDI registry.
Two class libraries
are provided for UDDI4J in the library subdirectory:
- uddi4j.jar supports Version 1 of the UDDI
API. This support is provided for compatibility with applications written
using UDDI Version 1, and the classes in this class library are deprecated.
- uddi4jv2.jar supports Version 2 of the UDDI
specification. Any application using UDDI4J to communicate with a Version
2 UDDI-compliant registry should use the class in this library.
Errors occur if you stop
and restart the UDDI Registry application from the administrative console
and then use the user console
If you stop and restart the UDDI Registry
application from the administrative console, and then try to access the registry
through the user console, an Error 500 - object is
not an instance of a declaring class displays on the user console, and
the error message SRVE0026E displays in the system
log. You cannot access the UDDI Registry until you restart the IBM WebSphere
Application Server.
To avoid seeing this problem when you restart the
UDDI registry application, perform the following steps using the IBM WebSphere
Application Server Administrative Console:
- Click Applications > Enterprise Applications.
- In the list of applications, locate and click the UDDI application link.
- Scroll down to the Related Items section and click Web Modules.
- Click gui.war.
- Change the Classload Mode value to PARENT_LAST (instead
of PARENT_FIRST).
An UDIN2041I error
might occur with the wsadmin appserversetupuddi.jacl command
The
following scripting error might display when you run the wsadmin appserversetupuddi.jacl command:
UDIN2041I: Starting UDDI application. UDIN8019E: startApplication command for appname caught exception Exc. Values are: appname=UDDIRegistry, Exc=com.ibm.ws.scripting.ScriptingException: com.ibm.websphere.management.exception.ConnectorException: ADMC0009E: Failed to make the SOAP RPC call: invoke
During installation, if you see the previous error after running the appserversetupuddi.jacl command,
you can ignore the error. It is recommended that you start (or stop and restart)
the application server and then continue.
An exception is thrown when
using Web Services Invocation Framework to create a Java Message Service response
to a Web service
The following exception is thrown when you use
Web Services Invocation Framework (WSIF) to create a Java Message Service
(JMS) response to a Web service:
org.apache.wsif.WSIFException: cannot find binding operation for formatter
This is fixed in the latest cumulative security fix for WebSphere
Application Server, Version 5.0.1. You can download the fix at the following
Web site:
http://www-3.ibm.com/software/webservers/appserv/was/support/.
From the main page, click All code fixes and support tools in
the Software downloads section. This takes you to the page to search
for a specific fix.
Working with HTTP servers
Cannot start IBM HTTP Server 2.0.42.1 on AIX 5.2
systems
There is a potential IBM HTTP Server 2.0.42.1 startup failure
on AIX 5.2 systems when a non-default AIX resolver configuration is used,
for example, in /etc/netsvc.conf, and the IBM HTTP Server configuration
file, for example, httpd.conf, uses the Listen directives
that do not specify an Internet Protocol address. The following is an example
of the error messages issued by IBM HTTP Server:
[crit] (78) A remote host did not respond within the timeout period.: alloc_listener: failed to set up sockaddr for ::
Syntax error on line 130 of /usr/IBMIHS/conf/httpd.conf
Listen setup failed.
This error is caused by a defect in the AIX resolver library. The
defect is fixed by APAR IY40908 for AIX 5.2. The fix is shipped with AIX52B
Gold and later.
In the meantime, you can take one of the following actions
to solve the problem:
- Use the IPv4-specific Listen directive in the IBM HTTP Server
configuration file, for example, "Listen 0.0.0.0:80"
- Do not override the default AIX resolver configuration.
- Change the following line in the /etc/netsvc.conf file from:
hosts = local = auth , bind
to
hosts = local = auth , bind , local
l
Change the permissions of four files to reduce
the risk of security exposure
When
you update the IBM HTTP Server with WebSphere Application Server, Version
5.0.1on UNIX platforms, there are four files with 777 permissions that need
to be updated. To change the permissions, issue the command chmod 644 <filename>,
where the filename is one of the following files:
<IHS install location>/example_module/Makefile.exmpl
<IHS install location>/example_module/mod_example.exp
<IHS install location>/ssl/ikeyman/en_US/sgkey.sgs
<IHS install location>/version.signature
You must change the
permissions of these files to reduce the risk of security exposures. Also,
if you follow these instructions and change the permissions, the functionality
of IBM HTTP Server is not adversely affected.
ImagePath entry not updated in registry when you
change the document root
When you change the document root in the
IBM HTTP Server Version 1.3.26 administration server, the ImagePath entry
in the registry, corresponding to the HTTP server, does not update. There
are no reported functionality problems caused by this registry entry.
Forms Proxy Settings and Proxy Cache do not behave
correctly
When using Internet Explorer Version 6.0 to view the IBM
HTTP Administration server, the Forms Proxy Settings and Proxy Cache do not
behave correctly. If you select the radio buttons that display editable fields,
the fields do not display.
To work around this problem, use another
version of the browser.
Unable to use the default service names
created by the installer because they are common
In a same version coexistence scenario for IBM HTTP Server Version
1.3.26 or Version 2.0.42 on a Windows platform, you are unable to use the
default service names created by the installer because they are common.
To
work around this problem:
- Install the first copy of IBM HTTP Server, either by itself or with IBM
WebSphere Application Server.
- Customize the service names for the first install by running the following
commands from the first install location:
apache -k install -n "IHS 1.3.26(1)"
apache -k install -f conf\admin.conf -n "IHS 1.3.26 Administration (1)"
- Edit the AdminAlias directive in the <installLocation 1>\conf\admin.conf
file to point to the new service name, for example "IHS 1.3.26(1)".
- Remove the default service names installed by the first install by running:
apache -k uninstall -n "IBM HTTP Server 1.3.26"
apache -k uninstall -n "IBM HTTP Administration 1.3.26"
- Install the second copy of IBM HTTP Server, either by itself or with IBM
WebSphere Application Server. The default service names will now correspond
to the second install.
Note: The custom service names above need to be unique on your system
and are not required to be those exact strings.
Null pointer exception during interactive
installation of IBM HTTP Server on AIX systems
When installing IBM HTTP Server as a standalone GUI installation
on the AIX platform, you can receive a null pointer Java error on the installation
panels, when the installer begins to copy files to your machine. This situation
is caused by an unstable AIX Object Data Manager (ODM) registry.
To
work around this problem:
- Exit the installer.
- Issue the lslpp -l|grep IHS command to see
if there are remaining IBM HTTP Server registry entries that should not be
there.
- If there are remaining IBM HTTP Server registry entries, do a silent installation
of IBM HTTP Server by running the following command:
java -jar setup.jar -silent -P ihs.installLocation=<the desired install location>
Note: To remove the installation silently, add the -silent parameter
to the regular uninstall command, for example:
java -jar _uninst/uninstall.jar -silent
from
the IBM HTTP Server installation location.
Certificate Revocation List is not supported
for IBM HTTP Server on HP-UX and Linux/s390
Using Certificate Revocation List (CRL) with IBM HTTP Server HP-UX
and Linux/s390 is not supported at this time.
Problem using the ikeycmd command-line
interface from IBM HTTP Server on Linux/390
You can see a Java core dump after executing an ikeyman command
function, such as creating the stash file. This core dump occurs on both RedHat
and SuSE releases and is the result of a conflict in library routines caused
by the default loading sequence.
To work around this problem, set the LD_PRELOAD=/usr/lib/libstdc+//0-libc6.1-2.so.3 environment
variable before running the command. Then, this library loads first when the
application is starts. Note that setting this environment variable is also
necessary to allow Secure Sockets Layer to work correctly on Linux390.
