Changes since 2.6.1

Changes since 2.7.0

Support for DII

Implemented the following members of the Dynamic Invocation Interface:

• CORBA::ORB::send_multiple_requests_oneway()
• CORBA::ORB::send_multiple_requests_deferred()
• CORBA::ORB::poll_next_response()
• CORBA::ORB::get_next_response()

Change in DII semantics

The usage of the DII has changed slightly. Request::poll_response() no longer throws exceptions under any circumstances (not even when omniORB::diiThrowsSysExceptions is true). Instead if an exception has been generated, and diiThrowsSysExceptions is true, the exception will be thrown from the next accessor method in called on the CORBA::Request. See the manual for more information.

Bugs fixed

The complete list of bugs reported and fixed can be found here. All the bugs listed have been fixed.

The omniORB manual

... has been updated.

Changes since 2.6.1

Support for DII and DSI

The Dynamic Invocation Interface and Dynamic Skeleton Interface are now fully supported.

Interface Repository

The CORBA::Object::_get_interface() operation is now supported on the server side (the GIOP operation name is _interface). This operation has also been implemented on the client side for platforms with namespaces, but is not enabled by default. To enable this feature you must add the line:

       #define ENABLE_CLIENT_IR_SUPPORT

at a suitable point in CORBA_sysdep.h. The runtime libraries will also need to be recompiled.

Library reorganisation

The omniORB runtime library has been split into two. Those parts of the runtime which implement the 'dynamic' aspects of the standard (Any, TypeCode, DynAny, DII, DSI) are in a new library. Existing makefiles which use omniORB's build environment will continue to work, and use both libraries by default. The current shared runtime library versions are:

On various unices:

• libomniORB2.so --> libomniORB2.so.7 --> libomniORB2.so.7.0
• libomniDynamic2.so --> libomniDynamic2.so.7 --> libomniDynamic2.so.7.0

On IBM AIX:

• libomniORB27.a
• libomniDynamic27.a
• libomniLC2.a

On Windows NT/95, the omniORB2 runtime DLLs for this version are:

• libomniORB270_rt.dll
• libomniORB270_rt.lib
• libomniDynamic270_rt.dll
• libomniDynamic270_rt.lib
• libomniLC22_rt.dll
• libomniLC22_rt.lib

Make sure you update your Visual Studio to pick up the right library.

NB. VMS systems have a limitation of 8 directory levels, and this reorganisation has deepened the distribution tree by one level. It is now unfortunately necessary to install the distribution in a root directory.

IDL stubs must be regenerated with the new IDL compiler to be compatible with the runtime library.

Stub enhancements

• The stub code for proxy calls has been restructured to decrease the overhead per operation/attribute.
• For egcs 1.1.1 namespaces are used to represent IDL modules, and the c++ bool type is used to represent IDL boolean. If you are using some libraries that have #define bool, it is best to disable this feature by passing -DNo_Cplusplus_Bool to the C++ compiler.
• Reopen IDL modules is allowed by default when the IDL compiler is compiled on egcs (in addition to MSVC++ and DEC C++ v6.0). The -m flag can be given to omniidl2 to explicitly enable reopen module on all platforms. However, the stub code will not compile unless namespace is used to represent modules.
• The support for compiling stubs into Windows DLLs has been clarified. See the comment in CORBA_sysdep.h
• The IDL compiler now generates three files. For input foo.idl they are:

  foo.hh

  the header file

  fooSK.cc

  type definitions, client and server call stubs et cetera

  fooDynSK.cc

  TypeCodes of user defined types, and support for marshalling these values into and out of values of type Any.

  This, combined with the splitting of the runtime library in two, should make it possible to have much smaller binaries (particularly for applications not using shared libraries). If support for TypeCode and Any is not needed then only fooSK.cc need be compiled and linked in, and libomniDynamic (or equivalent) need not be linked in. NB. Some compilers instantiate template code when a typedef is encountered. This can cause parts of the 'dynamic' library to be referenced, even if not directly used. In this case both the omniORB and omniDynamic libraries will have to be linked into the program.

Support or TypeCode and Any

This part of the library has been completely re-implemented. This should give significant performance improvements. There are no changes to the public interface.

Support of the DynAny interface

The DynAny interface has been re-implemented to use the new version of TypeCode and Any.

New runtime configuration variable

omniORB::diiThrowsSysExceptions

This variable controls the behaviour of deferred requests in the Dynamic Invocation Interface. If it is zero then any system exception generated by a DII call is packaged into a CORBA::Environment object. If it is non-zero system exceptions will be thrown. User-defined exceptions are always passed via a CORBA::Environment object. The value is zero by default.

New command line options

To set the value of omniORB::diiThrowsSysExceptions (above):

• -ORBdiiThrowsSysExceptions <1|0>

To control the idle connection scan period:

• -ORBinConScanPeriod <secs>
• -ORBoutConScanPeriod <secs>

Bugs fixed

The complete list of bugs reported and fixed can be found here. All the bugs listed have been fixed.

x86 Linux systems with glibc 2.0 library (e.g. Redhat 5.1)

omniORB2 is known to work well with egcs-1.1.1. This release incorporates important big fixes and is well worth getting hold of. Warning: there may still be bugs in the compiler which will cause it to generate the wrong code with -O2. If in doubt, remove the optimisation flag - use this line in dir.mk:

    CXXDEBUGFLAGS =

The omniORB manual has been updated

For comments, feedback, etc, please see the 'Keeping in touch' page.
Copyright 1999 - AT&T Laboratories Cambridge