Copyright © Micro Focus 2002-2016. All rights reserved.
The OpenFusion TAO 2.3.1 Release Notes cover the following topics:
Supported Platforms and Compilers
OpenFusion TAO Directory Organisation
Upgrading to OpenFusion TAO 2.3.1
Interoperability and Compatibility
Micro Focus offers various builds:
Micro Focus supports a wide variety of platforms and compilers. For an up-to-date list, please see the Product Availability and Support Schedule or contact us via https://www.microfocus.com/
Additional operating system / compiler combinations may be supported based on demand.
The OpenFusion TAO directory organisation is different from other TAO distributions.
The Micro Focus distribution has a modified directory structure to make it more readable and usable.
The directory structure is as follows:
Micro Focus TAO distribution is by default built with the following options:
Key: The values in the Must Match column have the meanings defined below.
Y - the application must have the same value as the build
N - the application may use any value it chooses
E - the application can only use this option if it was set at build time
B - this option is only effective at build time
The inline, debug, Unicode, MFC, IPv6, SSL and FT flags are set according to the build. See the build availability list above.
| Option | Description | Must Match | Default Build Flags (Solaris, HP-UX, Linux, LynxOS) | Default Build Flags (Windows XP, Windows Vista, Windows 7) |
|---|---|---|---|---|
| stdcpplib | Enable standard C++ library | Y | 1 | 0 |
| threads | Enable threads (if OS supports) | Y | 1 | 1 |
| optimize | Turn on compiler optimiztion | N | 1 | 1 |
| repo | Use GNU template repository | N | 0 | 0 |
| fast | Use -fast compiler option (SunCC only) | N | 0 | 0 |
| purify | Third party product support | N | 0 | 0 |
| quantify | Third party product support | N | 0 | 0 |
| profile | Enable profiling | N | 0 | 0 |
| shared_libs | Build shared libraries | E | 1 | 0 |
| static_libs | Build archive libraries | E | 0 | 0 |
| shared_libs_only | Build shared libraries only | E | 1 | 0 |
| static_libs_only | Build static libraries only | E | 0 | 0 |
| minimum_corba | Build with minimum CORBA support | B | 0 | 0 |
| probe | Enable ACE_Timeprobes | B | 0 | 0 |
| ami | Enable Asynchronous Method Invocation (AMI) | Y | 1 | 1 |
| smart_proxies | Enable Smart Proxies | Y | 1 | 0 |
| corba_messaging | Enable CORBA Messaging | Y | 1 | 1 |
| rt_corba | Enable Real-time CORBA support | Y | 1 | 1 |
| interceptors | Enable portable interceptors | Y | 1 | 1 |
| interface_repo | Enable Interface Repository support | N | 1 | 1 |
The following libraries and executables are the TAO product deliverables:
CORBA applications report errors via catching thrown CORBA exceptions. (Note that TAO no longer provides CORBA defined/emulated exceptions, instead it relies on standard, native C++ exception-handling, using try and catch statements.) CORBA exceptions are split into two different forms: "System exceptions" which are thrown by the ORB itself and "User exceptions" that are defined by IDL statements declared by the ORB provided services or end-user applications.
Normally simply catching the specific CORBA exception is enough to indicate
the problem; but the CORBA standard allows the ORB vendor to supply
supplemental information with each exception in the form of its minor code
which is a numerical CORBA::ULong value (obtained from the
caught exception itself via the minor() accessor function). This
value is split up into several sub-fields; the upper most significant 20-bits
are reserved to indicate which ORB originated the minor code itself, while the
least significant 12-bits are used by that ORB as it sees fit (TAO splits these
12-bits into two sub-fields). Note that the actual ORB specific minor codes are
not meant to be portable between different CORBA ORBs; those provided by TAO
are listed below. In addition some simple minor codes are actually detailed in
the CORBA standard for specific circumstances; a minor code of 0x00000000u
for example, simply indicates no further details are available. All of these
CORBA defined codes have zero in the most significant 20-bits. These codes are
mainly used to enable support or debugging to determine why the exceptions are
being thrown in the first place. They will probably have little relevance to an
end user's application unless they are attempting to specialise the handling of
certain otherwise generic exceptions.
CORBA Exception Minor Code (CORBA::ULong): |
||
|---|---|---|
| 20-MSBits | 5-Bits | 7-LSBits |
Identifier 0x54410u << 12 (in ASCII "TA" and a zero nibble) |
Location Code | Error Code |
Full details of the TAO Location Codes can be found in the "Error Handling" chapter of the OCI "TAO Developer's Guide" book, but the best insight may be found by searching the TAO source code directly for the specific used #define Location Code identifiers shown in the table below.
| TAO (5-bit) Location Code | Description | Value |
|---|---|---|
| No specific location details indicated | (0x00u << 7) | |
| TAO_INVOCATION_LOCATION_FORWARD_MINOR_CODE | Location forward failed | (0x01u << 7) |
| TAO_INVOCATION_SEND_REQUEST_MINOR_CODE | Send request failed | (0x02u << 7) |
| TAO_POA_DISCARDING | POA in discarding state | (0x03u << 7) |
| TAO_POA_HOLDING | POA in holding state | (0x04u << 7) |
| TAO_UNHANDLED_SERVER_CXX_EXCEPTION | Unhandled C++ exception in server side | (0x05u << 7) |
| TAO_INVOCATION_RECV_REQUEST_MINOR_CODE | Failed to receive request response | (0x06u << 7) |
| TAO_CONNECTOR_REGISTRY_NO_USABLE_PROTOCOL | All protocols failed to parse the IOR | (0x07u << 7) |
| TAO_MPROFILE_CREATION_ERROR | Error during MProfile creation | (0x08u << 7) |
| TAO_TIMEOUT_CONNECT_MINOR_CODE | Timeout during connect | (0x09u << 7) |
| TAO_TIMEOUT_SEND_MINOR_CODE | Timeout during send | (0x0au << 7) |
| TAO_TIMEOUT_RECV_MINOR_CODE | Timeout during receive | (0x0bu << 7) |
| TAO_IMPLREPO_MINOR_CODE | Implrepo server exception | (0x0cu << 7) |
| TAO_ACCEPTOR_REGISTRY_OPEN_LOCATION_CODE | Endpoint initialization failure in Acceptor Registry | (0x0du << 7) |
| TAO_ORB_CORE_INIT_LOCATION_CODE | ORB core initialization failed | (0x0eu << 7) |
| TAO_POLICY_NARROW_CODE | Failure when narrowing a Policy | (0x0fu << 7) |
| TAO_GUARD_FAILURE | Failure when trying to acquire a guard/monitor | (0x10u << 7) |
| TAO_POA_BEING_DESTROYED | POA has been destroyed or is currently being destroyed | (0x11u << 7) |
| TAO_POA_INACTIVE | POA in inactive state | (0x12u << 7) |
| TAO_CONNECTOR_REGISTRY_INIT_LOCATION_CODE | Initialization failure in Connector Registry | (0x13u << 7) |
| TAO_AMH_REPLY_LOCATION_CODE | Failure when trying to send AHM reply | (0x14u << 7) |
| TAO_RTCORBA_THREAD_CREATION_LOCATION_CODE | Failure in thread creation for RTCORBA thread pool | (0x15u << 7) |
The table below lists the TAO Error Codes; these are based upon the posix standard C errno equivalent codes. These errno values may help determine what the real problem might have been, as they represent the underlying Operating System error that resulted in the exception being thrown (if any).
| TAO (7-bit) Error Code | Description | Value |
|---|---|---|
| TAO_UNSPECIFIED_MINOR_CODE | Unspecified minor code | 0x00u |
| TAO_ETIMEDOUT_MINOR_CODE | Connection timed out | 0x01u |
| TAO_ENFILE_MINOR_CODE | Too many files open in system | 0x02u |
| TAO_EMFILE_MINOR_CODE | Too many open files | 0x03u |
| TAO_EPIPE_MINOR_CODE | Broken pipe | 0x04u |
| TAO_ECONNREFUSED_MINOR_CODE | Connection refused | 0x05u |
| TAO_ENOENT_MINOR_CODE | No such file or directory | 0x06u |
| TAO_EBADF_MINOR_CODE | Bad file descriptor | 0x07u |
| TAO_ENOSYS_MINOR_CODE | Function not implemented | 0x08u |
| TAO_EPERM_MINOR_CODE | Operation not permitted | 0x09u |
| TAO_EAFNOSUPPORT_MINOR_CODE | Protocol family not supported | 0x0au |
| TAO_EAGAIN_MINOR_CODE | Resource temporarily not available | 0x0bu |
| TAO_ENOMEM_MINOR_CODE | Not enough space | 0x0cu |
| TAO_EACCES_MINOR_CODE | Permission denied | 0x0du |
| TAO_EFAULT_MINOR_CODE | Bad address | 0x0eu |
| TAO_EBUSY_MINOR_CODE | Device or resource busy | 0x0fu |
| TAO_EEXIST_MINOR_CODE | File exists | 0x10u |
| TAO_EINVAL_MINOR_CODE | Invalid argument | 0x11u |
| TAO_ECOMM_MINOR_CODE | Communication error on send | 0x12u |
| TAO_ECONNRESET_MINOR_CODE | Connection reset | 0x13u |
| TAO_ENOTSUP_MINOR_CODE | Operation not supported | 0x14u |
/etc/hosts file that maps the machine hostname to IPv4 address
127.0.1.1. This can prevent the SSLIIOP transport code from correctly
identifying collocated network addresses. This in turn can prevent certain collocation
optimisations and proper use of Bi-directional GIOP when using SSL connections to
objects within the local host. Commenting or removing the line from the
/etc/hosts can be considered for use as a workaround for this issue.
Contact MF Technical Support quoting RPI620412 for more information
if you are impacted by this issue.-features=zla. To avoid this non-default option being required
globally on all compilation, OpenFusion TAO applies a workaround such that the macro
__SUNPRO_C is temporarily defined whilst the netinet/sctp.h
file is processed. If this workaround causes any problems it can be disabled by compiling
user applications with the options: -DACE_WORKAROUND_ZLA_IN_SCTP_H=0 -features=zlaACE_Time_Value such that ACE_Time_Value(1, -1000000) != ACE_Time_Value(0)-ORBListenEndpoints on
a port already in use by another server without an exception being generated.
Trying to start a second server on a port already in use is an error, so
a workaround is not to specify a port that is in use. Users impacted by this
issue should contact MF Technical Support quoting RPI620772.tests/SSL/Bug_2912_Regression_Test fails on Solaris 11.
The problem has not been fully diagnosed but is believed to be connected to
an issue with asynchronous IO with the proactor that does not affect
ORB operation.When using tao_ifr to add idl to the interface repository on Windows with Microsoft Visual C++, you need to have the following in your path:
<TAO Installation dir>\bin
<TAO Installation dir>\lib
Standard Microsoft Visual Studio console environment path additions
where <TAO Installation dir> is the path to the TAO installation directory. This is necesary because the tao_ifr tool makes use of the cl.exe C++ preprocessor which is in a Microsoft Visual Studio directory. Visual Studio provides batch scripts from the Start Menu to set a correct console environment.
Use of ORB::create_operation_list operation will require the TAO_IFR_Client library to be linked into a program. If the TAO_IFR_Client is not linked a NO_IMPLEMENT exception will be raised if ORB::create_operation_list is invoked.
The gcc 3.2 compiler fails to compile generated code for IDL containing fixed size arrays. The gcc 3.2.1 compiler fixes this problem (except on MontaVista Linux release 3.0). This was identified during interoperability testing of OpenFusion TAO releases.
UTF-16 Wide Characters / Wide String Interoperability. (Bug ID 00RE)
Issue 1: UTF-16 strings are being marshalled and demarshalled incorrectly. On little endian platforms little endian encoding is employed without an appropriate byte order marker being used. Characters within incoming strings are assumed to be encoded as per the byte order of the encapsulating stream. These are both in contravention of section "15.3.1.6 Character Types" of the CORBA 3.0 specification.
Issue 2: No account is taken of the byte order of an input stream when decoding a wide character type. Wide character passing between platforms with differing endian setting results in corrupted data.
Table Key:
| Product | Direction | Product | Status |
|---|---|---|---|
| JacORB | -> | TAO-BF LE | wstring OK, wchar Broken |
| JacORB | <-> | TAO-BF BE | OK |
| TAO-BF LE | -> | JacORB | Broken |
| TAO-BF LE | <-> | TAO-BF BE | OK |
| TAO-BF LE | <-> | TAO-BF BE | wstring OK, wchar Broken |
| TAO-BF BE | <-> | TAO-BF BE | OK |
| Product | Direction | Product | Status |
|---|---|---|---|
| JacORB | -> | TAO-AF LE | OK |
| JacORB | <-> | TAO-AF BE | OK |
| TAO-AF LE | -> | JacORB | OK |
| TAO-AF LE | <-> | TAO-AF BE | OK |
| TAO-AF LE | <-> | TAO-AF BE | OK |
| TAO-AF BE | <-> | TAO-AF BE | OK |
| Product | Direction | Product | Status |
|---|---|---|---|
| TAO-AF LE | <-> | TAO-BF LE | Broken |
| TAO-AF BE | <-> | TAO-BF BE | OK |
| TAO-AF LE | -> | TAO-BF BE | Broken |
| TAO-AF BE | <- | TAO-BF LE | wstring OK, wchar Broken |
| TAO-AF LE | <- | TAO-BF BE | Broken |
| TAO-AF BE | -> | TAO-BF LE | wstring OK, wchar Broken |
Memory mapped IFR persistence doesn't work on Linux. (Internal issue TAO#453)
The memory mapped IFR persistence mechanism (-p service option) has been discovered to have incompatibilities with versions of the RedHat Enterprise Linux (v4 and upwards) and SUSE Linux Enterprise Server (v12) kernel libraries. These consistently result in memory corruption and crashes of the service. The testing of this feature has also encountered ACCESS VIOLATION errors on Windows. There have been additional reports of problems on Fedora Core systems and earlier versions of RedHat Enterprise Linux. We therefore strongly recommend that this persistence option is not used on either Windows or Linux. Please use the flat file service persistence (-f option) instead as this mechanism is more stable.
Default version of Openssl is different for SUSE 12
The following tests will fail on SUSE 12 by default:
TAO/orbsvcs/tests/Security/Null_Cipher
TAO/orbsvcs/DevGuideExamples/Security/PolicyControllingApp
This is because the default version of openssl that comes with SUSE 12 is 1.0.1i-fips as they have deprecated openssl-0.9.8, though it is still possible to use openssl-0.9.8 through SUSE's Legacy Module. (see: https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-316681 ). Because the default version of Openssl is different, some changes have been made which cause the above tests to fail, notably: the disabling of eNULL ciphers by default. (see: https://www.openssl.org/news/changelog.html#x40 ). Please keep in mind that using Openssl-0.9.8f or higher will cause the same behaviour on other systems unless you also enable the use of eNULL ciphers.Solaris Sparc intermittent test failure
The Following test fails on Solaris Sparc machines intermittently:
TAO/orbsvcs/tests/ImplRepo/PICurrent
This test will occasionally fail with a client timeout error, possibly due to a race condition in the test. Running the test script with the '-debug' option will ensure that this test passes. Contact MF Technical Support quoting RPI620849 for more information if you are impacted by this issue.Copyright © Micro Focus 2002-2016. All rights reserved.