This is the omniORB FAQ page. It is in fact a wiki page. You can add your own Q&A to this page by clicking the Edit link at the bottom. Please help to make this FAQ better by extending it.

Please do not just add questions here! This page is for answers to questions.

TableOfContents

General Information

Q. What is omniORB?

omniORB is a robust, high-performance, multi-threaded CORBA 2 ORB, originally developed by Olivetti Research Ltd. (which later became AT&T Laboratories Cambridge). It is freely available under the GNU public licences. The native transport is IIOP, and it comes complete with a COS Naming Service. It supports C++ and Python language bindings.

Q. What is the current release of omniORB?

The current stable releases are omniORB 4.2.0 and omniORBpy 4.2.0.

Q. Where do I get the latest releases?

The latest release is available here. Between two public releases, you can keep up-to-date using Subversion.

Q. Is omniORB available on platform X?

omniORB is available on many platforms. A summary of some platforms it is known to run on:

If your platform is not listed, there is still a good chance it is supported. Most Unix platforms work with no problems just by running the Autoconf configure script.

Q. What do I need to build omniORB?

To build omniORB, you need:

Q. Are omniORB RPMs available?

Thomas Lockhart has made RPMs for omniORB and omniORBpy. Thomas builds the RPMs for Mandrake Linux, and Sander Steffann/opensource.nederland.net builds them for RedHat Linux. These sites mirror each other, so all packages should be available on both sites.

Q. Can I use omniORB in a commercial application?

Short answer: yes.

Longer answer:

The libraries in omniORB are released under the LGPL license. This means that you may use them in a commercial application, without having to release the source code to your application. You must, however, either provide or offer to provide the source to omniORB, along with the binaries you distribute. If you modify omniORB in any way, you must make your modifications to it available.

Application code that uses omniORB's headers is never considered a derived work of those headers, even when invoking long inline functions.

Q. On Windows, my omniORB program crashes with a crtIsValidHeapPointer exception. Why?

There are several versions of Microsoft's C/C++ runtime library, which contains the standard memory allocation/deallocation functions. If your application code uses a different runtime library than the omniORB DLLs, you will run into trouble. You may see crtIsValidHeapPointer error reports (if using a debug versions of the runtime library), or you may just experience random memory corruption potentially resulting in a process crash.

To ensure that the omniORB libraries are using the same C/C++ runtime library as your application:

Q. Is a Java version of omniORB available?

There is no Java version of omniORB available. However, omniORB is known to interoperate well with various Java ORBs.

Q. Does omniORB support the POA?

Yes, the POA has been supported since version 3.0.0.

Q. Can I still use my old BOA servers with new POA clients?

Yes, your old BOA servers will still work with new clients.

If you wish to recompile your servers and do not wish to modify them to use the POA, then read section 3.2 ("BOA compatibility") of the omniORB manual for advice and caveats.

Q. If I only ever want to use C++, do I have to use Python?

Python is used internally by omniidl, the omniORB IDL compiler. You do not need to write any Python code to use C++. Your final compiled application (and associated libraries) will be totally independent of Python code. Be sure to follow the appropriate installation/ building instructions carefully and all should be well.

Q. Is omniORB going to support Interceptors?

omniORB 4.x has interceptors, but not the Portable Interceptors API.

Q. I want to add a new transport to omniORB. Is there a defined interface to do so?

For omniORB 4.x, see transport.txt in src/lib/omniORB/orbcore/ , although note that the file is somewhat out of date.

Q. omniORB is a very efficent ORB. Is there any documentation on how this is achieved?

A technical report "The Implementation of a High Performance ORB over Multiple Network Transport" is available. This paper describes the design experience to achieve high performance. A slightly different version was presented at Middleware 98.

A technical report "The Implementation of a Native ATM Transport for a High Performance ORB" is available. This paper describes a lightweight, user space transport protocol that has been tailored for running GIOP over ATM AAL5 or similar network protocols.

Q. Does omniORB support SSL for encryption?

omniORB 4.x supports SSL.

Q. I'm new to CORBA, where can I learn more?

A great resource is a free online book CORBA Explained Simply by Ciaran McHale.

For a high-level introduction to CORBA, check out OMG's CORBA FAQ. For details, all the information you need is available in the CORBA Specification and the relevant IDL language mapping (C++, Python).

The book by Henning and Vinoski, "Advanced CORBA Programming with C++", is pretty much the standard textbook for learning CORBA.

Configuration Questions

Q. How can I set up omniNames to run as a Windows service?

In omniORB 4.1.2 and later, omniNames can run natively as a Windows service. See the omniNames documentation for details.

Q. How can I get javaIDL to use omniNames?

javaIDL accepts two ORB initialisation options: ORBInitialHost and ORBInitialPort. This instructs the ORB to use a bootstrap protocol to obtain the initial reference of CORBA services. omniNames supports this protocol. So if omniNames is running on machine wobble at port number 1234, one can run a javaIDL client with the options -ORBInitialHost wobble -ORBInitialPort 1234. The client would import the root context of omniNames automatically.

In omniORB 4.x, the Sun bootstrap agent is disabled by default. Set the supportBootstrapAgent parameter to true to enable it.

Problems

Q. In my IDL file, I use two identifiers which differ only in case, e.g. unit and Unit, omniidl complains that this is an error. Why?

Identifiers in IDL are not case sensitive. Therefore unit and Unit are treated as one identifier. A common mistake is to have the argument type and name in an operation differs only in case, e.g. void op(in Unit unit). This is wrong because the argument name clashes with its type. Identifiers in IDL are case insensitive to ensure that IDL can be mapped to a language that ignores the case of identifiers.

Q. I get an obscure error message from the g++ compiler when I try to access an array member.

The message I got came from a line of code that said simply:

and the error message was: CoRCCClient.cc:92: choosing `T& _CORBA_Array_Fix_Var<T_Helper,

CoRCCClient.cc:92: because worst conversion for the former is better than

This is not the most informative message. For technical reasons, it is part of the CORBA C++ binding that array indices """must""" be unsigned. Just change "int" to "unsigned int" in the variable declaration.

Compiling the source

Q. I get lots of unresolved symbols when linking omniORB applications using MS Visual C++

There is a bug in Visual C++ which causes unnecessary references to a few functions in omniDynamic41_rt.dll even though they are definitely not required. This problem typically manifests itself with errors of the form:

test.obj : error LNK2001: unresolved external symbol "public: __thiscall CORBA::TypeCode_member::~TypeCode_member(void)"
(??1TypeCode_member@CORBA@@QAE@XZ)
nodeidsk.obj : error LNK2001: unresolved external symbol "public: __thiscall CORBA::TypeCode_member::~TypeCode_member(void)"
(??1TypeCode_member@CORBA@@QAE@XZ)

This problem has been discussed on the mailing list, see here for solutions/ work arounds.

Q. How do I compile the source on Windows?

The omniORB source tree requires the gnu-win32 utilities from Cygnus Solutions to build. A step-by-step guide can be found in the file README.win32.txt.

CommonCygwinBuildIssues

Q. I get an ArrayIndexOutOfBounds exception when I try to use omniNames from JavaIDL. Why?

The ORB that comes with JDK 1.3 has a bug that means it cannot cope with the object key in an INS compliant root NamingContext, if the Naming service is running on the same machine as the Java client. The bug is supposedly fixed in JDK 1.4 and later. The best solution is to use a different Java ORB.

See http://developer.java.sun.com/developer/bugParade/bugs/4351366.html for Sun's bug page.

Q. If I only want the multi-thread part of omniORB, what parts of the source do I need? Do I then need Python and gnu-win32 utilities?

The omnithread library lives in include/omnithread.h, include/omnithread/* and src/lib/omnithread/*. To compile it with our make files you do not need Python, but you do need the gnu-win32 utilities (on Windows). The library is simple enough that it would be easy to write make files for other build systems for it.

FrequentlyAskedQuestions (last edited 2014-04-28 21:13:57 by DuncanGrisby)