Last updated 06/09/2003
This document is updated periodically. For the latest version, check the WebSphere Application Server InfoCenter page at www.ibm.com/software/webservers/appserv/infocenter.html.
These release notes are for enterprise services only. For a description of enterprise services, see the topic What are enterprise services? in the Enterprise Edition InfoCenter.
Separate release notes are available for the following products:
Prerequisites
Installing enterprise services
Business Process Beans (BPBeans) technology
preview
Defects and workarounds
The following Web site lists software products that are required by, or supported for use with, WebSphere Application Server:
www.ibm.com/software/webservers/appserv/doc/latest/prereq.html
Note: This release of enterprise services does not support CICS Universal Clients & Transaction Gateway.
You can find complete installation instructions in the Enterprise Services Installation Guide (pdf).
Most installations of enterprise services (with the exception of CORBA C++ clients) require that you first install the Advanced Edition server or client in order to provide a J2EE base. To install Version 4.1 enterprise services, your Advanced Edition base needs to be at a Version 4.0.2 level. This level is equivalent to Version 4.0 (or 4.0.1) plus FixPack 2. Advanced Edition Version 4.0 is included in your Enterprise Edition box. You can download FixPack 2 from the following Web page:
http://www.ibm.com/support/manager.wss?rs=180&rt=0&org=SW&doc=4001038.
When you perform an uninstallation of WebSphere Application Server, both Advanced Edition and enterprise services are removed from your system. There is no separate uninstallation program for enterprise services. Be aware that, after you install enterprise services, there is no way to uninstall (or "back out") Advanced Edition FixPack 2 .
Unlike the Advanced Edition installation, the Samples Gallery for enterprise services is not installed during a "Typical" installation. In order to install the samples for enterprise services, select the "Custom" installation option, then select "Samples" from the list of options.
BPBeans is a new technology for building Java components that use extended transaction processing paradigms. BPBeans can do the following:
BPBeans is a technology preview. This means that you can use the technology for demonstrations or "proof of concept" projects. You cannot use BPBeans in a production environment. You can install BPBeans on Windows NT Version 4, with SP4 or later, or on Windows 2000. This technology preview includes application tooling, runtime, and documentation. It is available in US English only.
To install the BPBeans technology preview,
run the command Windows/BPB_tech_preview/BPBeansSetup.exe
located on your Enterprise Edition Server
CD. This command installs the application
tooling, runtime, and documentation.
The following sections provide information about known defects and workarounds, as well as supplemental information for topics covered in the Enterprise Edition InfoCenter. Unless otherwise noted, defects and workarounds apply to all supported platforms.
Installation
ActiveX to EJB bridge
Business Rule Beans (BRBeans)
CORBA C++ SDK
Extended Messaging support
National language concerns
On installation panels that include a text field, the Tab key does not move the focus forward after reaching the text field, which prevents you from proceeding to the next panel.
Workaround: Use a pointing device to click the Next button.
During installation on Solaris (X11 display), the small window in which you make your selections can become hidden behind the larger background window when the background window is brought into focus.
Workaround: Bring the small window back to the foreground by pressing Alt+Tab, then click on the small window to give it focus.
The CallByName() function in Visual Basic is used with the ActiveX to EJB bridge when the case of a Java method call cannot be guaranteed (for example, Visual Basic changes myJavaObject.create to myJavaObject.Create). As documented in the Microsoft Knowledge Base article Q194418 at http://support.microsoft.com/support/kb/articles/Q194/4/18.ASP:
"When an error is raised in a procedure of an ActiveX server and the procedure is called with the CallByName() function from a client, the client always gets error 440 regardless of the original error number being raised."
All Java exceptions that would normally be thrown as error 0x6003 with the Java stack trace embedded in the error description are instead thrown as error 440 with the words "Automation Error" embedded in the error description.
Workaround: Complete one of the following steps:
The following error is displayed if you have any invalid parameters in the XJBInit() string array:
0x6002 "XJBJNI::Init() Failed to create
VM" when calling XJBInit().
If you have C++ logging enabled, the activity log shows what the invalid parameter is.
The ActiveX to EJB bridge provides two logging and tracing formats: C++ and Java.
C++ activity log
The C++ activity log shows JNI errors, Java
Console error messages, and XJB initialization
messages. This log is most useful for determining
XJBInit() errors and any unusual exceptions
that do not come from the Java environment.
To enable the C++ activity log, you need to install the CORBA C++ SDK client. Once installed, the ActiveX to EJB bridge detects the presence of the SDK and automatically enables logging. For details on how to modify log settings, See the topic "Corba support > Developing a C++ CORBA Server > Specifying Runtime properties" in the Enterprise Edition InfoCenter.
By default, the log is created in the WAS_HOME\Enterprise\service
directory. For service programs such as Active
Server Pages, the log is created in the C:\WINNT\SYSTEM32\service
directory. The default log directory can
be overridden using the SOMCBASE environment
variable, which is set by launchClientXJB.bat
and setupCmdLineXJB.bat
in the WAS_HOME\Enterprise\bin
directory.
For example, to activate the property file set the SOMCBASE environment variable as follows (you must use a System environment variable for Active Server Pages):
set SOMCBASE= C:\WebSphere\AppClient\Enterprise
Once the application is restarted, a log
file named activitycpp.log
is created in the C:\WebSphere\AppClient\Enterprise\service
directory. To view the log, open a command
window, change directories to C:\WebSphere\AppClient\Enterprise\service
, then enter the following command:
launchClientXJB showlogcpp activitycpp.log
To disable logging once the C++ SDK is installed,
rename the SOMRSBSM.DLL
file located in the WAS_HOME\Enterprise\bin
directory. Note that renaming this DLL renders
the C++ SDK unusable.
Java trace log
The Java trace log displays information that
you can use to debug method calls, class
lookups, and argument coersion problems.
Since the Java portion of the bridge mirrors
the functionality of the COM IDispatch interface,
the information in the trace log is similar
to what you have come to expect from an IDispatch
interface. To understand the trace log,
you need a fundamental understanding of IDispatch.
To enable user-logging, add the following
parameters to the XJBInit()inputstringarray
:
"-DtraceString=com.ibm.ws.client.xjb.*=event=enabled" "-DtraceFile=C:\MyTrace.txt"
For example, if you are having problems with the following Visual Basic code:
Dim oInt as Object
Dim strHexValue as String
Set oInt = oXJB.FindClass("java.lang.Integer")
strHexValue = oInt.toHexString(24579)
The resulting trace for the failing line would look something like this:
[01.07.31 11:17:13:815 CDT] 6b2d2635 JDispatch E dispGetIDsOfNames: Retrieving DISPID from Method or Field. ClassID:-102|ObjectID:0|Name:FindClass|Result DISPID:60 [01.07.31 11:17:13:875 CDT] 6b2d2635 JDispatch E dispInvoke: Retrieving Member from DISPID and Arg Types. ClassID:-102|ObjectID:0|DISPID:60|Arg Sig:Ljava.lang.String;|Found Member:public static java.lang.Class com.ibm.ws.client.xjb.JClassFactory.FindClass(java.lang.String) throws java.lang.Exception [01.07.31 11:17:13:946 CDT] 6b2d2635 JClassFactory E
FindClass complete. ClassName:java.lang.Integer|ClassID:-103 [01.07.31 11:17:13:946 CDT] 6b2d2635 JDispatch E dispInvoke: Method.invoke() Succeeded. Result:
class java.lang.Integer [01.07.31 11:17:13:956 CDT] 6b2d2635 JDispatch E dispGetIDsOfNames: Retrieving DISPID from Method or Field. ClassID:-103|ObjectID:0|Name:toHexString|Result DISPID:115 [01.07.31 11:17:13:986 CDT] 6b2d2635 JDispatch E dispInvoke: Retrieving Member from DISPID and Arg Types. ClassID:-103|ObjectID:0|DISPID:115|Arg Sig:S|Found Member:NOT FOUND
Here is an explanation of the above trace:
Line 1: | dispGetIDsOfNames() was called on an internal Class (no. -102) looking for the FindClass method. It returned a DISPID (Dispatch ID) of 60. |
Line 2: | dispInvoke() was called on the same internal Class (no. -102) to try and invoke the method associated with DISPID 60 with an argument signature of "Ljava.lang.String;" (Java's internal way of saying java.lang.String. This is the format that javap.exe will output.) The member was found and it's definition displayed in the log. |
Line 3: | The FindClass() method was completed and returned a ClassID of -103 for java.lang.Integer |
Line 4: | dispInvoke: Returns the resulting class java.lang.Integer |
Line 5: | The toHexString method was found in dispGetIDsOfNames and returned a DISPID of 115. |
Line 6: | dispInvoke, however could not find the member with a DISPID of 115 with an Argument Signature of "S" ("S" is the Java's internal way of saying "short"). |
Argument signatures (or Descriptors) are defined as follows:
BaseType Character | Type | Interpretation |
B | byte |
signed byte |
C | char |
Unicode character |
D | double |
double-precision floating-point value |
F | float |
single-precision floating-point value |
I | int |
integer |
J | long |
long integer |
L<classname>; | reference |
an instance of class <classname> |
S | short |
signed short |
Z | boolean |
true or false |
[ | reference |
one array dimension |
For more details, see chapter 4.3.2, Field Descriptors, in the Sun VM Specification:http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html
In the sample code and documentation for
ActiveX to EJB bridge, both forward and backward
slashes are displayed in the WAS_HOME and Java directories. Both Windows NT and
Windows 2000 can handle mixed slashes. For
example, the path C:/WebSphere/AppClient\java\jre
is correct.
The ActiveX to EJB bridge does not have a console available to view Java System.out messages. To view these messages when running a standalone client program (such as Visual Basic), redirect the output to a file. For example, launch your client application using the following command:
launchClientXJB.bat MyProgram.exe > output.txt
To view these messages when running a Service
program such as Active Server Pages, override
Java's System.out OutputStream
object to
a FileOutputStream
. For example, in VBScript you would do the
following:
'Redirect system.out to a file ' Assume that oXJB is an initialized XJB.JClassFactory object Dim clsSystem Dim oOS Dim oPS Dim oArgs
' Get the System class Set clsSystem = oXJB.FindClass("java.lang.System")
' Create a FileOutputStream object Set oOS = oXJB.NewInstance(oXJB.FindClass("java.io.FileOutputStream"), "c:\sysout.txt")
' Create a PrintStream object and assign to it our FileOutputStream Set oArgs = oXJB.GetArgsContainer oArgs.AddObject "java.io.OutputStream", oOS Set oPS = oXJB.NewInstance(oXJB.FindClass("java.io.PrintStream"), oArgs)
' Set our System OutputStream to our file clsSystem.setOut oPS
If using a database other than DB2 with the BRBeans samples (Movie Sample or Simple Sample), you need to modify the generated Table.ddl file. For details, see the topic Modifying Table.ddl file for use with non-DB2 databases.
A new BRBeans Jar file named BRBeansInformix731.jar has been added in the <WAS_HOME>/Enterprise/BRBeans directory to support Informix Version 7.3.1. You must use this jar file if you want to run BRBeans on a server accessing an Informix 7.3.1 database. For Informix Version 9.2.1, continue to use the BRBeansInformix.jar file.
In order to run BRBeans on Informix Version 7.3.1 you also need a fix for Informix bug number 153465. This is a fix to the Informix JDBC driver and is available in Version 2.21 and later of the driver. Without this fix, the BRBeans enterprise beans cannot save their state to the database and BRBeans will not function.
If validate is specified, four warning messages are displayed during deployment of BRBeans. These warnings are for createRule, indicating that arg1 and the return type must be serializable. You can ignore these warning messages.
While importing rules from an XML document that you created using the export function of the BRBeans rule management application, the XML parser returns error messages indicating that the document cannot be parsed and that no rules have been imported. This occurs only when importing a document that was created using the rule management application (not the command line utility). This happens because the export function of the rule management application does not add the correct header and trailer XML tags to the exported XML document
Workaround: Do either of the following:
<!DOCTYPE brb SYSTEM "brb.dtd"> <brb>
Add the following line to the end of the file:
</brb>
Due to a bug in the Merant SequeLink JDBC driver, the clearParameters method does not adequately reset parameters to allow prepared statements to be reused.
Workaround: When using the Merant SequeLink driver with any database, disable prepared statement caching on the BRBeans data source by setting the Statement Cache Size to 0. If using Advanced Edition, the Statement Cache Size property is one of the Connection Pooling properties of the data source. If using Advanced Developer Edition, the Statement Cache Size property is one of the Data Source properties.
When you trigger a rule that has dependent rules, from a Trigger Point that has its Base Folder attribute set to a non-null value, a NullPointerException is returned.
Workaround: Do not set the Base Folder attribute of any Trigger Points that fire rules that have dependent rules.
The Netscape browser does not start after requesting Help from a user interface running on the Solaris platform.
Workaround: Set a valid locale for your session and disable access control.
To set a valid locale, complete the following steps:
locale -a
To set the locale, enter the following command where locale is one of the valid locales:
export LANG=locale
For example, to set locale to United States English, enter:
export LANG=en_US
To disable access control, enter the following command:
xhost +
Complete the following steps to initialize the cds database, which is used by C++ servers and the C++ location service daemon, somorbd:
cdspop
, to initialize the cds database, which is
placed in the SOMCBASE/data directory.
If you run the current version of RMIC against a Java class that includes getters and setters, and those getters and setters are named according to the JavaBean naming conventions, RMIC generates duplicate getters and setters.
Workaround: Modify the Java class to rename the getters and setters.
For example, consider the following piece of code from the Java class "Book":
public class Book implements Serializable { private String BookTitle = null; private double price = 0.0; private int salesCount; public Book() { salesCount = 0; } public void setBookTitle( String name ) { bookTitle = name; } public String getBookTitle() { return( bookTitle ); } ...
The above code contains a getter and a setter for BookTitle. The getter and setter follow the JavaBeans naming convention: get<var> and set<var>. This causes problems for RMIC. The fact that the class variables are declared as private results in RMIC generating IDL with a public and an attribute declaration for each variable, for example:
public long a; attribute long a;
When IDLC is used to generate code from the IDL, two getters and two setters for each class variable are created, one public, the other protected, and the code does not compile.
Workaround: Rename the getters and setters
in the Java class to something that does
not follow the JavaBean naming convention.
Here is one possibility, using sendBookTitle
and receiveBookTitle
:
... salesCount = 0; } public void sendBookTitle( String name ) { bookTitle = name; } public String receiveBookTitle() ...
The CORBA support documentation in the Enterprise Edition InfoCenter states that the valuetype library contains C++ valuetype implementations for the commonly-used java primitive data types. This is not correct.
The valuetype library provides support for many of the primitive classes in the java.lang package such as Integer, Short, and Long. These do not equate to the Java primitive types such as short, long, and integer. The list of C++ valuetype library implemented methods that is provided in the InfoCenter correctly states the various java.lang classes that are provided; however, you should ignore the list of mappings from IDL types to CORBA types as this list is not relevant to the valuetype library.
The printStackTrace(java.io.PrintStream)
and printStackTrace(java.io.PrintWriter)
methods of java::lang::Throwable
are not supported in the valuetype library
due to the difficulty of passing stack trace
from Java into the C++ runtime.
The concrete implementations of the arguments
to the printStackTrace methods, java.io.PrintStream
and java.io.PrintWriter
, are not provided. The stream and writer
valuetypes contained in the valuetype library
(that is, OutputStream, FilterOutputStream,
PrintStream, Writer, and PrintWriter) are
abstract classes that cannot be used as local
output streams in your C++ client program.
The Byte_init method create__()
does not exist in the valuetype library.
Ignore any references to this method in the
CORBA support documentation.
In the InfoCenter article entitled "Creating your own C++ valuetypes", note the corrections to the following commands:
Under step one, the command should be:
rmic -idl java.util.Hashtable
Under step two, the command should be:
idlc .... java/util/Hashtable.idl
To use Extended Messaging support, download and install the latest level of MQSeries supportPac MA88: MQSeries classes for Java and MQSeries classes for Java Message Service: www.ibm.com/software/ts/mqseries/txppacs/ma88.html
Install Version 1.1.3, dated 08/29/01 or later.
The InfoCenter documentation, as well as
the MQSeries documentation, suggests copying
Jar files and library files from the MQSeries\java
directory structure into various WebSphere
directories. While this configuration can
work, it is not recommended for serviceablility
reasons. Upgrades and patches to MQSeries
do not take effect as desired. A more appropriate
method is to include these Jar files on the
Custom Service classpath for the Extended
Messaging Support Service. The MQSeries Jar
files to include are com.ibm.mq.jar
and com.ibm.mqjms.jar
.
If you are using the Advanced Developer Edition (AEd), you must also specify any required naming provider Jar files on the Resource Provider classpath. See Defect 106821.RN for more information.
Because Advanced Edition for Developers (AEd) does not provide a persistent name space, you need to use a second naming provider when configuring Extended Messaging support for use with AEd.
Workaround: Complete the following steps to configure the file system provider as the second naming provider:
Note: The file system naming provider uses the system property "file.separator" as the separator. On Windows platforms, be aware that a name that would normally be bound as jms/mq/Destination is bound as jms\mq\Destination. You may need to escape the single backslash (\) with two backslashes (\\).
JMSAdmin.config
file.
C:\temp\JNDI-Directory
.
JMSAdmin.bat
and bind your ConnectionFactories and Queues/Topics
as you typically would.
http://localhost:9090/admin
).
MQSeriesInstallDir\java\lib\fscontext.jar;
MQSeriesInstallDir\java\lib\providerutil.jar;
MQFscontextProvider
com.sun.jndi.fscontext.RefFSContextFactory
file:/C:/temp/JNDI-Directory
Connection Factory:
Name: ConnectionFactory
JNDI Name: Sample/JMS/ConnectionFactory
JNDI Foreign Name (Windows): Sample\JMS\ConnectionFactory
JNDI Foreign Name (Unix): Sample/JMS/ConnectionFactory
Name: Q1
JNDI Name: Sample/JMS/Q1
JNDI Foreign Name (Windows): Sample\JMS\Q1
JNDI Foreign Name (Unix): Sample/JMS/Q1
When running MQSeries on Linux SuSE Version
7.2, the message broker initialization does
not complete after you issue the startup
command: strmqbrk -m <Queue Manager>
, and you cannot interrupt the command by
pressing CTRL+C. If you check the status
of the message broker using the command dspmqbrk
, the result continues to be "MQSeries
message broker for queue manager <Queue
Manager> starting."
There is no workaround, and therefore you cannot presently run WebSphere applications that use Publish/Subscribe on Linux SuSE Version 7.2.
The JVM supplied with WebSphere on HP-UX does not support the encoding used by MQSeries Queue Managers. This causes the JMS classes to throw a JMSException with an error code of MQJMS1086 and a linked exception of type UnsupportedEncodingException when you attempt to send or publish a message to a Queue.
Workaround: Change the encoding used by the Queue Manager. Change to a CCSID value of 850 or 819 by entering the following commands:
runmqsc
alter qmgr CCSID(850)
For more information, see the MQSeries book Using Java, Chapter 2.
The JMSAdmin tool supplied with the MQSeries supportPac MA88 for administering JMS objects requires that you specify certain configuration parameters. For the Initial Context factory property there are currently three supported values:
com.sun.jndi.ldap.LdapCtxFactory
(for LDAP)
com.sun.jndi.fscontext.RefFSContextFactory
(for file system context)
com.ibm.ejs.ns.jndi.CNInitialContextFactory
(to work with WebSphere’s naming repository)
WebSphere Application Server has deprecated
com.ibm.ejs.ns.jndi.CNInitialContextFactory
, and you should therefore use com.ibm.websphere.naming.WsnInitialContextFactory
instead. For JMSAdmin to work with the WebSphere
naming repository it still needs to use com.ibm.ejs.ns.jndi.CNInitialContextFactory
. The WebSphere Application Server and administered
JMS objects can work together with these
different values for Initial Context factory.
If the LIBPATH environment variable does not contain the path to your MQSeries Java library, the following exception is thrown:
Exception:
no mqjbnd02 (libmqjbnd02.a or .so) in java.library.path
java.lang.UnsatisfiedLinkError: no mqjbnd02
(libmqjbnd02.a or .so) in java.library.path
Workaround: Add the following path to your LIBPATH environment variable:
/mq_install_path/java/lib
When using MQSeries from within WebSphere Application Server the creation of a JMS QueueConnection or an WMQ MQQueueManager can fail with an WMQ Reason Code of 2059 even when the Queue Manager is running. This is because WebSphere uses bindings connections to the Queue Manager that may require some extra configuration.
Workaround: If you are using MQSeries V5.2 there is an extra stanza that can be added to mqs.ini that affects the part of shared memory MQSeries uses when connecting (the mqs.ini file is typically found in the /var/mqm directory). The parameter is "IPCCBaseAddress" and is set on a per queue manager basis. By default this parameter is set to the value "8", but a value of "11" is recommended (allowable values for this parameter are "4", "5", "8", "9", "10", "11" or "12").
The following is an example of an altered QueueManager stanza in an mqs.ini file:
QueueManager:
Name=MQJavaTest
Prefix=/var/mqm
IPCCBaseAddress=11
The Queue Manager must be recycled for the changes to take effect. If "11" does not allow the application to connect as normal then try the other values. The more components involved in the application (WebSphere, DB2, and so on), the less shared memory available for MQSeries to use.
See the following Web site for the latest information on this problem:
http://www.ibm.com/software/ts/mqseries/support/summary/javasupp.html
This problem does not occur when both the application database and administrative database are remote.
When trying to stop the application server after an MQSeries queue manager stoppage, the server process throws an access violation in java.exe. This occurs when Extended Messaging support has been configured on the server and is listening on an MQSeries JMS destination.
Workaround: When using Extended Messaging support, do not stop the MQSeries queue manager prior to stopping the application server. If an abnormal failure causes the queue manager to stop, perform a forced stop of the application server in the administrative console.
Attempting to stop and restart the MQSeries Queue Manager results in the following error:
AMQ8041: The queue manager cannot be restarted
or deleted because processes, that were previously
connected, are still running.
Workaround: Restart MQSeries and the WebSphere Application Server.
A fix for this problem is scheduled to be provided in MQSeries Version 5.2 CSD 3 level. Refer to the MQSeries support page for updates:
http://www.ibm.com/software/ts/mqseries
When receiving a javax.jms.ObjectMessage in a message bean driven by the JMS listener, a call to getObject() on the JMS ObjectMessage occasionally returns a ClassDefNotFound exception. This exception occurs when the application class contained within the ObjectMessage cannot be loaded because it is found in the enterprise bean classloader and not the system classpath.
Workaround: Place the object class definition
within the ws.ext.dirs classpath by copying
the jar file to the directory \WebSphere\AppServer\lib\ext
.
If you configure two WebSphere application servers with JMS listeners that are subscribed to JMS topics using the same MQ JMS subscription queue, you may intermittently lose publications or encounter the following error message on the console:
MQJMS1031: an internal error has occurred
This occurs because MQSeries JMS Pub/Sub support requires each JVM subscriber connection consumer to use a different subscription queue.
Workaround: When you use JMSAdmin to create
your TopicConnectionFactory, either specify
unique BROKERCCSUBQ() subscription queue
names or use the multiple-queue facility
by specifying a prefix; for example, BROKERCCSUBQ(SYSTEM.JMS.ND.CC.MySubQueues.*)
.
In the InfoCenter article entitled "Extended messaging, transaction support", it suggests that to update (reload) the classes used by an application, you must stop the J2EE application and start it again. Stopping the individual J2EE module only does not work in all cases.
Workaround: Note the following correction to the last sentence in the article:
When you have resolved the problem, you must then stop and restart the given message bean's EJB module or, in some cases, the entire application from the Administrative Console.
In this release, the Internationalization
Service does not support Java 2 SDK TimeZone
types other than java.util.SimpleTimeZone
. Unsupported TimeZone types silently map
to default SimpleTimeZone when supplied to
service API methods. This has the following
effects:
java.util.SimpleTimeZone
will map to the default java.util.SimpleTimeZone
of the containing process.
java.util.SimpleTimeZone
.
On HP-UX Version 11.11, only the English locale version of Netscape is provided as a default application. Therefore, when you complete a non-English installation of WebSphere Application Server, the README file cannot be opened.
Workaround: From a command prompt, enter the following command to open the README:
netscape [WAS_HOME]/Enterprise/readme/xx_XX/readme.htm
where xx_XX is one of the following:
de_DE German
en_US English
es_ES Spanish
fr_FR French
it_IT Italian
ja_JP Japanese
ko_KR Korean
pt_BR Brazilian Portuguese
zh_CN Simplified Chinese
zh_TW Traditional Chinese
When running commands in a DOS window, some characters in the output messages are corrupted.
Workaround: Redirect the DOS command to an output file and view the output file using the Windows Write editor.