1 Orber Release Notes
1.1 Orber 3.2.9, Release Notes
1.1.1 Improvements and new features
1.1.2 Fixed bugs and malfunctions
- External IOR:s containing unsupported or incorrectly placed TaggedComponents was corrupted when Orber forwarded the IOR via IIOP. This bug was introduced in 3.2.6.
Own Id: OTP-4170
1.1.3 Incompatibilities
1.1.4 Known bugs and problems
- The same as in last release.
1.2 Orber 3.2.8, Release Notes
1.2.1 Improvements and new features
- Orber now support interceptors.
Own Id: -
1.2.2 Fixed bugs and malfunctions
1.2.3 Incompatibilities
1.2.4 Known bugs and problems
- The same as in last release.
1.3 Orber 3.2.7, Release Notes
1.3.1 Improvements and new features
- When Orber acted as server-side and communicating via IIOP the overhead was unreasonably large and memory consuming (depended on the IDL-specification). This have now been fixed and will, especially, improve the performance when invoking operations with no, or simple, arguments on a complex interface. This change will have little effect on objects started as pseudo since this problem did not affect them.
Own Id: OTP-4063
- When Orber tried to set up a connection to another ORB which did not respond all IIOP access where blocked until the TCP protocol generated a timeout. Now only requests to that particular ORB are queued.
Own Id: OTP-4060
1.3.2 Fixed bugs and malfunctions
- It was not possible to invoke the operation CosNaming_BindingIterator:next_one via IIOP if no more bindings existed.
Own id: OTP-4004
1.3.3 Incompatibilities
1.3.4 Known bugs and problems
- The same as in last release.
1.4 Orber 3.2.6, Release Notes
1.4.1 Improvements and new features
- Registering data in the IFR overhead reduced.
Own id: OTP-3904
- The overhead for the function
is_a/1
have been reduced, which also affects remotenarrow
operations for inherited interfaces (e.g. using Java or C++ ORBs).
Own id: OTP-3904
- If the underlying OS was not configured to allow Erlang to lookup the host-name by using the short-name the result was always the IP-adress 127.0.0.1 (loop-back). Now Orber uses the full name. Hence, make sure the
net_adm:localhost/0
andinet:getaddr/2
return proper values.
Own id: OTP-3966
1.4.2 Fixed bugs and malfunctions
- The CONV_FRAME_CodeSetComponentInfo struct was not placed correctly in IOR:s. Each profile must be self-sustained which is why this information must be duplicated in each profile. Currently this only applies for the IIOP-profile but will also concern future protocols.
Own id: OTP-3992
1.4.3 Incompatibilities
1.4.4 Known bugs and problems
- The same as in last release.
1.5 Orber 3.2.5, Release Notes
1.5.1 Improvements and new features
- Orber now defines the configuration variable,
iiop_setup_connection_timeout
, which makes it possible to timeout connection attempts to another ORB before the OS TCP timeout is activated.
Own id: OTP-3961
- It is now possible to configure Orber to generate reports when abnormal situations occurs. For more information consult the User's Guide regarding the configuration parameter
orber_debug_level
. Note, it is not recommended to use this option for delivered systems since some of the reports is not to be considered as errors.
Own id: OTP-3962
- Orber now accepts a list of addresses as value for the configuration parameter
orbInitRef
.
Own id: OTP-3945
- Orber now includes services defined by the configuration parameter
orbInitRef
when invokingcorba:list_initial_services/0
.
Own id: OTP-3946
1.5.2 Fixed bugs and malfunctions
- When using the configuration variable 'orbDefaultInitRef' with a value pointing to another Orber-ORB it was not possible to install Orber since Orber used to create default
NamingContexts
. Orber no longer add these contexts.
Own id: OTP-3943
- Orber accessed
corbaloc
addresses in reverse order. Now fixed.
Own id: OTP-3944
1.5.3 Incompatibilities
- When installing Orber no default
NamingContext's
, i.e.,host
,hosts
,resources
,development
,factories
andworkgroup
, will be added. These contexts was defined in a cancelled specification.
Own id: OTP-3942
corbaloc
adrresses are now accessed in FIFO order (instead of LIFO).
Own id: OTP-3944
1.5.4 Known bugs and problems
- The same as in last release.
1.6 Orber 3.2.4, Release Notes
1.6.1 Improvements and new features
1.6.2 Fixed bugs and malfunctions
- When communicating via IIOP using version 1.2 Orber used incorrect offset for reply bodies containing system exceptions, exceptions and location forward.
Own id: OTP-3912
- Orber did not return correct IFR Id:s when raising system exceptions via IIOP.
Own id: OTP-3911
- If two different processes concurrently manipulated a
CosNaming::NamingContext
the data could become corrupted. For single-node Orber this error occured in version 3.2.1, 3.2.2 and 3.2.3. For multi-node Orber this behaviour have been present at all time.
Own id: OTP-3910
1.6.3 Incompatibilities
- Since Orber now returns a different, and correct, IFR-id for systems exceptions other ORB:s and older versions of Orber might raise a different exception, probably MARSHAL or UNKNOWN. This only occurs when communicating via IIOP. It is not possible to upgrade during runtime. Use
orber:stop()
, load new version and restart Orber by invokingorber:start()
.
Own id: OTP-3911
1.6.4 Known bugs and problems
- The same as in last release.
1.7 Orber 3.2.3, Release Notes
1.7.1 Improvements and new features
- Improved performance for all types, simple and complex, when communicating via IIOP. It is not possible to upgrade during runtime. Use
orber:stop()
, load new version and restart Orber by invokingorber:start()
.
Own id: OTP-3905
1.7.2 Fixed bugs and malfunctions
- If a psuedo object raises an exception or exits the exception was only returned, not thrown.
Own id: OTP-3907
- Orber defined an incorrect ID for CodeSets. This may cause INV_OBJREF or DATA_CONVERSION exceptions to be thrown, it depends on the other ORB.
Own id: OTP-3899
1.7.3 Incompatibilities
1.7.4 Known bugs and problems
- The same as in last release.
1.8 Orber 3.2.2, Release Notes
1.8.1 Improvements and new features
- The behaviour of Orber when receiving unsupported or incorrect messages have now been improved.
Own id: OTP-3903
- Time consumed by
oe_MyModule:oe_register()
decreased.
Own id: OTP-3904
1.8.2 Fixed bugs and malfunctions
- When Orber received a 'location_forward' reply, the result from the second invocation was never delivered to the client. Now fixed.
Own id: OTP-3814
1.8.3 Incompatibilities
1.8.4 Known bugs and problems
- The same as in last release.
1.9 Orber 3.2.1, Release Notes
1.9.1 Improvements and new features
- It is now possible to use external
NamingContexts
when, for example, using'CosNaming_NamingContextExt':bind_context/3
.
Own id: OTP-3902
1.9.2 Fixed bugs and malfunctions
1.9.3 Incompatibilities
1.9.4 Known bugs and problems
- The same as in last release.
1.10 Orber 3.2, Release Notes
1.10.1 Improvements and new features
- Orber now supports IIOP-version 1.2.
Own id: OTP-3901
- Improved encoding and decoding performance for IIOP requests containing
struct
,union
or user definedexceptions
.
Own id: OTP-3900
1.10.2 Fixed bugs and malfunctions
- Setting the
bootstrap_port
configuration parameter to a value less than 1024 made it impossible to start Orber properly. Now fixed.
Own id: OTP-3898
1.10.3 Incompatibilities
1.10.4 Known bugs and problems
- The same as in last release.
1.11 Orber 3.1.8, Release Notes
1.11.1 Improvements and new features
- Orber now accepts
Indirection/Repeated
CORBA::TypeCode
as input and/or return value when communicating via IIOP.
Own id: -
1.11.2 Fixed bugs and malfunctions
- When another ORB replied with
location forward
Orber failed to decode this. Now fixed.
Own id: OTP-3709
- Orber failed to encode
CORBA::TypeCode
containingtk_alias
, e.g., sending an#any{}
which encapsulates data defined bytypedef
.
Own id: OTP-3689
1.11.3 Incompatibilities
1.11.4 Known bugs and problems
- The same as in last release.
1.12 Orber 3.1.7, Release Notes
1.12.1 Improvements and new features
- Earlier, Orber did not use the IIOP/GIOP version specified in an external object key when invoking an intra-ORB request.
Own id: OTP-3663
- The OMG standard now support an Interoperable Naming Service. Initially there where two proposals of which Orber earlier supported one of them. Now both standards are supported.
Own id: OTP-3664
- The OMG have redefined the operator, used when encoding requests via IIOP, for the function
corba_object:non_existent/1
. CORBA version 2.0 and 2.2 compliant ORB:s is supposed to support the old definition, while later versions, i.e., 2.3, is supposed to use the new operator (_non_existent
instead of_not_existent
). Orber accepts both versions.
Own id: OTP-3679
1.12.2 Fixed bugs and malfunctions
- If an Orber node crashed and was restarted the object keys could point to other processes than it should, which may cause problems if, for example, the other process termiantes due to it does not handle unknown messages. Now Orber GC object keys for objects residing on the crashed node. If Orber is started as a multi-node ORB of which one or more nodes runs an older Orber version they can still communicate but with an increased overhead. Hence, all nodes should be upgraded during a relatively short time. If Orber is stopped, i.e., orber:stop() or a shutdown is generated, objects residing on that node will be terminated.
Own id: OTP-3678
- If an IDL-file contains two interfaces of which the first one contains an exception and the second interface, which inherits the first one, contain an operation which raises this exception the IFR failed since multiple references where found when invoking orber_ifr:lookup_id/2. Now fixed.
Own id: OTP-3665
1.12.3 Incompatibilities
- To be able to start Orber as lightweight the mnesia application cannot be listed in the "orber.app" file. You might find it necessary to add 'mnesia' to the applications-list. For example, you cannot upgrade an older version of Orber (not started as lightweight) to this version without adding mnesia to the application dependencies list.
Own id: OTP-3666
- The function
corba_object:non_existent/1
have been updated to follow the CORBA 2.3 standard. Hence, Intra-ORB communication with ORB:s not supporting this standard will fail. The operationcorba_object:not_existent/1
allow users to use the old standard. Consult the ORB vendor's documentation to decide which functio to use.
Own id: OTP-3679
1.12.4 Known bugs and problems
- The same as in last release.
1.13 Orber 3.1.6, Release Notes
1.13.1 Improvements and new features
- Cosmetic update of internal functions.
Own id: -
1.13.2 Fixed bugs and malfunctions
1.13.3 Incompatibilities
1.13.4 Known bugs and problems
- The same as in last release.
1.14 Orber 3.1.5, Release Notes
1.14.1 Improvements and new features
1.14.2 Fixed bugs and malfunctions
- When decoding TypeCode for an object reference, e.g., as a part of an #any{}, Orber failed. This is no longer the case.
Own id: OTP-3631
1.14.3 Incompatibilities
1.14.4 Known bugs and problems
- The same as in last release.
1.15 Orber 3.1.4, Release Notes
1.15.1 Improvements and new features
- The function
start_lightweight/1
have been added to theorber
module. This function allow us to start orber as lightweight without, or override, the configuration parameter-orber lightweight
.
Own id: -
- A new configuration parameter, 'iiop_connection_timeout Secs', is now available. This parameter's purpose, is to terminate the socket connection on the client side if a timespan of Secs seconds have passed. The connection will, however, NOT be terminated if a client still waits for a reply. For the last scenario to happen, the client have been configured to use a larger timeout value than the configuration parameter 'iiop_connection_timeout' have been set to.
Own id: -
- Up until now, invoking an an operation with an extra Timeout parameter (using the IC option: ic:gen(IdlFile, [{timeout,"module::interface"}])), only applied to local Objects. Now, using the IC option above, when compiling the stubs, and adding the extra Timeout parameter, a timeout will also be triggered when calling Objects residing on other ORB:s. The return value, after a timeout has been triggered, have changed from an EXIT message to raising the system exception COMM_FAILURE. For more information, about how this feature interacts with the configuration parameter 'iiop_timeout', consult the documentation.
Own id: -
- When using invalid intra-ORB configuration, i.e., incorrect Port/IP-address, when trying to connect to another ORB, a CRASH REPORT was generated if the configuration parameter '-boot start_sasl' was used. This behaviour has now changed.
Own id: -
1.15.2 Fixed bugs and malfunctions
- If a client-side ORB terminated the IIOP connection immediately there was a possibility that the server responsible detecting this did not.
Own id: OTP-3593
- Setting the configuration parameter 'iiop_timeout' did not result in a correct behaviour, i.e., no timeout triggered.
Own id: OTP-3555
1.15.3 Incompatibilities
- When using the IC option, ic:gen(IdlFile, [{timeout,"module::interface"}]), an EXIT was the timeout result. Now, the system exception COMM_FAILURE is raised.
1.15.4 Known bugs and problems
- The same as in last release.
1.16 Orber 3.1.3, Release Notes
1.16.1 Improvements and new features
1.16.2 Fixed bugs and malfunctions
- Orber did not ignore unrecognized TaggedProfiles. Other vendors may have registered own TAG's with the OMG. These TAG's are valid but not necessarily handled by other vendors.
Own id: OTP-3514
- When passing Object references over IIOP, decoding local references could fail. Now fixed.
Own id: OTP-3515
1.16.3 Incompatibilities
1.16.4 Known bugs and problems
- The same as in last release.
1.17 Orber 3.1.2, Release Notes
1.17.1 Improvements and new features
1.17.2 Fixed bugs and malfunctions
- Previously the OMG have published two suggestions for
Interoperable Name Service
, of which, theCORBA 3
specifyorbos/98-10-11
to be implemented. Unfortunately, the Interoperable Name Service Orber supports, is the one not chosen. Hence, theInitialReferences.idl
will not be according to the future standard. The modules name is now changed fromCORBA
toOrber
. This will affect code which are using this interface. The idl specification must be recompiled and thenCORBA
must be changed toOrber
in the client.
Own id: OTP-3468, OTP-3155
- Now possible to run oe_unregister when the IDL-specification contains exceptions correctly.
Own Id: OTP-3447
- Now possible to run oe_unregister when the IDL-specification contains attributes.
Own Id: OTP-3439
1.17.3 Incompatibilities
The change in
InitialReferences.idl
to clash with the Corba standard implies changes in code that use this interface. See the OTP-3468 and OTP-3155 in theFixed bugs and malfunctions
chapter above.1.17.4 Known bugs and problems
- The same as in last release.
1.18 Orber 3.1.1, Release Notes
1.18.1 Improvements and new features
1.18.2 Fixed bugs and malfunctions
- When introducing the configuration parameter
ip_address
it was no longer possible to have the same default behaviour as before. Now fixed.
Own Id: OTP-3431
- The internal request number handling never checked if maximum reached. Now the counter restart at 0 after reaching max.
Own Id: OTP-3415
- Orber did not handle locate-requests correctly, i.e., not able to recognize the new internal representation of object references.
Own Id: OTP-3414
1.18.3 Incompatibilities
1.18.4 Known bugs and problems
- The same as in last release.
1.19 Orber 3.1, Release Notes
1.19.1 Improvements and new features
- It is now possible to start Orber as lightweight.
Own Id: -
- It is now possible to create pseudo objects, i.e., not server objects.
Own Id: -
- One new system exception introduced; 'BAD_QOS'.
Own Id: -
- Orber now supports the types 'long long' and 'unsigned long long'
Own Id: -
1.19.2 Fixed bugs and malfunctions
- Encoding typecode for complex exceptions (non-empty body) was not done correctly.
Own Id: OTP-3390
- orber_iiop_pm crashed when it received an 'EXIT'. Now fixed.
Own Id: OTP-3391
1.19.3 Incompatibilities
1.19.4 Known bugs and problems
- The same as in last release.
1.20 Orber 3.0.1, Release Notes
1.20.1 Improvements and new features
- Orber is now able to handle upgrade properly.
Own Id: -
1.20.2 Fixed bugs and malfunctions
1.20.3 Incompatibilities
1.20.4 Known bugs and problems
- The same as in last release.
1.21 Orber 3.0, Release Notes
1.21.1 Improvements and new features
- It is now possible to use secure IIOP connections to and from Orber. Orber currently only supports security with the help of SSL and not SECIOP.
Own Id: OTP-1510
- It is now possible to start Orber objects as supervisor childs using Module_Interface:oe_create_link/2 or corba:create_link/4 as the start function.
Own Id: -
- It is now possible to start a Orber object and be able to tell apart if it is in the process of being restarted or has permanently terminated. This is also the reason for introducing
objectkeys_gc_time
configuration parameter.
Own Id: -
- The service CosEvent has been removed from orber and become its own application, called cosEvent.
Own Id: -
- The service CosTransactions is now available as a separate application, called cosTransactions.
Own Id: OTP-1741
- Three new system exceptions, 'TRANSACTION_REQUIRED', 'TRANSACTION_ROLLEDBACK' and 'INVALID_TRANSACTION', introduced. Required by the cosTransactions application.
Own Id: -
- An configuration variable ip_address has been added, so it's possible to listen on a specific ip interface on a multi interface host. The value is the ip address as a string or a tuple of four integers, default value is all interfaces.
Own Id: OTP-3294
1.21.2 Fixed bugs and malfunctions
- set- and get-operations for the 'any'-module now behaves properly.
Own Id: OTP-3355
- Orber can now handle IORs which contain more than one "Tagged Profile".
Own Id: OTP-3266
1.21.3 Incompatibilities
- CosEvent include paths have changed since it is now a separate application, called cosEvent.
- The internal representation of object references have changed. Orber do, however, recognize the old representation. But object references (created by Orber 2.2.2 or older) stored and used through several Orber upgrades may not be supported.
- The functions oe_create/2 and oe_create_link/2 now take an options list as its second argument. Orber still allow oe_create*(Env, {Type,RegName}) to be used, but may not in future releases.
1.21.4 Known bugs and problems
- The same as in last release.
1.22 Orber 2.2.2, Release Notes
1.22.1 Improvements and new features
1.22.2 Fixed bugs and malfunctions
- Allignment error in the IIOP decoding/encoding of doubles fixed.
Own Id: OTP-3185
- Removed a to strict guard on float/double cdr encoding.
Own Id: OTP-3186
- Orber now accepts parallell requests on the same socket.
Own Id: OTP-3198
1.22.3 Incompatibilities
1.22.4 Known bugs and problems
- The same as in last release.
1.23 Orber 2.2.1, Release Notes
1.23.1 Improvements and new features
- In this version of Orber we have added orber:add_node/2 and orber:remove_node/1\ to make it possible to add/remove an Orber node to/from a set of running Orber nodes.
Own Id: OTP-3103
- A global timeout on outgoing IIOP calls have been added as a configuration variable to Orber. It has the name
iiop_timeout
and can be set to a value in seconds. If not set it will have the value infinity.
Own Id: OTP-3151
1.23.2 Fixed bugs and malfunctions
- An error when decoding locate requests from IIOP is fixed.
Own Id: OTP-3149
- There was always a negative response for a locate request on the initial reference (INIT) because of an error in the existence check function. This is now fixed.
Own Id: OTP-3150
InitialReferences.idl
was not according to the standard. The modules name is now changed fromOrber
toCORBA
. This will affect code which are using this interface. The idl specification must be recompiled and thenOrber
must be changed toCORBA
in the client.
Own Id: OTP-3155
1.23.3 Incompatibilities
The change in
InitialReferences.idl
to follow the Corba standard implies changes in code that use this interface. See the OTP-3155 in theFixed bugs and malfunctions
chapter above.1.23.4 Known bugs and problems
1.23.4.1 ORB
- The CORBA dynamic interfaces (DII and DSI) are not supported.
- Orber only supports persistent object startup behaviour.
- There are a number of functions in the BOA and CORBA interfaces that are not implemented but are mostly used only when implementing the ORB, and generating IDL compiler stubs and skeletons. These functions are not used by application designers.
1.23.4.2 Interface Repository
- For the moment, the Interface Repository cannot be used from another ORB.
- IFR will register corruption when trying to register on already defined IDs. This is a problem that appears when trying to call the registration function without unregistering old IFR-objects with the same ID.
1.23.4.3 Resolving initial reference from C++
The returned IOR is the same for both C++ and Java. However, we have only tested on a client implemented in C++. That is an Orbix C++ client accessing an Orber server.
1.24 Orber 2.2, Release Notes
1.24.1 Improvements and new features
- In this version of Orber we have added IIOP 1.1 as default protocol to other ORB's. IIOP 1.0 is still usable but you have to set a configuration variable giop_version to get it. We don't support all the new IIOP types because the IDL compiler is not updated yet, but all the headers are updated so the protocol works.
Own Id: OTP-3092
- The omg.org prefix has been added to CosNaming and CosEvent specifications. This means that the IDL types for these two services now have changed and are incompatible but the names are now according to the CORBA standard.
Own Id: OTP-3093
- A couple of name creation functions have been added to the naming library. These are not in the CosNaming standard but they are easier to use in the Erlang environment. It doesn't matter that they're not standard because the objects in the naming library are just pseodo objects and are never sent to other ORB's. The changes are in the modules lname and lname_component and the functions are described in the reference manual.
Own Id: OTP-3094
1.24.2 Fixed bugs and malfunctions
1.24.3 Incompatibilities
- IIOP 1.1 is now default protocol version but orber can be configured to run 1.0.
- The omg.org prefix which all standard IDL specification must have has been added. This means that CosEvent and CosNaming now have new type names for all their definitions.
1.24.4 Known bugs and problems
1.24.4.1 ORB
- The CORBA dynamic interfaces (DII and DSI) are not supported.
- Orber only supports persistent object startup behaviour.
- There are a number of functions in the BOA and CORBA interfaces that are not implemented but are mostly used only when implementing the ORB, and generating IDL compiler stubs and skeletons. These functions are not used by application designers.
1.24.4.2 Interface Repository
- For the moment, the Interface Repository cannot be used from another ORB.
- IFR will register corruption when trying to register on already defined IDs. This is a problem that appears when trying to call the registration function without unregistering old IFR-objects with the same ID.
1.24.4.3 Resolving initial reference from C++
The returned IOR is the same for both C++ and Java. However, we have only tested on a client implemented in C++ ie.an Orbix C++ client accessing an Orber server.
1.25 Orber 2.1, Release Notes
1.25.1 Improvements and new features
In this version of Orber we have added IIOP 1.1, not all types but the protocol headers should be handled correct. IIOP 1.0 is still the default protocol so orber is fully compatible with previous version, but in OTP R5A IIOP 1.1 will be default protocol (it will be possible to configure the system for 1.0).
1.25.2 Fixed bugs and malfunctions
- Orber now handles the functions _is_a and _not_existent over IIOP.
Own Id: OTP-2230
- A new function orber:uninstall/0 is added so one can clean up an orber installation.
Own Id: OTP-3027
- Orber has an improved error message if orber:start is run before orber:install.
Own Id: OTP-3028
1.25.3 Incompatibilities
1.25.4 Known bugs and problems
1.25.4.1 ORB
- The CORBA dynamic interfaces (DII and DSI) are not supported.
- Orber only supports persistent object startup behaviour.
- There are a number of functions in the BOA and CORBA interfaces that are not implemented but are mostly used only when implementing the ORB,and generating IDL compiler stubs and skeletons. These functions are not used by application designers.
1.25.4.2 Interface Repository
- For the moment, the Interface Repository cannot be used from another ORB.
- IFR will register corruption when trying to register on already defined IDs. This is a problem that appears when trying to call the registration function without unregistering old IFR-objects with the same ID.
1.25.4.3 Resolving initial reference from C++
The returned IOR is the same for both C++ and Java. However, we have only tested on a client implemented in C++ ie.an Orbix C++ client accessing an Orber server.
1.26 Orber 2.0.2, Release Notes
1.26.1 Improvements and new features
1.26.2 Fixed bugs and malfunctions
- Communication problems under NT, caused by erranous closing of a socket when using long version of hostname when accessing a remote NameService.
Own Id: OTP-2757
- Hangings related to orber usage, caused by erranous closing of a socket when using long version of hostname when accessing a remote NameService.
Own Id: OTP-2758
- Private fields - CORBA objects. This was just an error in the example code for the stack client.
Own Id: OTP-2859
1.26.3 Incompatibilities
1.26.4 Known bugs and problems
1.26.4.1 ORB
- The CORBA dynamicinterfaces (DII and DSI) are not supported.
- Orber only supports persistent object startup behaviour.
- There are a number of functions in the BOA and CORBA interfaces that are not implemented but are mostly used only when implementing the ORB,and generating IDL compiler stubs and skeletons. These functions are not used by application designers.
1.26.4.2 Interface Repository
- For the moment, the Interface Repository cannot be used from another ORB.
- IFR will register corruption when trying to register on already defined IDs. This is a problem that appears when trying to call the registration function without unregistering old IFR-objects with the same ID.
1.26.4.3 Resolving initial reference from C++
The returned IOR is the same for both C++ and Java. However, we have only tested on a client implemented in C++ ie.an Orbix C++ client accessing an Orber server.
1.27 Orber 2.0.1, Release Notes
1.27.1 Improvements and new features
1.27.2 Fixed bugs and malfunctions
- The application environment variable domain in orber can now be sent as an atom when starting the Erlang node. Example: erl -orber domain Name
Own Id: OTP-2745
- An error in Orber iwhich resulted in a crash when an exception was sent over IIOP is fixed.
Own Id: OTP-2931
- Problems in C++ with narrow of initial reference returned by the InitialReference class fixed. Both the C++ and Java implementations of the InitialReference class used the ` old module name ORBER instead of Orber. OrbixWeb (java) worked anyway but Orbix (C++) got an exception.
Own Id: OTP-2935
1.27.3 Incompatibilities
1.27.4 Known bugs and problems
1.27.4.1 ORB
- The dynamic interfaces are not supported and won't be in the first release of Orber.
- Orber only supports persistent object startup behaviour.
- There are a number of functions in the BOA and CORBA interfaces that are not implemented but are mostly used only when implementing the ORB,and generating IDL compiler stubs and skeletons. These functions are not used by application designers.
1.27.4.2 Interface Repository
- For the moment, the Interface Repository cannot be used from another ORB.
- IFR will register corruption when trying to register on already defined IDs. This is a problem that appears when trying to call the registration function without unregistering old IFR-objects with the same ID.
1.27.4.3 Resolving initial reference from C++
The returned IOR is the same for both C++ and Java. However, we have only tested on a client implemented in C++ ie.an Orbix C++ client accessing an Orber server.
1.28 orber 2.0, Release Notes
1.28.1 Improvements and new features
- It is 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 is 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 its own application, called ic.
Own Id: OTP-2483
- It Is 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
1.28.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
1.28.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 its 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
1.28.4 Known bugs and problems
1.28.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.
1.28.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.
1.28.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.
1.29 Orber 1.0.3, Release Notes
1.29.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
1.29.2 Incompatibilities
One needs to recompile the IDL files to get the inherited interfaces correctly in the IFR register/unregister functions.
1.29.3 Known bugs and problems
1.29.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.
1.29.3.2 IDL compiler
- Defining interface repository identifiers by the use of compiler pragmas is not supported. The
ID
,version
orprefix
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.
1.29.3.3 Interface Repository
- The Interface Repository cannot be used from another ORB for the moment.
1.29.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.
1.30 Orber 1.0.2, Release Notes
1.30.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
1.30.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.
1.30.3 Known bugs and problems
1.30.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.
1.30.3.2 IDL compiler
- Defining interface repository identifiers by the use of compiler pragmas is not supported. The
ID
,version
orprefix
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.
1.30.3.3 Interface Repository
- The Interface Repository cannot be used from another ORB for the moment.
1.30.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.
1.31 Orber 1.0.1, Release Notes
1.31.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
1.32 Orber 1.0, Release Notes
1.32.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).
1.32.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).
1.32.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)
1.32.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.1.32.1.4 Orber CosNaming service
This is the first version of the CosNaming compliant service which also includes two modules
lname
andlname_component
which supports the naming library interface in erlang.1.32.1.5 Orber CosEvent Service
Orber contains an Event Service that is compliant with the untyped part of the CosEvent service specification.
1.32.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).
1.32.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).
1.32.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.
1.32.2 Fixed bugs and malfunctions
1.32.3 Incompatibilities
1.32.4 Known bugs and problems
1.32.4.1 General
- Operation attribute
oneway
is implemented but not tested.
1.32.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.
1.32.4.3 IDL compiler
- Defining interface repository identifiers by the use of compiler pragmas is not supported. The
ID
,version
orprefix
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.
1.32.4.4 Interface Repository
- The Interface Repository cannot be used from another ORB for the moment.
1.32.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.