Last updated 8/30/2001
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
You can find complete installation instructions in the Enterprise Edition InfoCenter, available for viewing or download on the InfoCenter page at www.ibm.com/software/webservers/appserv/infocenter.html.
If you installed the Advanced Edition server or client as a base for Enterprise services, you may need to apply additional e-fixes. Specific e-fix requirements are noted below, in the section "Defects and workarounds". E-fixes are available for download from the FixPacks and E-fixes page at www.ibm.com/software/webservers/appserv/efix.html.
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.
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
Business Rule Beans (BRBeans)
CORBA C++ SDK
Extended Messaging support
Tracing and debugging
If you choose to install CORBA support for AIX and you do not have the C++ compiler installed, you need to manually install the latest IBM Open Class libraries (vacpp.ioc) as described in the Enterprise services Installation Guide. In order to install vacpp.ioc successfully, the xlC.C fileset is also required. All of these filesets are included on your Enterprise Edition Server CD.
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.
On Unix, there is no message to indicate whether or not your uninstallation was successful. The following information can help you verify that Enterprise Edition was successfully uninstalled.
First, note the commands to verify that your installation of Enterprise Edition was successful:
lslpp -L | grep IBMeex
You should see the following output:
Server installation: IBMeex 4.0.0.0 C WebSphere Enterprise Edition
Client installation: IBMeexC 4.0.0.0 C WebSphere Enterprise Edition
Solaris:
pkginfo | grep IBMeex
You should see the following output:
Server installation: application IBMeex WebSphere Enterprise Edition
Server
Client installation: application IBMeexC WebSphere Enterprise
Edition Client
Upon successful uninstallation, you should see nothing when you enter the above commands.
The "Space needed" and "Space available" information, as provided on the Install Options Selected panel, is reasonably accurate but you typically require a little more disk space than is shown under "Space needed". Depending on the packages you select, the minimum disk space needed for an Enterprise services installation is 50 MB, and the maximum is 138 MB. Due to an error in space calculation during file copy, you may get a "Not enough disk space .." error message that prevents you from completing the installation even when you have sufficient space.
Workaround: Ensure that you have more disk space available than the amount displayed under "Space needed". Also, be aware that if you click Back while on the Install Options Selected panel, the amount of required disk space increases. In this case, you should cancel the current installation and start over again.
Following a client installation on Unix,
the enterprise services update to the file
product.xml
is incomplete. The file does not include
information about which enterprise services
were installed.
Workaround: To determine which services were
installed, view the file IBMeexC_subpackages
:
AIX: /usr/WebSphere/AppClient/Enterprise/etc/IBMeexC_subpackages
Solaris: /opt/WebSphere/AppClient/Enterprise/etc/IBMeexC_subpackages
The uninstallation program runs a batch file to remove any files leftover after running the InstallShield uninstall program. If you do not have the MKS Toolkit installed, the commands in this batch file fail and you need to manually delete the files as follows:
Server uninstallation:
cd c:\winnt
uninstWAS40.exe
uninsteexs.exe
eexscleanup.bat
eexsinstall.log
Client uninstallation:
cd c:\winnt
uninstj2ee.exe
uninsteexc.exe
eexccleanup.bat
eexcinstall.log
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
After installing the BRBeans Movie sample on Advanced Developer Edition, JNDI names are switched between two sets of EJBs on the Modify EJBs to JNDI Names mapping panel, causing a ClassCastException when you start the Rule Management utility.
Workaround: Apply e-fix PQ51678, available for download from the FixPacks and E-fixes page
When triggering a BRBeans rule that is defined to use the RuleAND or RuleOR rule implementors, a NullPointerException is returned if a dependent rule is not found. This exception occurs in the RuleAND or RuleOR rule implementor code.
Workaround: Ensure that dependent rules, as specified by the RuleAND or RuleOR rule implementor, exist and that those rules are scheduled to be in effect.
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.
When you try to access help files from the Rule Management Application, Netscape is not launched automatically. If an instance of Netscape is already running, the help file is displayed correctly.
Workaround: Open Netscape prior to accessing help from the Rule Management Application.
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 for private class variables, and those getters and setters are named according to the JavaBeans 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 ValuetypeSampleClient is built for Solaris
7. If you want to run the sample on Solaris
8, you need to rebuild it using the provided
makefile and the accompanying "build-it-yourself"
documentation. To access the documentation,
open the Samples Gallery in your Web browser:
WAS_HOME/Enterprise/Samples/index.htm
.
The source code for the sample uses a hardcoded
Hex value in the RID for the Address custom
valuetype. It is better to use the symbolic
Address_RID
defined in the generated Address.hh
file. This change affects the orb-> register_value_factory()
call in Address_I.cpp
, and the VtlUtil::getFactory()
call in ValuetypeSampleClient.cpp
. Here is the correct code for these two
lines, respectively:
retfact = _sampleOrb->register_value_factory((char *)::com::ibm:websphere::
vtlib::sample::Address::Adresss_RID, fact.in());
Address_init* factory = (Address_init*) VtlUtil::getFactory(::com::ibm::websphere::
vtlib::sample::Address::Address_RID);
If you encounter problems running the code that sends the custom valuetype, for example, if VtlUtil::getFactory() returns a null leading to a core dump, update the two lines of code as shown above, then rebuild the client.
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.
The topic "Creating your own C++ valuetypes" has been updated in the latest version of the InfoCenter (09/14 or later).
The documentation has been updated for both the "Pub/Sub" and "Point-to-Point" samples.
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 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.
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.
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 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 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
.
The Object Level Trace and Debugger tools cannot trace an application running a native C++ client and calling enterprise beans hosted by a WebSphere server.
Workaround: Apply e-fix PQ51494, available for download from the FixPacks and E-fixes page.
When you attempt to trace a WebSphere C++ client on AIX using Object Level Trace (OLT), the following error messages are displayed:
SOMDynamicLinkLibrary(libivbtr30.so) errno=8; 0509-130 Symbol resolution failed for /usr/WebSphere/AppServer/Enterprise/lib/libivbtr30.so because: 0509-136 Symbol memcpyFPvPCvUl (number 170) is not exported from dependent module /usr/WebSphere/AppServer/Enterprise/lib/libsomcscd.so.
Workaround: Apply e-fix PQ51951, available for download from the FixPacks and E-fixes page.
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.