...[#corba2spec##1#]
  Most of the 2.3 features have been implemented. The features still missing in this release is listed in 1.1.4. Where possible, backward compatibility has been maintained up to specification 2.0.

...1999
  More information can be found at http://www.opengroup.org/press/7jun99_b.htm

...code
  The stub code is the C++ code that provides the object mapping as defined in the CORBA 2.0 specification.

...defined
  In omniORB2, all object reference variable types are instantiated from the template type _CORBA_ObjRef_Var.

...castings
  However, the implementation of the type conversion operator() between Echo_var and Echo_ptr varies slightly among different C++ compilers, you may need to do an explicit casting when the compiler complains about the conversion being ambiguous.

...Adaptor
  The interface of a BOA is described in chapter 8 of the CORBA specification.

...)
  A conversion operator() of CORBA::String_var converts a CORBA::String_var to a char*.

...string
  Please refer to the CORBA specification 16.7 for the details of the String_var mapping. Other T_var types are also covered in chapter 16.

...argument
  The 1st argument is a pointer to the implementation definition and is always ignored by omniORB2.

...argument
  The CORBA specification does not specify when `impl_is_ready` should return. Many ORB vendors choose to implement `impl_is_ready` as blocking until a certain time-out value is exceeded. In a single threaded implementation this is necessary to give the ORB the time to serve incoming requests.

...reference
  Object references held by clients in other address spaces will not prevent the object implementation from being disposed of. If these clients invoke on the object after it is disposed, the system exception INV_OBJREF is raised.

...space
  Notice that the object key is not globally unique across address spaces.

...condition
  If a system exception is not caught, the C++ runtime will call the `terminate` function. This function is defaulted to abort the whole process and on some system will cause a core file to be produced.

...RTTI
  Run Time Type Identification

...RTTI
  A noticeable exception is the GNU C++ compiler (version 2.7.2). It doesn't support RTTI unless the compilation flag -frtti is specified. The omniORB2 runtime is not compiled with the -frtti flag. It is said that RTTI will be properly supported in the upcoming version 2.8.

...Echo''
  A pathname, or in the Naming Service's terminology- a compound name, is a sequence of textual names. Each name component except the last one is bound to a naming context. A naming context is analogous to a directory in a filing system, it can contain names of object references or other naming contexts. The last name component is bound to an object reference. Note: '/' is purely a notation to separate two components in the pathname. It does not appear in the compound name that is registered with the Naming Service.

...``omniORB''
  omniORB is a class name if the C++ compiler does not support the namespace keyword.

...interface
  This interface is first defined by Sun's NEO and is in used in Sun's JavaIDL

...Format
  For further details of the repository ID formats, see section 6.6 in the CORBA specification.

...purpose
  In pre-omniORB 2.8.0 releases, omniORB2 performs an equality test and will ignore any alias TypeCodes (`tk_alias`) when making this comparison. The semantics is similar to the equivalent() test in the TypeCode interface of CORBA 2.3.

...reference
  Testing a nil DynAny object with CORBA::is_nil() returns TRUE(1). The CORBA 2.2 specification does not specify what is the return value of this function when the current component pointer is invalid. To ensure portability, it is best to avoid calling `current_component()` under this condition.

...exception
  The CORBA 2.2 specification does not define the behavior of this error condition. To ensure portability, it is best to avoid calling the get operations when the current component pointer is known to be invalid.

...exception
  The CORBA 2.2 specification does not define the behavior of this error condition. To ensure portability, it is best to avoid calling the insert operations when the current component pointer is known to be invalid.

...union
  In the CORBA 2.2 specification, the DynFixed interface is defined to handle the fixed data type. This is not supported in this implementation.

...usage
  This interface is currently an open issue with the ORB revision task force.

...CORBA::release()
  if not managed by a `_var` type.

...CORBA::NVList
  obtained by calling `CORBA::ORB::create_list()`