Orber Release Notes

19 Orber Release Notes
19.1 orber 2.0, Release Notes
19.1.1 Improvements and new features

It's now possible to start an corba object with a registered name, this can be a local name known only in the same erlang node or a global name which can be seen in the whole system. This functionality is useful when one is designing application which will be restarted on other nodes when one the first node is going down.
Own Id: OTP-2486

It's now possible to install orber so the Interface Repository uses RAM base mnesia tables instead of disc based.
Own Id: OTP-2484

The IDL compiler has been removed from orber and become it's own application, called ic.
Own Id: OTP-2483

It's now possible to have different Orber nodes talking to each other with IIOP instead of just erlang distribution. This is solved through a configuration parameter called domain. If the server objects object key has a domain name that differs from the senders domain name IIOP is used.
Own Id: OTP-2397

There is now a possibility to have sub objects in an orber object. These sub objects are not distinguishable from ordinary objects from the outside. This functionality can be useful when one just wants one process to handle a number of objects of the same type.
Own Id: OTP-2396

Performance tuning, the calls internal in an erlang node to an orber object is now more efficient. The overhead that Corba adds is minimised so it will especially visible on calls with a small amount of data.
Own Id: OTP-2111

19.1.2 Fixed bugs and malfunctions

A bug in orber_ifr:lookup/2 have been fixed.
Own Id: OTP-2172

The encoding problem with arrays in IIOP is now fixed.
Own Id: OTP-2367

A Marshalling error in the IIOP encoding of any objects corrected. It existed for all the complex types, tk_objref, tk_struct, tk_union, tk_enum, tk_array, tk_sequence tk_alias and tk_exception.
Own Id: OTP-2391

A crash under IFR registration and unregistration when modules with inherited interfaces is now fixed.
Own Id: OTP-2254

19.1.3 Incompatibilities

There are a number of modules which now are prefixed, but object.erl is the only one which is included in the external interface (it is changed to corba_object.erl). The data type "any" is the only module without prefix now.
Own Id: OTP-2305

A hidden field which contains the IFR id in the record definitions will be removed. This will require a regeneration of all IDL specs.
Own Id: OTP-2480

The any type is now represented as a record and not just a two tuple which makes it possible to check the type in guards. The two tuple {<TypeCode>, <Value>} is now defined as: -record(any,{typecode, value}).
Own Id: OTP-2480

IDL unions are represented as erlang records in the same manner as IDL structs which makes it possible to use the names in guards.
Own Id: OTP-2481

The prefix OE_ which has been used on some modules and functions have been changed to oe_.
Own Id: OTP-2440

The corba:create function is renamed to corba:create_link and a new corba:create function have been added. This means that corba:create have changed it's semantics a bit and if the old behaviour is wanted corba:create_link should be used. These functions are now the corba similar to gen_server:start and gen_server:start_link in behaviour.
The IDL compiler now also generates create functions (oe_create and oe_create_link with different number of parameters) in the api module which are more convenient to call than the create functions in the corba module because they have less parameters but does the same thing.
Own Id: OTP-2442

19.1.4 Known bugs and problems
19.1.4.1 ORB

The dynamic interfaces are not supported and won't be in the first release of Orber.

Orber only support the persistent object startup behaviour.

There are a number of function in the boa and corba interfaces that not are implemented but they are mostly used when implementing the ORB and in the stubs and skeletons generated by the IDL compiler and not used by application designers.

19.1.4.2 Interface Repository

The Interface Repository cannot be used from another ORB for the moment.

IFR register corruption when trying to register on already defined id's. This is a problem that appears when trying to call the registration function without unregistering old ifr-objects with the same id's.

19.1.4.3 Resolving initial reference from C++
The returned IOR is correct and the same as for the java implementation but we have for the moment just tested with a client implemented in C++, ie an Orbix C++ client accessing an Orber server.
19.2 Orber 1.0.3, Release Notes
19.2.1 Fixed bugs and malfunctions

Inherited interfaces are now registered correctly in the Interface Repository. This means that object:get_interface/1 now work properly.
Own Id: OTP-2134

The generated function which unregisters IDL specifications from the Interface repository crashed when when modules contained interfaces which inherited other interfaces.
Own Id: OTP-2254

19.2.2 Incompatibilities
One needs to recompile the IDL files to get the inherited interfaces correctly in the IFR register/unregister functions.
19.2.3 Known bugs and problems
19.2.3.1 ORB

The dynamic interfaces are not supported and won't be in the first release of Orber.

Orber only support the persistent object startup behaviour.

There are a number of function in the boa and corba interfaces that not are implemented but they are mostly used when implementing the ORB and in the stubs and skeletons generated by the IDL compiler and not used by application designers.

19.2.3.2 IDL compiler

Defining interface repository identifiers by the use of compiler pragmas is not supported. The ID, version or prefix compiler pragmas are not supported. This is an add on to the standard.

No checks are made to ensure reference integrity. IDL specifies that identifiers must have one and only one meaning in each scope.

Files are not closed properly when the compiler has detected errors. This may result in an emfiles error code from the Erlang runtime system when the maximum number of open files have been exceeded. The solution is to restart the Erlang emulator when the file error occurs.

If inline enumerator discriminator types are used, then the name of the enumeration is on the same scope as the name of the union type. This does not apply to the case where the discriminator type is written using a type reference.

The IFR registration of interface operations does not register any raised exceptions.

When running the type code registration functions (OE_register) for the IFR and have included files the specifications must be registered in the correct order. There is for the moment no check if that have been done which can give some bad registrations, but an unregistered followed by a register of the superior specification will solve it.

19.2.3.3 Interface Repository

The Interface Repository cannot be used from another ORB for the moment.

19.2.3.4 Resolving initial reference from C++
The returned IOR is correct and the same as for the java implementation but we have for the moment just tested with a client implemented in C++, ie an Orbix C++ client accessing an Orber server.
19.3 Orber 1.0.2, Release Notes
19.3.1 Fixed bugs and malfunctions
The idl compiler generated wrong type registration code for the IFR when an IDL specification included another IDL specification. One could get exceptions from the IFR for trying to double register something (for example a module or interface).
Own Id: OTP-2133

Two type errors in internal IDL specified interfaces corrected.
Own Id: OTP-2121, OTP-2122

object:get_interface/1 didn't work properly.
Own Id: OTP-2025
IDL compiler: Error in handle call code generation in server stub. The compiler stopped generating handle_call clauses when there was a ONEWAY function. In the example below there was no code generated for the function h. If the oneway functions were last in the interface definition all worked fine.
interface i {
   short f();
   oneway void g(in char c);
   long h();        
}
          
Own Id: OTP-2057
Badly choosen module name in the IDL example file InitialReferences.idl, the module name is changed from ORBER to Orber.
Own Id: OTP-2069

Documentation error in the description of the IDL mapping to Erlang. The example in chapter 2.7 was wrong.
Own Id: OTP-2108

pull() function in ProxyPullSupplier interface had a wrong return vaue of {Value, BOOL} instead of Value.
Own Id: OTP-2150

'Disconnected' exceptions were missing from calls to ProxyPullSupplier:pull(), ProxyPullSupplier:try_pull() and ProxyPushConsumer:push(). This exception should be thrown in case if communication has been disconnected.
Own Id: OTP-2151
19.3.2 Incompatibilities
One needs to recompile the IDL files to get the corrections in some cases.
There are one incompatibility, the package name for the Java InitialReferences class has been changed. see bugfix id OTP-2069 above.
19.3.3 Known bugs and problems
19.3.3.1 ORB

The dynamic interfaces are not supported and won't be in the first release of Orber.

Orber only support the persistent object startup behaviour.

There are a number of function in the boa and corba interfaces that not are implemented but they are mostly used when implementing the ORB and in the stubs and skeletons generated by the IDL compiler and not used by application designers.

19.3.3.2 IDL compiler

Defining interface repository identifiers by the use of compiler pragmas is not supported. The ID, version or prefix compiler pragmas are not supported. This is an add on to the standard.

No checks are made to ensure reference integrity. IDL specifies that identifiers must have one and only one meaning in each scope.

Files are not closed properly when the compiler has detected errors. This may result in an emfiles error code from the Erlang runtime system when the maximum number of open files have been exceeded. The solution is to restart the Erlang emulator when the file error occurs.

If inline enumerator discriminator types are used, then the name of the enumeration is on the same scope as the name of the union type. This does not apply to the case where the discriminator type is written using a type reference.

The IFR registration of interface operations does not registerany raised exceptions.

When running the type code registration funcctions (OE_register) for the IFR and have included files the specifications must be registered in the correct order. There is for the moment no check if that have been done which can give some bad registrations, but an unregistered followed by a register of the superior specification will solve it.

19.3.3.3 Interface Repository

The Interface Repository cannot be used from another ORB for the moment.

19.3.3.4 Resolving initial reference from C++
The returned IOR is correct and the same as for the java implementation but we have for the moment just tested with a client implemented in C++, ie an Orbix C++ client accessing an Orber server.
19.4 Orber 1.0.1, Release Notes
19.4.1 Fixed bugs and malfunctions

Default count in the Type Kind structs where always -1.
Own Id: OTP-2007

CosNaming::NamingContext::list() returned wrong return value and bad format of out parameters.
Own Id: OTP-2023

corba::string_to_object previously returned an internal structure. This has been remedied and the function now returns an object reference.
Own Id: OTP-2024

19.5 Orber 1.0, Release Notes
19.5.1 Improvements and new features
Orber is a new application which allows OTP applications to interact with other programs written in other languages through the CORBA standard.
The orber release contains the following parts:

Orb kernel and IIOP support

IDL compiler

Interface Repository

Orber CosNaming Service

Orber CosEvent Service (only untyped events)

Resolving initial reference from Java

Resolving initial reference from C++

A small example

Implemented work packages are: OTP-1508, OTP-1509 (not typed event).
19.5.1.1 Orb kernel and IIOP support
There is an ORB kernel with IIOP support which allows creating persistent server objects in erlang and access them from erlang and java. For the moment one need a java enabled Orb to generate java from idl and use java server objects (we have tested with OrbixWeb).
19.5.1.2 IDL compiler
The IDL compiler generates server behaviours and client stubs according to the IDL to Erlang mapping. Interface inheritance is supported. The idl compiler requires gcc because it's used as preprocessor. (It's possible to run the compiler without preprocessor if for example you don't use include statements)
19.5.1.3 Interface Repository
The Interface Repository (IFR) is fully implemented. The module orber_ifr is the interface to it. The IFR is used for some type checking when coding/decoding IIOP and therefore all interfaces must be registered in the IFR.
19.5.1.4 Orber CosNaming service
This is the first version of the CosNaming compliant service which also includes two modules lname and lname_component which supports the naming library interface in erlang.
19.5.1.5 Orber CosEvent Service
Orber contains an Event Service that is compliant with the untyped part of the CosEvent service specification.
19.5.1.6 Resolving initial reference from Java
A class with just one method which returns an IOR on the external string format to the INIT object (see "Interoperable Naming Service" specification).
19.5.1.7 Resolving initial reference from C++
A class (and header file) with just one method which returns an IOR on the external string format to the INIT object (see "Interoperable Naming Service" specification).
19.5.1.8 A small example
A small programming example is contributed which shows how Orber can be used. It is an implementation of a Stack service which shows how erlang services can be accessed from both erlang and java.
19.5.2 Fixed bugs and malfunctions
-
19.5.3 Incompatibilities
-
19.5.4 Known bugs and problems
19.5.4.1 General

Operation attribute oneway is implemented but not tested.

19.5.4.2 ORB

The dynamic interfaces are not supported and won't be in the first release of Orber.

Orber only support the persistent object startup behaviour.

There are a number of function in the boa and corba interfaces that not are implemented but they are mostly used when implementing the ORB and in the stubs and skeletons generated by the IDL compiler and not used by application designers.

19.5.4.3 IDL compiler

Defining interface repository identifiers by the use of compiler pragmas is not supported. The ID, version or prefix compiler pragmas are not supported. This is an add on to the standard.

No checks are made to ensure reference integrity. IDL specifies that identifiers must have one and only one meaning in each scope.

Files are not closed properly when the compiler has detected errors. This may result in an emfiles error code from the Erlang runtime system when the maximum number of open files have been exceeded. The solution is to restart the Erlang emulator when the file error occurs.

If inline enumerator discriminator types are used, then the name of the enumeration is on the same scope as the name of the union type. This does not apply to the case where the discriminator type is written using a type reference.

The IFR registration of interface operations does not registerany raised exceptions.

19.5.4.4 Interface Repository

The Interface Repository cannot be used from another ORB for the moment.

19.5.4.5 Resolving initial reference from C++
The returned IOR is correct and the same as for the java implementation but we have for the moment just tested with a client implemented in C++, ie an Orbix C++ client accessing an Orber server.