DynAnyMigration

DynAny migration

omniORB 4 supports (well, will soon) the DynAny specification from CORBA 2.5. omniORB 2.x and 3.0 supported CORBA 2.2 DynAny. The differences are mainly cosmetic, but this page lists some potential porting hurdles.

The CORBA 2.5 DynAny specification can be found at http://www.omg.org/cgi-bin/doc?formal/01-09-13.

DynAny creation

• The DynAny interfaces and associated definitions now live in module DynamicAny rather than the CORBA module.

• The DynAny creation functions are no longer part of the ORB interface. They now live in the DynAnyFactory interface, found with resolve_initial_references("DynAnyFactory").

• The individual functions to create uninitialised DynAnys from TypeCodes (create_dyn_struct(), create_dyn_sequence(), etc.) have been replaced with the single create_dyn_any_from_type_code() function.

• Empty DynAnys created with a TypeCode are now initialised to a default value, rather than remaining uninitialised.

Reading and writing

• insertion/extraction functions no longer advance the component pointer. You must explicitly call next(). If you have code like

    for (i=0; i < len; i++) {
       s = d->get_short();
       // do something with s
    }
   

  you will find it now repeatedly reads the same value, rather than iterating through the components like it did in omniORB 2/3. You must add a call to next():

    for (i=0; i < len; i++) {
       s = d->get_short();
       // do something with s
       d->next();  
    }
   

  This will be a major source of bugs! Check your code carefully.

• Many boundary conditions that were not specified before are now specified, and have changed from the omniORB 3 implementation. This means exceptions are often different, and some operations that used to succeed now throw exceptions.

• Attributes in DynEnum, DynUnion, DynSequence have been replaced by operations. This means that, for example, DynSequence's length() function has been replaced with get_length() and set_length(len).

• The useful ability to choose a DynUnion member by name no longer exists. You must now explicitly manipulate the discriminator. DynUnion is by far the most changed interface.

• DynAnys containing sequences of base types can now be efficiently accessed with the get_..._seq() and insert_..._seq() functions.