ace/tao faq
Stone Jiang
last updated on: 1/31/2006
Send updates, additions, and corrections to f...@ociweb.com
| |||||||||||||||
Q: |
What is this FAQ about? | ||||||||||||||
A: |
This is a FAQ for The ACE ORB (TAO), an open-source CORBA-compliant ORB born of research at Washington University in St. Louis' Center for Distributed Object Computing (
http://ace.cs.wustl.edu). If your question isn't answered here, you might want to check out the following links:
We at OCI provide commercial-grade support for this ORB, along with documentation and consulting services (see our web page at http://www.ociweb.com for more details), and provide the site and content of this FAQ as a free service to the TAO community. If you have questions, and especially if you have answers to them, please send them to sup...@ociweb.com for inclusion in this FAQ! Let us know whether you'd like to be credited with the answer and, if so, how. | ||||||||||||||
Q: |
Where can I find the source code for the examples in the TAO Developer's Guide?; | ||||||||||||||
A: |
The source code for all the examples in recent versions of the OCI TAO Developer's Guide is available in the OCI TAO source code distribution, itself. See ACE_wrappers/TAO/DevGuideExamples/
. For older versions of TAO and the TAO Developers' Guide, the source code for the examples can be downloaded from our web site. See http://www.theaceorb.com/downloads/index.html
for more details. | ||||||||||||||
Q: |
What is the best way to start learning CORBA and TAO ? | ||||||||||||||
A: |
BooksAdvanced CORBA Programming with C++ book by Henning and Vinoski. It's the equivalent of the ACE tutorial (except it's much more complete). This is a general C++ CORBA book and covers the standard way of doing things. OnlineThe C++ Report and CUJ columns that Vinoski and Schmidt wrote over the past 4 years. They are all online at http://www.cs.wustl.edu/~schmidt/report-doc.html . TrainingDoug Schmidt teaches a course at UCLA Extension. See http://www.cs.wustl.edu/~schmidt/UCLA.html for more details. TutorialsYou can build TAO and work through the online tutorials in | ||||||||||||||
Q: |
What's the relationship between OCI's TAO and DOC's TAO? | ||||||||||||||
A: |
The short answer is that OCI releases OCI's TAO, and the DOC Group releases DOC's TAO. DOC releases beta kits every few weeks, while OCI puts out a release at most twice annually. OCI's release is based on a DOC Group release, but doesn't correspond exactly to an exact DOC Group release. DOC release numbers are
X.Y.Z, where X, Y, and Z are all integers, while OCI numbers them X.Yq where X and Y are integers and 'q' is a lowercase letter.
OCI's release represents a stable, fully-tested, product for which commercial support is available. Many organizations desire a commercially-supported release of TAO as a basis for their application development. The long answer is that the DOC Group (http://www.cs.wustl.edu/~schmidt/doc-group.html ) is a research group, not a product group. It, therefore, treats its source more like research than product. Often, bug fixes and feature enhancements are combined into a single release or beta kit, and occasionally even into a single commit. This facilitates rapid progress, but occasionally occurs at the expense of stability. Its distributions are solely in the form of source code, and, while the DOC Group often provides excellent support, it doesn't guarantee any support. OCI selects, with the DOC Group's assistance, some release (either a release or a beta kit) generally considered to be "reasonably stable". OCI then begins its release cycle, building and testing on its build platforms (over 30 combinations of hardware, operating systems, and C++ compilers). As it encounters bugs, it does one of the following:
In addition, OCI applies various enhancements, sponsored by our customers. We also integrate these back into the DOC group repository. OCI then packages up select binaries (custom builds available -- see http://www.theaceorb.com/product/index.html) and makes them available for purchase on CD-ROM. OCI also distributes its source free of charge (see http://www.theaceorb.com/downloads). An Example: | ||||||||||||||
Q: |
What's a PRF? | ||||||||||||||
A: |
"PRF" refers to the PROBLEM-REPORT-FORM, i.e., $ACE_ROOT/PROBLEM-REPORT-FORM. This boilerplate document is found in both DOC distributions and OCI distributions.
The odds of getting questions answered, bugs fixed, etc., goes up significantly when you report problems using the PRF because it insures that developers and support personnel get the most commonly required information right away. Failure to use the PRF means that those folks have to spend valuable time (yours and theirs) having a conversation to get that information just to start debugging. Unless you've got a paid support contract, there's even a chance that nobody will answer! So, always use the PRF! | ||||||||||||||
Q: |
I want to ask a question about TAO; what can I do? | ||||||||||||||
A: |
See ACE+TAO Mailing lists for a full description of all the available ACE and TAO mailing lists. Please remember to use the Problem Report Form (See
What's a PRF?) when posting questions (and not just "problems"). | ||||||||||||||
| |||||||||||||||
Q: |
How do I obtain, configure, and build OCI's Distribution of ACE and TAO on Windows? | ||||||||||||||
A: |
This FAQ provides basic instructions for installing and building OCI's Distribution of TAO, version 1.4a, for Windows. ACE+TAO can also be used on other major modern operating systems, such as Linux, Solaris, HP-UX, AIX, and Tru64, and some real-time and embedded operating systems, such as VxWorks, LynxOS, Timesys Linux, and Windows CE.
Hardware Requirements
- CPU Speed: Intel x86 P3 500 MHz or faster
- Memory: 512 MB (more memory improves compile speed)
- Hard Drive Space: 256MB swap + 250 free MB
Operating System Requirements
- Windows 2000, 2003, or XP
C++ Compiler Requirements
- Microsoft Visual C++ 6.0 SP5 or 7.1 (NOT 7.0)
Other Software Requirements
- OCI TAO 1.4a latest patch release (see instructions below for
obtaining and installing OCI TAO)
- WinZIP or similar tool for extracting software archives
- ActiveState Perl v5.6.1 or newer (recommended, but not required)
Obtaining and Installing OCI TAO
1. Download the latest patch release of OCI TAO 1.4a from:
http://download.ociweb.com/TAO-1.4a/ACE+TAO-1.4a_with_latest_patches.zip
2. Extract the above archive into a path with no spaces in the path
name (e.g., C:\ACE_wrappers).
3. Set ACE_ROOT, TAO_ROOT, and PATH environment variables.
For example, if ACE+TAO are installed in C:\ACE_wrappers, the
variables will look like this:
* ACE_ROOT=C:\ACE_wrappers
* TAO_ROOT=%ACE_ROOT%\TAO
* The PATH variable should contain these directories: %ACE_ROOT%\bin;%ACE_ROOT%\lib
4. Create a file named config.h in %ACE_ROOT%\ace with the following
contents:
#define ACE_DISABLE_WIN32_ERROR_WINDOWS
#define ACE_HAS_STANDARD_CPP_LIBRARY 1
#define ACE_DISABLE_WIN32_INCREASE_PRIORITY
#include "ace/config-win32.h"
5. If you are using Visual C++ 6.0, build the Win32 Debug
configuration of ACE+TAO using the following workspace file:
%TAO_ROOT%\TAOACE.dsw
The projects in the TAOACE workspace build the ACE and TAO
libraries, TAO IDL compiler, gperf, ORB services libraries and
executables, and some common utilities. Libraries will be
installed in %ACE_ROOT%\lib. Some executables will be installed
in %ACE_ROOT%\bin, others (the ORB services executables) will be
installed in their source directories.
If the above file does not exist, you will need to generate it
using MakeProjectCreator (MPC) (requires Perl as listed above)
with the following commands:
cd %TAO_ROOT%
%ACE_ROOT%\bin\mwc.pl -type vc6 TAOACE.mwc
6. If you are using Visual C++ 7.1, build the Debug configuration of
ACE+TAO using the following solution file:
%TAO_ROOT%\TAOACE.sln
The projects in the TAOACE solution build the ACE and TAO
libraries, TAO IDL compiler, gperf, ORB services libraries and
executables, and some common utilities. Libraries will be
installed in %ACE_ROOT%\lib. Some executables will be installed
in %ACE_ROOT%\bin, others (the ORB services executables) will be
installed in their source directories.
If the above solution file does not exist, you will need to
generate it using MakeProjectCreator (MPC) (requires Perl as
listed above) with the following commands:
cd %TAO_ROOT%
%ACE_ROOT%\bin\mwc.pl -type vc71 TAOACE.mwc
| ||||||||||||||
Q: |
How do I obtain, configure, and build OCI's Distribution of ACE and TAO on Linux? | ||||||||||||||
A: |
This FAQ provides basic instructions for installing and building OCI's Distribution of TAO, version 1.4a, for Linux. ACE+TAO can also be used on other major modern operating systems, such as Windows, Solaris, HP-UX, AIX, and Tru64, and some real-time and embedded operating systems, such as VxWorks, LynxOS, Timesys Linux, and Windows CE.
Hardware Requirements
- CPU Speed: Intel x86 P3 500 MHz or faster
- Memory: 512 MB (more memory improves compile speed)
- Hard Drive Space: 256MB swap + 250 free MB
Operating System Requirements
- Linux 2.2 (or later) kernel
C++ Compiler Requirements
- gcc 3.2.x (or later)
Other Software Requirements
- OCI TAO 1.4a latest patch release (see instructions below for
obtaining and installing OCI TAO)
- GNU gunzip and GNU tar for extracting software archives
- GNU make
- Perl v5.6.1 or newer (recommended, but not required)
Obtaining and Installing OCI TAO
1. Download the latest patch release of OCI TAO 1.4a from:
http://download.ociweb.com/TAO-1.4a/ACE+TAO-1.4a_with_latest_patches.tar.gz
2. Extract the above archive into a path with no spaces in the path
name (e.g., /opt/ACE_wrappers)
3. Set ACE_ROOT, TAO_ROOT, PATH, and LD_LIBRARY_PATH environment
variables.
For example, if ACE+TAO are installed in /opt/ACE_wrappers,
the variables will look like this:
* ACE_ROOT=/opt/ACE_wrappers
* TAO_ROOT=$ACE_ROOT/TAO
* PATH will include the directory $ACE_ROOT/bin
* LD_LIBRARY_PATH will include the directory $ACE_ROOT/lib
4. Create a file named config.h in $ACE_ROOT/ace with the following
contents:
#include "ace/config-linux.h"
5. Create a file named platform_macros.GNU in
$ACE_ROOT/include/makeinclude with the following contents:
exceptions=1
inline=1
ami=1
rt_corba=1
interceptors=1
interface_repo=1
corba_messaging=1
probe=0
profile=0
fakesvcconf=0
shared_libs_only=1
debug=1 # (or debug=0)
optimize=0 # (or optimize=1)
include $(ACE_ROOT)/include/makeinclude/platform_linux.GNU
6. Build ACE+TAO using the following commands:
cd $TAO_ROOT
make
The above commands will build the ACE and TAO libraries, TAO IDL
compiler, gperf, ORB services libraries and executables, and some
common utilities. Libraries will be installed in $ACE_ROOT/lib.
Some executables will be installed in $ACE_ROOT/bin, others (the
ORB services executables) will be installed in their source
directories.
7. If there are no GNUmakefiles, you will need to generate them
using MakeProjectCreator (MPC) (requires Perl as listed above)
with the following commands:
cd $TAO_ROOT
$ACE_ROOT/bin/mwc.pl -type gnuace TAOACE.mwc
| ||||||||||||||
| |||||||||||||||
Q: |
What's the advantage to buying OCI's Distribution of TAO? | ||||||||||||||
A: |
Depending upon your circumstances, there may be several advantages to buying OCI's Distribtution of TAO rather than closely tracking the beta source code kits:
| ||||||||||||||
Q: |
Does the OCI documentation set include the CD, too? | ||||||||||||||
A: |
No, it does not. The documentation set only includes OCI's own TAO Developer's Guide. CDs containing prebuilt versions of TAO for multiple platforms are available separately. |
||||||||||||||
Q: |
If I install TAO from the OCI CD set, do I need to build it? | ||||||||||||||
A: |
In addition to the full source code for ACE and TAO, the OCI CD set includes pre-built libraries for ACE, TAO, and TAO's CORBA services, plus executables for TAO's IDL compiler, gperf, and servers for the various services.
The CD set contains these pre-built components for many popular platforms, operating systems, and C++ compilers. In addition, the builds on the CD set include more than one build configuration (i.e., debug on or off, native C++ exception support on or off). Note that the CD set does not include pre-built binaries of the various tests, performance tests, and examples that come with ACE and TAO, but the full source code for them is there. So, if you install TAO from the OCI CD set for one of the existing platform / operating system / compiler combinations, you can get started writing, building, and running your own applications that use TAO right away. Of course, since you have the full source code, you can custom build it yourself (e.g., for a particular platform, operating system, compiler, or configuration which is not present on the CD). | ||||||||||||||
Q: |
Are the Table of Contents and Index for the TAO Developer's Guide available on-line? | ||||||||||||||
A: |
Yes.
The Table of Contents and Index for OCI's TAO Developer's Guide are available in PDF form via: http://www.theaceorb.com/downloads/1.4a/index.html Just follow the appropriate links to download the files you want. | ||||||||||||||
Q: |
Is it possible to install debug and release versions of TAO on the same NT machine? | ||||||||||||||
A: |
It is possible to install both debug and release versions of TAO on one NT machine by selecting a different installation directory for each installation and setting $ACE_ROOT and $TAO_ROOT appropriately. More efficienty, the debug and release versions of TAO can be installed in the same directory since the different versions of the libraries have slightly different names.
| ||||||||||||||
Q: |
I get a font error during installation using the TAO 1.1 CD, what can I do? | ||||||||||||||
A: |
While this problem may exist on other platforms, we've only seen it trying to perform an installation from CD on Redhat 6.1. The problem will be fixed for the next release.
If you get this error message when starting the installation setup script: font "" doesn't exist at /tmp/tkfiles.12950/perl/Tk/Widget.pm line 171. at /mnt/cdrom/_setup//window.pl line 116You must use command line options to install TAO from the OCI TAO Distribution CD. Running 'setup -h' will show a list of options like this: Usage: setup [options...]
-b = Builds
buildtag, staticlibs
Where possible values for buildtag are:
il6e11a, il6e11b, il6e11c, il6e11d, is57e11a,
is57e11b, is57e11c, is57e11d, iw40v50a,
iw40v50b, iw40v50c, iw40v60a, iw40v60b,
iw40v60c, ph11h39a, ph11h39b, ph11h39c,
ph11h39d
-e = Do not show the gui and begin installation.
-f = Do not prompt about disk space (non-gui only).
-h = Show this help.
-i = Install Directory
ace_root, fullsourcecodedistribution, includefilesonly
-r = Read in the specified configuration file.
-t = TAO Services
cosevent, event, implrepo, lifecycle, naming,
scheduling, time, trading
-u = Allow the use of Tk on unsupported platforms.
NOTE: All option arguments can be shortened to 3 letters. Boolean name value pairs default to 1 (true). To turn
something off use 0 (false).
ex. setup -b buildtag=il6e11a -i ace_root=/ace -b static \
-t eve=0 -t impl=1
setup -b buildtag=ph11h39b -i ace_root=/home/jim/ace \
-i inc=1 -t life=1
The -e option will be required to bypass all graphical interfaces. setup -b buildtag=il6e11c -e -i ace_root=/usr/local/ACE_wrappers -i fullLook in the zips directory for a description of the builds. Each build has a .dat file which lists the different attributes associated with the compressed build. | ||||||||||||||
Q: |
Why is the TAOd.dll library I install from OCI's CD so large? | ||||||||||||||
A: |
The DLLs on the CD include all the information you need to debug TAO applications. This information is normally stored by Visual C++ in .pdb files. Our builds store them in the .dll in a location independent manner (using the C7 compatible option for the debug information). This allows you to step into TAO code in the Visual C++ debugger.
If you desire a smaller set of libraries, either install the release versions of the CD or rebuild the debug libraries with the default debug configuration. | ||||||||||||||
Q: |
How do I get support from OCI? | ||||||||||||||
A: |
You're always welcome to send a question. However, the disposition of your request depends upon whether or not you have a technical support contract with OCI:
| ||||||||||||||
Q: |
Which platforms (hardware/OS combinations) are supported by OCI for TAO 1.2a? | ||||||||||||||
A: |
A full list of platforms (and other support details) is available at http://www.theaceorb.com/support/index.html. | ||||||||||||||
| |||||||||||||||
Q: |
I'm having weird problems with the Naming Service; how can I solve them? | ||||||||||||||
A: |
More than likely you're having problems related to multicast discovery of the naming service, the default in all versions of TAO prior to 1.2a. Symptoms range anywhere from clients not being able to find the naming service, to it finding it sometimes, to just completely bizarre and inexplicable behavior.
So, before you do anything, try it all again, but this time turn off multicast discovery. See How do I locate the naming service server without multicast?. | ||||||||||||||
Q: |
How do I locate the naming service server without multicast? | ||||||||||||||
A: |
Here are some common ways to use the -ORBInitRef option to locate the Naming Service server (where bart is just an example host name):
# Store the IOR of the Naming Service server's root naming context in a file: Naming_Service -m 0 -o /tmp/ns.ior client -ORBInitRef NameService=file:///tmp/ns.ior# Specify an IIOP endpoint when you start the Naming Service server (using TAO 1.1.10 and later): Naming_Service -m 0 -ORBEndpoint iiop://bart:2809 client -ORBInitRef NameService=corbaloc:iiop:bart:2809/NameService# Specify an IIOP endpoint when you start the Naming Service server (using TAO 1.1.9 and before): Naming_Service -m 0 -ORBEndpoint iiop://bart:2809 client -ORBInitRef NameService=iioploc://bart:2809/NameService You can also use the NameServiceIOR environment variable to achieve the same effect. Here, we show what it might look like on a UNIX or UNIX-like system using the Naming_Service -m 0 -ORBEndpoint iiop://bart:2809 export NameServiceIOR=corbaloc:iiop:bart:2809/NameServiceNow, when your client calls resolve_initial_references("NameService"), no multicast will be performed. The -m 0 option turns multicast off in the Naming_Service server. This is the default in TAO versions
1.1.17 and later. Earlier versions defaulted to multicast enabled in the server. | ||||||||||||||
Q: |
Why is multicast discovery of the Naming Service failing? | ||||||||||||||
A: |
There can be a myriad of reasons, many related to network or OS-level issues rather than TAO. Try turning on -ORBDebugLevel 5 to get some sense of what might be happening internally.
If you're using NT, check out Why doesn't using the Naming Service with Multicast work? and see if it applies. | ||||||||||||||
Q: |
Is the Naming Service server's object reference "persistent?" | ||||||||||||||
A: |
Yes, TAO's implementation of the OMG Naming Service always creates a persistent IOR for the root naming context. That is to say, it creates the object reference in a POA that has the PERSISTENT life span policy. Thus, you can use the IOR across invocations of the Naming Service provided that the service always starts up on the endpoint used when creating the original reference.
Use the -ORBEndpoint option to request that the server start on a specific endpoint, e.g., Naming_Service -ORBEndpoint iiop://bart:9999The general form is: Naming_Service -ORBEndpoint iiop://name_server_host:name_server_portFor more detailed information on using the -ORBEndpoint option, see the TAO Developer's Guide, Section 8.5.3. For more information on direct binding of persistent object references, see Henning and Vinoski, 14.3.2. | ||||||||||||||
Q: |
How do I keep Cos Event Service consumers from blocking suppliers? | ||||||||||||||
A: |
By default, the COS event channel delivers an event to a consumer using the same thread that received it from the supplier. When suppliers publish or emit events, they do so using a two-way invocation. When the event channel delivers an event, it also uses a two-way invocation. Since these are both two-way calls, and the delivery invocation is initiated during the publishing invocation, this causes the supplier to block (waiting for the response to its two-way publication invocation) while the consumers process the event.
This behavior can be avoided by directing the event channel to use a separate dispatching thread for the push to the consumers. This is accomplished differently depending on which COS EC is being used. When using the "native" COS EC, the -CECDispatching option can be used to change the dispatching strategy. A dispatching strategy of "mt" (multithreaded) will start a second thread and use it for the push calls to the consumer. Placing the following option in the service configurator file does the trick: static CEC_Factory "-CECDispatching mt"For example, if this line was placed in ec.conf, then the event channel server can be started with the following command: CosEvent_Service_Native -ORBSvcConf ec.confThe -CECDispatchingThreads option is used to control the number of threads used for consumer deliveries. When using the COS EC that wraps the RTEC (which is the only COS EC in older versions of TAO), the same effect can be accomplished by using the analogous options on the RTEC (-ECDispathing and -ECDispatchingThreads on the EC_Factory). For more information about these and other event channel options, see the TAO Developer's Guide, 14.8 and the online documentation at $TAO_ROOT/docs/cec_options.html and $TAO_ROOT/docs/ec_options.html. | ||||||||||||||
Q: |
Why does my event channel get so slow when consumers die? | ||||||||||||||
A: |
By default the event channels (Cos and RTEC) in TAO continue to attempt to push new events at consumers even after previous pushes to that consumer have failed. If a particular consumer is destroyed without disconnecting from the event channel, then all subsequent pushes by the corresponding supplier proxy will fail. Since each of these require the ORB to timeout, they can drastically affect the throughput of the EC.
You can modify this behavior via the -ECSupplierControl and -ECConsumerControl options. The consumer control option sets the strategy used to deal with ill-behaved consumers. Put the following in a service configurator option file ( ec.conf): static EC_Factory "-ECConsumerControl reactive" This sets the control strategy for the consumers to reactive. Now start the event channel process with this configuration: $TAO_ROOT/orbsvcs/Event_Service -ORBSvcConf ec.conf Any failed attempts to communicate with a consumer result in the disconnection of that consumer (and its proxy) from the event channel. The reactive strategy also polls all the consumers periodically and disconnects them if they fail to respond. The default polling period is 5 seconds and can be set via the -ECConsumerControlPeriod option. The supplier control strategy (and associated polling period) works the same way with suppliers. The native Cos Event Channel has analogous options (-CECConsumerControl, -CECSupplierControl, -CECConsumerControlPeriod, and -CECSupplierControlPeriod). | ||||||||||||||
Q: |
Does TAO's COS Event Service support Typed Events? | ||||||||||||||
A: |
No, and there are no plans to do so. To quote Carlos O'Ryan (cor...@uci.edu): "The spec is so loose that it is hard to define what an implementation would be, and implementations probably won't be interoperable." | ||||||||||||||
Q: |
What is the difference between TAO's Real-Time Event Service and the OMG Notification Service? | ||||||||||||||
A: |
The Notification Service is an implementation of the OMG's Notification Service specification, which originally came out of the Telecommunications working group within the OMG. See
http://www.omg.org/cgi-bin/doc?formal/2000-06-20 for the specification. The Notification Service is backwards compatible with the OMG Event Service.
The Real-Time Event Service is TAO specific. It was developed prior to the adoption of the OMG Notification Service specification. The RT Event Service was designed to meet the real-time and quality of service needs of certain sponsors of the DOC group, but has applicability in a wide variety of domains. On the surface, the two services provide several similar features, though the specifics of their interfaces and implementations are quite different:
In addition, the RT Event Service provides some features that are not part of the Notification Service, such as event channel federations, event correlation, suspension and resumption of consumer connections, and integration with a scheduling service. The RT Event Service is older and perhaps more "mature" in that it has been through multiple iterations of development and is in active use by many real world applications. However, the Notification Service is also quite good and since the Notification Service is based on an OMG specification, it may be a better choice for your application, depending upon your needs.
| ||||||||||||||
Q: |
Why are the notification event channel consumers not receiving events? | ||||||||||||||
A: |
In TAO 1.1a the consumers receive all the events coming to the event channel by default. But in TAO 1.2a the consumers need to subscribe to the events to receive them, as they do not receive any events by default.
This can be done by calling | ||||||||||||||
| |||||||||||||||
Q: |
Is it built automatically or do I have to do something special? | ||||||||||||||
A: |
Security and SSLIOP are not built in a default configuration. You must add stuff to your platform_macros.GNU (see How do I build TAO to get security and SSLIOP?
) as well as install additional software (see What additional software do I need to install?). | ||||||||||||||
Q: |
What additional software do I need to install? | ||||||||||||||
A: |
You'll need OpenSSL (http://www.openssl.org).
In addition, you might need a way of getting good random numbers. | ||||||||||||||
Q: |
How do I build TAO to get security and SSLIOP? | ||||||||||||||
A: |
See http://doc.ece.uci.edu/TAO/Security/SSLIOP-INSTALL.html. | ||||||||||||||
Q: |
Is it legal for me to have this? What sort of legalities are there in using this? | ||||||||||||||
A: |
First, we're software developers and not lawyers. We might be able to write good software, but it takes a mind far more twisted than ours to understand US Export regulations, especially on cryptography and security issues. Therefore, if you have concerns, you should consult
your lawyer.
That said, you might look at http://www.bxa.doc.gov/Encryption/ for current information from the U.S. Government if you're under its jurisdiction. |
||||||||||||||
Q: |
How I can enter the certificate password using an API rather than requiring a user to type in the password? | ||||||||||||||
A: |
The ACE_SSL wrappers don't provide an API or wrapper method(s) to do this. However, you can set a password callback function by manually using the OpenSSL functions. For example, something like the following should work:
SSL_CTX *ctx = ACE_SSL_Context::instance ()->context ();where "your_callback" is a pointer to your PEM passwork callback function. See <openssl/ssl.h> and <openssl/pem.h> for the required callback function signature. | ||||||||||||||
Q: |
Why can't I make an SSLIOP connection using a DSA certificate? | ||||||||||||||
A: |
If you would like to create and use DSA certificates there are a couple of things that need to be done for it to work with SSLIOP. When using DSA certificates you need to specify DH parameters. You can do this by obtaining the SSL context before any connections are made using the ORB. This is TAO specific therefore not portable to other ORBs. First you need to obtain a set of DH parameters. You can either generate these at runtime ( which will take a very long time ), or generate them once with the openssl tool and append them to the end of your certificate.
openssl tool: [Command Line]
openssl gendh 512 >>cert.pemThis will add 512-bit DH parameters to the end of the file cert.pem. After you have created these parameters you will need to load them in your application.#include "orbsvcs/SSLIOPC.h" #include "openssl/pem.h"This should be it. This sets the DH parameters needed to use a DSA certificate with SSLIOP. Please note that a greater degree of error checking should be done than what is provided in this code. | ||||||||||||||
Q: |
How can I use a non-security enabled Naming Service with a security (SSLIOP) enabled client? | ||||||||||||||
A: |
When security is enabled in a CORBA client's ORB, all invocations will be attempted using a secure connection. However, the Naming Service for example may not be set up to use security. Invocations on that Naming Service will result in a CORBA::INV_POLICY exception since the client is unable to make a secure/protected invocation on that non-security enabled Naming Service.
To correct this problem, protected invocations via the Naming Service's object reference must be disabled. This is achieved by setting a policy override on the Naming Service's object reference like so: // Disable protection on Naming Service invocations.This is based on TAO's Secure_Invocation test client side code in $TAO_ROOT/orbsvcs/tests/Security/Secure_Invocation/client.cpp. (TAO 1.2 or better) The above policy override code is standard and should be portable to all ORBs that support the SecurityLevel2::QOPPolicy quality-of-protection client-side policy. Don't forget to include "orbsvcs/SecurityC.h" (this is TAO-specific) to pull in the Security QoP policy related constants and types. | ||||||||||||||
| |||||||||||||||
Q: |
Which OMG CORBA specifications is TAO compliant with? | ||||||||||||||
A: |
For a detailed discussion of OCI TAO 1.1a's compliance with CORBA specifications see http://theaceorb.com/compliance | ||||||||||||||
Q: |
Can I use resolve_initial_references() to directly bind to my own servers? | ||||||||||||||
A: |
Instead of binding object references with the Naming Service and requiring clients to resolve them by name, you can make it possible for clients to directly bind to objects using CORBA::ORB::resolve_initial_references()
, the same mechanism used to bind to other important objects, such as the Naming Service.
For example, suppose you have a server that provides a Bank object (let's call it "CORBABank"). Rather than binding this object by name in a naming context in the Naming Service, you would like clients to access it directly by simply calling orb->resolve_initial_references("CORBABank");
There are several ways to accomplish this.
The following steps describe one way to use the 3rd method described above.
The combination of the simple object key and the fixed endpoint allows us to reference the object via a corbaloc-style reference in the For example, we can start our processes as follows: Server -ORBEndpoint iiop://bart:10200 Client -ORBInitRef CORBABank=corbaloc:iiop:bart:10200/BankObject Where BankObject is the simple object key assigned to the CORBA object in the server. Now, on the client side, we can use // Initialize the ORB.
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
// Get a reference to the Bank using resolve_initial_references().
CORBA::Object_var obj = orb->resolve_initial_references("CORBABank");
Bank_var bank = Bank::_narrow(object.in());
if (CORBA::is_nil(bank.in())) {
cerr << "Bank::_narrow() failed!" << endl;
return 1;
}
// Use the Bank's object reference like you normally would...
Note that on older versions of TAO (before 1.1.10) the object reference format is slightly different: client -ORBInitRef CORBABank=iioploc://bart:10200/BankObject | ||||||||||||||
Q: |
How do I use a "corbaloc" object reference with a TAO server? | ||||||||||||||
A: |
Note: The corbaloc style object reference was added to the CORBA standard via the Interoperable Naming Service specification. For more information on "corbaloc", see the CORBA 2.3.1 (or later) specification, section
13.6.6.
TAO added support for corbaloc references in version 1.1.10. Prior to that, TAO supported an earlier version of the specification that used the iioploc format. You can use corbaloc references to contact servers built with any version of TAO (assuming the client ORB supports them). To simplify use if corbaloc object references, you can register your CORBA object in the server ORB's IOR table so it can be located via a simple object key. To bind an object reference to this table in current versions of TAO (
1.1.10 and later): // Turn your object reference into an IOR string CORBA::String_var ior_string = orb->object_to_string(obj.in()); // Get a reference to the IOR Table CORBA::Object_var tobj = orb->resolve_initial_references("IORTable"); IORTable::Table_var table = IORTable::Table::_narrow(tobj.in()); // Bind your stringified IOR in the IOR Table table->bind("CORBABank", ior_string.in());You will also need to #include "tao/IORTable/IORTable.h" and link with the TAO_IORTable library. In older versions of TAO (1.1.9 and prior) this binding is accomplished via the following code: // Add our Bank object to the ORB's IOR table (TAO specific). orb->_tao_add_to_IOR_table( "CORBABank", obj.in() ); Both of these techniques make it possible for corbaloc-style object references to locate the specified CORBA object via a simple object key ("CORBABank"). The Bank's object reference doesn't necessarily have to be a persistent object reference, but it can be. For more information on persistent object references, see How do I make my object references persistent?. When we run the TAO server, we must ensure that it listens on a host and port that are known to the client. We use TAO's -ORBEndpoint command-line option to do this. The format of -ORBEndpoint is -ORBEndpoint iiop://host:portFor example, if I'm running my server on host "myhost", listening on port 11019: server -ORBEndpoint iiop://myhost:11019When running the client, we'll use a "corbaloc" object reference. The format of the "corbaloc" object reference is corbaloc:protocol:host:port/ObjectKeyFor example: corbaloc:iiop:myhost:11019/CORBABankconnects to the server on host "myhost" at port 11019, and finds the object reference in that server corresponding to the "CORBABank" key. This object reference can be passed to ORB::string_to_object()
and then is used like any other object reference. | ||||||||||||||
Q: |
How do I make my object references persistent? | ||||||||||||||
A: |
In CORBA terminology a transient object reference is one that is only good for the lifetime of a given server's execution. If you run a server, distribute a transient reference to a client, and then kill the server, then the object reference is now useless (even if the server is restarted). A persistent reference allows you continue to use the reference even if the server is restarted.
In order to make your object references persistent you must do the following in your server:
For example: // Initialize the ORB.
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
// Obtain an object reference for the root POA.
CORBA::Object_var obj = orb->resolve_initial_references("RootPOA");
PortableServer::POA_var rpoa = PortableServer::POA::_narrow(obj);
// Create a policy list for our child POA.
CORBA::PolicyList bankPolicies;
// Create the policies for our child POA:
// LifespanPolicy: PERSISTENT
// IdAssignmentPolicy: USER_ID
pols.length(2);
pols[0] = rpoa->create_lifespan_policy(PortableServer::PERSISTENT);
pols[1] = rpoa->create_id_assignment_policy(PortableServer::USER_ID);
// Get the Root POA's POA Manager so it can manage our child POA
PortableServer::POAManager_var poa_mgr = rpoa->the_POAManager();
// Create the child POA.
PortableServer::POA_var bank_poa =
rpoa->create_POA("BankPOA", poa_mgr, pols);
// Destroy the POA policies (create_POA() makes a copy).
pols[0]->destroy();
pols[1]->destroy();
// Create a Bank servant object and activate it with the POA.
Bank_i* bankServant = new Bank_i();
// Explicitly activate the Bank servant. We will use the string
// "CORBABank" to generate an ObjectId for the bank.
CORBA::String_var bankIdString = CORBA::string_dup("CORBABank");
PortableServer::ObjectId_var bankId =
PortableServer::string_to_ObjectId(bankIdString.in());
bank_poa->activate_object_with_id(bankId, bankServant);
obj = bank_poa->id_to_reference(bankId.in());
// Activate the POAs.
poa_mgr->activate();
// Handle requests from clients.
orb->run();
Since the Bank's object reference is a persistent IOR, when we invoke the Bank's server, we need to specify a particular endpoint for the ORB. For example: BankServer -ORBEndpoint iiop://bart:10200 Now, any clients that receive these object references can use them between different runs of the server. Note, that you still need to manually restart the server, unless you use the Implementation Repository. | ||||||||||||||
Q: |
How can I help extend TAO's functionality and add new features? | ||||||||||||||
A: |
TAO is open source and the development group welcomes code contributions. Active participation by users ensures a robust implementation. Please refer to the terms and conditions relating to software submissions on the Washington University Center for Distributed Object Computing's TAO web site at
http://www.cs.wustl.edu/~schmidt/ACE-copying.html before you send code. Incorporation of your code into TAO results in it becoming "open" and the user community being protected by the ACE/TAO copyright and terms.
OCI can also provide consulting and software engineering resources to help you add new functionality into TAO or to span additional platforms. We can also manage the inclusion of such code into the supported releases of new open source versions of TAO. We can provide anonymity if you wish to avoid exposing your technical strategies in public forums, where your competition may be watching. Contact sa...@ociweb.com to discuss your project. Open source software can add immeasurably to the development of a rich infrastructure, and the provision of a high degree of application interoperability, from which we all may derive benefit. Read more about the benefits of open source at
http://theaceorb.com/product/benefit.html. | ||||||||||||||
Q: |
Why doesn't TAO support the BOA? | ||||||||||||||
A: |
The short answer is that the BOA (Basic Object Adapter) is no longer part of the CORBA specification. The BOA was removed because of its lack of portability and underspecification among various other shortcomings. The main argument for adding BOA support to TAO is migration of existing CORBA applications. Because the BOA is implemented differently by each vendor, porting to a TAO BOA would probably be the same amount of work as porting to the POA (which provides true cross-vendor portability). All in all, applications are probably better off making the transition to the POA. | ||||||||||||||
Q: |
How can I get TAO to use my own transport rather than TCP/IP? | ||||||||||||||
A: |
The short answer is that you will need to implement a pluggable protocol.
Starting with TAO 1.0.10, you can find the documentation for the pluggable protocol framework in your TAO distribution ( If the transport satisfies the basic requirements listed in the documentation, then it should be possible to do the implementation without modifying ACE or TAO source code. For an example on how to do this, check out the SSLIOP pluggable protocol. If, on the other hand, your transport protocol doesn't satisfy those requirements (as described by Bruce Trask in the documentation when discussing his SCRAMnet pluggable protocol), then you may need to modify ACE & TAO as he describes. | ||||||||||||||
Q: |
Is the tao-users mailing list archived anywhere? | ||||||||||||||
A: |
Yes.
You can find the tao-users archives on the web at http://www.egroups.com/list/tao-users/. The ace-users archive is available at http://www.egroups.com/list/ace-users/. ACE+TAO Mailing list info can be found at http://www.cs.wustl.edu/~schmidt/TAO-mail.html which includes information about subscribing to the various mailing lists including tao-users. Thanks to Irfan Pyarali for providing this information! | ||||||||||||||
Q: |
How do I get a TAO server to use IIOP v1.0 or v1.1? | ||||||||||||||
A: |
You must use the -ORBEndpoint option. For further details, please refer to the TAO Developer's Guide, the chapter on "ORB Initialization Options." Alternately refer to $TAO_ROOT/docs/Options.html.
The short answer is: -ORBEndpoint iiop://V.v@[hostname:[port]] The V.v@ portion of this syntax informs the server to use a specific major and minor version of the specified protocol. For example, to force a server to use IIOP v1.1 (instead of the default v1.2) on a host named "barney" at port 22000: -ORBEndpoint iiop://1.1@barney:22000 If you always want to force use of IIOP 1.0 or 1.1, you can set the following macro values and rebuild TAO (and your application): #define TAO_DEF_GIOP_MAJOR 1 These macros are typically set in $TAO_ROOT/tao/orbconf.h or $ACE_ROOT/ace/config.h. | ||||||||||||||
Q: |
Why does my application fail when the client and server are on different hosts? | ||||||||||||||
A: |
When an application works with the client and server on the same host, but fails when they are on different hosts, the usual culprit is some sort of naming problem between the hosts. One simple way to test this is to use the ping command to attempt to ping each host from the other (using the host name). You need to ping in both directions as TAO will require both paths.
Another way to test this (and even make it work) is to tell TAO to use decimal addresses (i.e. 128.252.120.1) instead of host names. You can do this by passing "-ORBDottedDecimalAddresses 1" to ORB_init in each process of your application. Note that you need to do this for every CORBA server in your system. Because many
client applications are also CORBA servers, it is best to use this option for all processes. Assuming your code passes command line options to ORB_init, you can do this from the command line: server -ORBDottedDecimalAddresses 1 client -ORBDottedDecimalAddresses 1Even if this works, you still probably want to get your system administrators to fix the naming problems. If you want to always force use of decimal addresses add the following to your $ACE_ROOT/ace/config.h (or $TAO_ROOT/tao/orbconf.h):
#define TAO_USE_DOTTED_DECIMAL_ADDRESSES 1 You can also get this behavior if your server happens to be listening on the address associated with the loopback device. The IP address for this "host" is 127.0.0.1 and often (especially on Linux-based hosts), the hostname is set to localhost.localdomain. Thus, when your client tries to resolve the hostname, it resolves it correctly but connects to itself rather than the host on which the server is actually running. Use Thanks to Tim Fry tf...@imoney.com for posting the raw material from which this entry was created to the tao-users mailing list.
Using The confusion starts when people expect the hostname provided to For further technical and philosophical discussion on this issue, refer to http://ace.cs.wustl.edu/bugzilla/show_bug.cgi?id=474 and http://ace.cs.wustl.edu/bugzilla/show_bug.cgi?id=506. However in TAO 1.2a, this behavior has changed. If you specify an explicit hostname or IP address with the | ||||||||||||||
Q: |
Which thread does TAO use to dispatch a request? | ||||||||||||||
A: |
The answer to this depends on a number of conditions:
See http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/docs/Options.html for more details on these options. See http://www.cs.wustl.edu/~schmidt/PDF/C++-report-col18.pdf for a discussion of TAO's collocation optimizations. | ||||||||||||||
Q: |
How can I detect when a connection between a client and server is broken? | ||||||||||||||
A: |
(Paraphrased from e-mail by Carlos O'Ryan cor...@uci.edu)
You cannot directly detect when this happens. You could write a pluggable protocol that informs your application when a connection dies, but that's about it. Typically behind this question is the issue: how can I detect if my client died. Using connections for that is a very bad idea: the client or server ORBs may close the connection just because it is idle for too long or there may not be a physical connection between two ORBs (they may be collocated or using shared memory to communicate). There can also be multiple connections between a given client-server pair. In CORBA, connections are hidden, and can come and go as needed. Trying to rely on them to establish if the client is still there does not work. In general you are better off using some application-level session object that gets destroyed by the client when it terminates gracefully, and that gets destroyed by an Evictor if it has been idle or unable to contact the client for too long.
| ||||||||||||||
Q: |
Can I use version X of TAO with version Y of ACE? | ||||||||||||||
A: |
Only if X and Y were the versions of TAO and ACE that were released together. For example, ACE 5.1/TAO 1.1 or ACE 5.1.12/TAO 1.1.12. There is no attempt to make the interface between ACE and TAO backward (or forward) compatible. That being said, you may be able to coerce mismatched versions to work together, but it is not something you really want to do.
| ||||||||||||||
Q: |
What are these CORBA::Environment parameters? Why do I get errors about pure virtual functions? | ||||||||||||||
A: |
The CORBA::Environment parameters are part of the alternate exception mapping defined by the OMG's CORBA->C++ mapping specification. Normally, CORBA exceptions are mapped to C++ exceptions. The mapping also allows CORBA to be used when C++ exceptions are unavailable or undesirable by passing exception information via an extra parameter of type CORBA::Environment. TAO supports both mappings and you can build ACE/TAO to support either mapping by passing exceptions=0 or exceptions=1 to GNU make or doing a #define of ACE_HAS_EXCEPTIONS.
If you build TAO to use native exceptions the IDL compiler, by default, does not include the CORBA::Environment parameters. If you build with the alternate mapping the IDL compiler includes the CORBA::Environment parameter by default. You can explicitly tell the IDL compiler what to do with the -Ge flag (-Ge 1 includes the extra parameter, -Ge 0 omits it). You need to generate the skeleton classes in manner that is compatible with your servant classes or you will receive the compiler errors about abstract classes or pure virtual functions. For more information about Exceptions and TAO, see the Error Handling chapter of the TAO Developer's Guide or http://www.cs.wustl.edu/~schmidt/ACE_wrappers/docs/exceptions.html
. | ||||||||||||||
Q: |
What is involved with using std library (inc stl) with ACE/TAO? | ||||||||||||||
A: |
There are several conditional directives that are relevant:
In practice it is fairly common to use ACE_HAS_STANDARD_CPP_LIBRARY. I always use this, and prefer the standard library to ACE where there is overlap. (ie std::map or hash_map over ACE_Hash_Map_Manager_Ex) Of course this can be a portability issue. | ||||||||||||||
Q: |
Why is my "client" thread dispatching requests? | ||||||||||||||
A: |
By default, TAO attempts to efficiently use all the threads that are given to it. This includes "client" threads that have sent a request and are waiting for a reply from the server. While waiting, these threads enter the normal thread pool reactor event loop. This means that any incoming requests (assuming that the process is also a server) may be dispatched using that thread.
This has a couple of side effects that suprise many people. First, it is possible for even a single threaded server to process more than one request at the same time. Second, if you try to allocate threads exclusively as "server" threads and "client" threads, the ORB will pay no attention to your idea of what these threads are and dispatch requests on both. Why is this the default behavior of TAO? Mainly because it avoids many potential deadlock situations. One example is a simple callback operation with a single threaded client. When the client sends a request to the server, the server sends a callback request back to the client. If the client's only thread is waiting for the reply and not dispatching incoming requests, then a deadlock is now in place. The default behavior allows the client ORB to process the callback request and send a reply to the server which frees the server ORB to send its reply back to the client. You can modify the default client side behavior of TAO via the static Client_Strategy_Factory "-ORBWaitStrategy rw -ORBTransportMuxStrategy exclusive -ORBConnectStrategy blocked" static Resource_Factory "-ORBFlushingStrategy blocking" Note that you should always set the | ||||||||||||||
Q: |
Why does ORB_init change the order of the command line arguments if we pass argv to ORB_init(argc, argv)? | ||||||||||||||
A: |
CORBA::ORB_init() is supposed to remove all "-ORB" options it recognizes. One way of doing that logically and efficiently is to put all of those recognized arguments at the end of the argument vector and adjust the argument count (argc) accordingly.
You are only supposed to use the first "argc" number of arguments after call CORBA::ORB_init(). In your case, you had: argc = 3 and argv = { "ex", "-ORBDebugLevel", "5" }
After calling CORBA::ORB_init() you have: argc = 1 and argv = { "ex", "5", "-ORBDebugLevel" }
This means that you should only be using first argument from the argument vector.If you need to maintain the order of the original argument vector for later use, then you have to make a copy before calling CORBA::ORB_init(). | ||||||||||||||
Q: |
Why don't signals work with the ORB reactor? | ||||||||||||||
A: |
Signals and the ORB reactor: By default ACE uses the ACE_Select reactor, which works with signals. TAO defaults to use the TP reactor, which does not currently work with signals. The call ACE_Reactor::instance() returns an ACE_Select_Reactor. The call TAO_ORB_Core_instance()->reactor() returns an ACE_TP_Reactor. | ||||||||||||||
Q: |
Why does my multithreaded server deadlock when I make an invocation from an event handler registered with the ORB's reactor? | ||||||||||||||
A: |
(Expanded question): I am running a server with a few threads in a thread pool. I have also registered an event handler with the ORB's Reactor from which I am making remote invocations. My server is deadlocking. Note: I am using the default configuration (
i.e., default concurrency strategy, wait strategy, flushing strategy, etc.)
(Answer): By default, the ORB uses a Leader Follower (LF) for receiving requests and processing replies from remote targets. It uses a simple protocol that keeps track of the server threads that are ready to process invocations and the client threads that are waiting to process replies. When you register your own event handlers with the reactor, the reactor makes an upcall directly into your application code. If your event handler code then makes a remote call and waits for a reply, the LF protocol breaks down since a thread marked as a server thread becomes a client thread without the LF's knowledge. The signature of the problem is a blocked server with stack traces showing none of the threads in the
To fix this problem, you have to abide by the LF protocol. Do the following within your event handler code (e.g., in TAO_ORB_Core *oc = my_orb->orb_core (); oc->lf_strategy ().set_upcall_thread (this->orb_core_->leader_follower ()); You may have to include the header files Thanks to Milan Cvetkovic <mcvet...@mpathix.com> for reporting the problem and to Balachandran Natarajan <ba...@dre.vanderbilt.edu > for providing the answer. Note: You could also solve the problem by configuring the ORB to use a different wait strategy other than the default Leader Follower. Or, you could use a different ORB (other than the server ORB) in your event handler for making the outbound invocation. | ||||||||||||||
Q: |
How can I build debug applications with non-debug libraries? | ||||||||||||||
A: |
During development, you will normally want to build your application code with debugging enabled. However, you may be using non-debug versions of the ACE, TAO, and CIAO libraries. Depending upon your platform and development environment, special care must be taken to make sure your debug-enabled application can link against non-debug ACE, TAO, and CIAO libraries.
On platforms that use GNU Make, all you have to do to enable debugging in your application is set the debug build flag to 1 when you build your application code. You can do this by setting
debug=1 on the make command line, as follows:make debug=1Or, you can set debug=1 in your platform_macros.GNU file when you build your application. Note: If you have debug=1 in platform_macros.GNU when you build the ACE, TAO, and CIAO libraries, they will be built with debugging enabled, too.
On some platforms, such as Windows with Visual C++, the ACE, TAO, and CIAO library names may have a modifier appended to the library name to indicate whether it was built with a debug, static, MFC, or some other configuration. For example, in a debug build, the name of the ACE shared library will be ACEd.dll, whereas in a non-debug (release) build, the name of the ACE shared library will be ACE.dll.On these platforms, if you build your application with a debug configuration, and you are using project files generated by MPC, the linker will, by default, look for libraries with the "d" debug modifier appended to the library name. If you are building your debug application against non-debug libraries, you need to tell the linker to look for the unmodified library names. You can do this by directly editing the project settings ( e.g., to remove the "d" from the library names). Or, you can use the -value_template MPC option to override the default definition of the library modifier when you generate your project files.
For example, suppose your application's MPC workspace file is MyApp.mwc and suppose you are using Visual C++ 7.1. If you want to build your application against the same set of non-debug ACE, TAO, and CIAO libraries, regardless of whether you build the debug or release configuration, you can use the following command to generate your application's project and solution files:
$ACE_ROOT/bin/mwc.pl -type vc71 -value_template lib_modifier=The -value_template option in the above command sets the value of the lib_modifier template variable to an empty string, which causes no modifier to be added to the library names with which your application will link, regardless of which configuration (debug or release) you build.
Watch out for build problems if you have any settings in your config.h file that depend upon having debugging enabled, for example:#if defined(_DEBUG) #undef __ACE_INLINE__ #endifFor more information on MPC, see the MPC documentation and the MPC FAQ: http://download.ociweb.com/MPC http://www.ociweb.com/products/mpc/faq.html | ||||||||||||||
| |||||||||||||||
Q: |
Why do I experience a run-time link error, even though my path and environment variables are set correctly and I have a fresh build tree? | ||||||||||||||
A: |
You may have an older version of one of the ACE, TAO, or CIAO libraries somewhere in your library search path (e.g., PATH on Windows, LD_LIBRARY_PATH on Linux) that you don't know about, even though you have only one build tree of ACE+TAO+CIAO. For example, the CoSMIC tool chain installer ships with the ACE libraries and installs them on your system. The same is true of OCI's TAO distribution CDs.
If you do have an out-dated version of one of the ACE, TAO, or CIAO libraries (e.g., You can confirm that this is the problem you are having by moving the problematic library in your build tree to a backup file and re-running your application. If you still experience the run-time link error, then you probably have another (stale) version of the problematic library on your system. (The
Thanks to Stoyan Paunov for contributing this question and answer. | ||||||||||||||
Q: |
My server IOR contains the address 127.0.0.1 and my client, running on a different machine, can't connect. What do I do? | ||||||||||||||
A: |
When determining the endpoint for a server, TAO chooses an interface from the interfaces available to the system and encodes its address within the IOR. If TAO chooses 127.0.0.1
(the local loop back) as the endpoint address, then it could not find any other suitable interfaces. Since this address is only visible to local machine, no other machine will be able to connect to the local machine through that address.
If there are dynamic interfaces that are available to the system, you may need to explicitly specify that TAO should use that interface with the -ORBEndpoint command line option: -ORBEndpoint iiop://< hostname or ip address >:< port > | ||||||||||||||
Q: |
Why I am getting errors when I try to initialize the first ACE object in an application? | ||||||||||||||
A: |
The short answer is that you probably need to call ACE::init() before initializing or using any ACE/TAO objects.
When you include ACE/TAO headers from the file containing main(), then the | ||||||||||||||
Q: |
Why is my application leaking memory when I use local objects? | ||||||||||||||
A: |
It is likely that your objects are using reference counting to manage their life cycle. The CORBA::LocalObject class provides an empty implementation of the _add_ref() and _remove_ref() methods. However, the TAO_Local_RefCounted_Object implements real reference counting through these methods.
The solution to your memory leak may be as simple as inheriting from TAO_Local_RefCounted_Object instead of CORBA::LocalObject. | ||||||||||||||
| |||||||||||||||
Q: |
Why does Orbix 2000 reject large messages from TAO? | ||||||||||||||
A: |
(as related by Balachandran Natarajan ba...@cs.wustl.edu)
By default, Orbix 2000 will reject any message larger than 512 KB. Orbix 2000 users can get around this by setting a run time policy in their configuration file. The policy is policies:iiop:buffer_sizes_policy:max_buffer_size = "-1"; |
||||||||||||||
Q: |
What ORBs does TAO interoperate with? | ||||||||||||||
A: |
There are many different interpretations of the word "interoperate". In general, TAO works with any ORB that adheres to the relevant OMG CORBA standards. If it doesn't work, then there is a bug in one of the ORB implementations. If it is with TAO it is usually corrected quickly (even quicker if you help document and debug the problem). Other ORB implementors also fix these problems quite quickly when they are brought to their attention.
There is no definitive list of ORBs that a particular version of TAO works with. Here are some ORBs that users have reported successfully using with TAO in the past:
| ||||||||||||||
Q: |
Is the TAO Naming Service interoperable with the JDK 1.4 beta 3 ORB? | ||||||||||||||
A: |
JDK 1.4 supports Interoperable Object References (IORs). To use the JDK 1.4 ORB with the TAO Naming Service server:
Start TAO Naming Service server: $ $TAO_ROOT/orbsvcs/Naming_Service/Naming_Service -ORBListenEndpoints iiop://host:port Then, run the JDK 1.4 client as follows to use the TAO Naming Service: $ java MessengerClient \
-ORBInitRef NameService=corbaloc:iiop:host:port/NameService
Here is a sample Java client: public class MessengerClient
{
public static void main( String[] args )
{
try {
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
// resolve the naming service
org.omg.CORBA.Object obj =
orb.resolve_initial_references("NameService");
NamingContext rootContext = NamingContextHelper.narrow( obj );
// create sample name(sever binding)
NameComponent[] name = { new NameComponent( "example", "" ),
new NameComponent( "Messenger", "" ) };
// resolve the server reference
obj = rootContext.resolve(name);
Messenger msgr = MessengerHelper.narrow(obj);
..............
...........
} catch ( Exception e ) {
System.err.println( "ERROR: " + e );
e.printStackTrace( System.err );
}
}
}
| ||||||||||||||
| |||||||||||||||
Q: |
Where can I see performance comparisons between TAO and <some other ORB>? | ||||||||||||||
A: |
It's not as easy to compare the performance of ORBs as generically as one might compare, e.g., the performance of microprocessors. There are no standard benchmarks available at the present. Thus, any evaluation of performance of an ORB is largely dependent on the application and its characteristics as well as the environment in which it's running (such as over an ATM network vs. ethernet vs. wireless, etc.).
That said, you might be able to get a better feeling of the situations in which various ORBs "shine" (performance-wise) by looking at some of the benchmarks available through the following links:
Finally, don't forget that nothing comes without a cost, so carefully evaluate the entire ORB package, not just the performance. | ||||||||||||||
Q: |
How can I minimize the sizes of the ACE and TAO libraries? | ||||||||||||||
A: |
There are several ways to minimize the sizes of the ACE and TAO libraries, at least in UNIX. They are described briefly here. More details can be found in the TAO Developer's Guide (Section B.2 of the
TAO 1.3a Developer's Guide).
Note that all of these solutions take place at compile time, so if you have OCI's distribution of TAO you'll need to re-compile.
IMPORTANT You should use the "size" command instead of measuring the size of each library file on disk (e.g., with "ls -l") to get a more accurate measure of the true size of the code in the library. For example, in TAO
1.1a, here is the output of the "ls -l" and "size" commands for $ACE_ROOT/ace/libACE.so on Linux (Fedora Core 2) built with gcc 3.3.3 with debug=1, exceptions=1, optimize=1: $ ls -l $ACE_ROOT/ace/libACE.so
-rwxr-xr-x 1 johnc distcomp 48154963 Jan 18 11:13 libACE.so*
Note that the "ls -l" command reports the size of the library file on disk as a whopping 48154963 bytes (or about 46 MB) while the size command ("dec" column, which is the total of the "text", "data", and "bss" columns, in decimal) reports the size at only 2080024 bytes (or about 2 MB). (The "bss" section is unitialized data, according to the Solaris size(1) man page.) You can also use the "size" command to measure the size of an executable. The size of each library's file on disk, as reported by "ls -l", is actually somewhat irrelevant to the runtime size of your executable, for the following reasons:
Depending upon your linker and operating system, your mileage may vary. | ||||||||||||||
Q: |
My platform doesn't have a filesystem; how can I use service configurator directives? | ||||||||||||||
A: |
Many embedded systems don't have filesystems, which really puts a cramp in using the svc.conf file and its directives (e.g., for the Resource_Factory).
However, you can pass Service Configurator directives on the "command line" using the For example, you might put code like the following in your main(): ACE_ARGV orb_args(
"-ORBSvcConfDirective "
"\"static Resource_Factory '-ORBResources tss'\"");
CORBA::ORB_var orb = CORBA::ORB_init(orb_args->argc(),
orb_args->argv());
| ||||||||||||||
Q: |
Running a thread pool ORB | ||||||||||||||
A: |
The trick is to configure TAO to use the thread pool reactor and then to call orb->run() from a number of threads, thereby enabling each thread to service incoming requests.
Selection of the reactor is done through the use of the resource factory, a service config object. If you are using a service configuration file, such as svc.conf, add a line: static Resource_Factory '-ORBReactorType tp' If you cannot use a configuration file, add the following to your command line: -ORBServiceDirective "static Resource_Factory '-ORBReactor TP'" Note that if you are already configuring the resource factory for any other behavior, do not add a new directive line, just add "-ORBReactor TP" to the arguments already passed to the resource factory. Now that you have the correct reactor selected, you must invoke ORB::run() from within the threads that are members of the thread pool. The easiest way to achieve this is to derive from ACE_Task, override the svc() method to run the orb, and then use the activate method to start the desired number of threads.
class my_ORB_Pool : public ACE_Task <ACE_MT_SYNCH>
{
public:
virtual int open (void *arg);
virtual int svc (void);
private:
CORBA::ORB_ptr orb_;
};
// A reference to the ORB must be supplied to the object, via open
int
my_ORB_Pool:: open (void *arg)
{
orb_ = ACE_static_cast (CORBA::ORB_ptr,arg);
return 0;
}
// ACE_Task::activate calls svc() in as many threads as we specify
int
my_ORB_Pool::svc (void)
{
orb_->run();
return 0;
}
//Now, start it going
int
main (int argc, char ** argv)
{
// normal program initialization business
my_ORB_Pool orb_pool;
// initialize the orb, which also loads the correct reactor
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
int nthreads = 42; // the number of threads in the pool
orb_pool.open(orb);
orb_pool.activate (ACE_NEW_LWP,nthreads); // nthreads = 1 is normal
// reactive behavior
ACE_Thread_Manager::instance->wait(); // wait for all threads
return 0;
}
| ||||||||||||||
Q: |
Does TAO support request/reply timeouts? | ||||||||||||||
A: |
TAO 1.3a supports the Relative Roundtrip Timeout policy as defined in the CORBA Messaging specification (OMG TC Document orbos/98-05-05). This policy allows you to specify the maximum time allowed (in 100 nanosecond units) for a request to be sent to and processed by a server and the reply received by the client. The policy can be applied at one of three levels: the client ORB, the requesting thread, or the object reference on which the request is invoked.
Relative roundtrip timeouts can be applied when the client requires low request/reply latencies. The following example shows how to set the Relative Roundtrip Timeout policy to a value of 1 millisecond (that is 1.0e-3 * 1.0e7 in 100 nanosecond units) and apply it at the ORB level: // Initialize the ORB. It serves as a factory for policies.
CORBA::ORB_var orb = CORBA::ORB_init (argc, argv);
// Set the timeout value as a TimeBase::TimeT (100 nanosecond units)
// and insert it into a CORBA::Any.
TimeBase::TimeT relative_rt_timeout = 1.0e-3 * 1.0e7;
CORBA::Any relative_rt_timeout_as_any;
relative_rt_timeout_as_any <<= relative_rt_timeout;
// Create the policy and put it in a policy list.
CORBA::PolicyList pols;
pols.length(1);
pols[0] =
orb->create_policy (Messaging::RELATIVE_RT_TIMEOUT_POLICY_TYPE,
relative_rt_timeout_as_any);
// Apply the policy at the ORB level using the ORBPolicyManager.
CORBA::Object_var obj =
orb->resolve_initial_references ("ORBPolicyManager");
CORBA::PolicyManager_var policy_manager =
CORBA::PolicyManager::_narrow (obj.in());
policy_manager->set_policy_overrides (pols, CORBA::SET_OVERRIDE);
All requests made via this ORB will now timeout if a reply is not received within 1 millisecond. When a timeout occurs, the ORB will raise a CORBA::TIMEOUT system exception. The client can then take whatever action is necessary to handle the failure. If a reply eventually arrives after the timeout period has expired, it will be discarded by the client ORB. The Relative Roundtrip Timeout policy, and other Quality of Service policies defined as part of the CORBA Messaging specification, are described in more detail in the OCI TAO Developer's Guide, Chapter 8.3, available from
http://www.theaceorb.com/. See also http://www.cs.wustl.edu/~schmidt/PDF/C++-report-col19.pdf. | ||||||||||||||
Q: |
What IDL compiler options help reduce the footprint? | ||||||||||||||
A: |
Footprint Reduction in Generated Code
IDL Compiler Command Line Options
C++ Compiler Options If both TAO and the application are compiled with TAO_HAS_INTERCEPTORS defined to be 0 (either by passing to the C++ compiler or by redefining the macro in ACE_ROOT/TAO/tao/orbconf.h) not only will the TAO library be smaller, but also the application object code, since the C++ preprocessor will skip the generated interceptor classes and parts of the code generated for each IDL operation. | ||||||||||||||
Q: |
How can I reduce my compile time during development? | ||||||||||||||
A: |
Reducing compile time during development: Disable Optimization: When developing software that uses ACE+TAO you can reduce the time it takes to compile your software by not enabling you compiler's optimizer flags. These often take the form -O. Disabling optimization for your application will come at the cost of run time performance, so you should normally only do this during development, keeping your test and release build optimized. Disable Inlining : When compiler optimization is disabled, it is frequently the case that no inlining will be performed. In this case the ACE inlining will be adding to your compile time without any appreciable benefit. You can therefore decrease compile times further by build building your application with the -DACE_NO_INLINE C++ flag. In order for code built with -DACE_NO_INLINE to link, you will need to be using a version of ACE+TAO built with the "inline=0" make flag. In order to accommodate both inline and non-inline builds of your application it will be necessary to build two copies of your ACE+TAO libraries, one with inlining and one without. You can then use your ACE_ROOT and TAO_ROOT variables to point at the appropriate installation. | ||||||||||||||
| |||||||||||||||
Q: |
What's the minimum set of directories I need to build to be able to develop applications with ACE and TAO? | ||||||||||||||
A: |
One common way to build ACE and TAO (once you have your configuration set up) is to simply run "make" in the $ACE_ROOT directory, then run "make" again in the $TAO_ROOT directory. However, running "make" from $ACE_ROOT not only builds the ACE library, it also builds all of the examples, tests, and other things you may not need. Likewise, running "make" from $TAO_ROOT builds not only the TAO and orbsvcs libraries, it also builds all the TAO and orbsvcs tests and examples.
To build only what you need to develop applications with ACE and TAO (and to save LOTS of disk space while building) you can run make in only the following directories: $ACE_ROOT/ace $ACE_ROOT/apps/gperf/src $TAO_ROOT/TAO_IDL $ACE_ROOT/ACEXML $TAO_ROOT/tao $ACE_ROOT/protocols $TAO_ROOT/orbsvcs/orbsvcs This will build only the ACE library, gperf executable (needed by the IDL compiler), tao_idl executable, ACEXML library, protocol libraries (extensions of the ACE framework), TAO libraries, and orbsvcs libraries. If you want to also build any of the orbsvcs executables (e.g., $TAO_ROOT/orbsvcs/Naming_Service), add their directories to the set of directories that you build. For example: cd $TAO_ROOT/orbsvcs/Naming_Service make You may also find the "nslist" and "catior" utilities very useful, so you probably should also add these directories to the list of directories in which to build: $TAO_ROOT/utils/nslist $TAO_ROOT/utils/catior Of course, you can always go back and build individual tests and examples if you want to. | ||||||||||||||
Q: |
Why can't my client connect to a server running on a wintel host with dialup networking? | ||||||||||||||
A: |
See My server IOR contains the address 127.0.0.1 and my client, running on a different machine, can't connect. What do I do? for a possible solution.
| ||||||||||||||
Q: |
What issues are involved when using MFC with ACE/TAO? | ||||||||||||||
A: |
You can add an ACE_HAS_MFC conditional #define to your ace/config.h file. It is only necessary to use ACE_HAS_MFC if you wish threads created and managed by ACE to be able to make MFC calls. The ACE_HAS_MFC setting causes ACE to use CWinThread worker thread objects for all threads. ACE will still manage these threads just the same as threads created by _beginthreadex(). The only difference is the extra thread-local data stored in the threads. Refer to the many articles on MSDN for when to use AfxBeginThread vs _beginthread, and which MFC functions require CWinThreads. There are quite a few subtle problems. For instance, you typically can't use an MFC wrapper object created in one thread in another. (By wrapper object, I mean those that wrap windows handles. CDC, CWnd, ...) (The typical solution is to pass the handles betweeen threads.) --- In summary, if you find that you really do need to make MFC calls from ACE threads then use the MFC build of the ACE library, however it is typically not necessary because the layer of software using ACE/TAO is often separated from the layer using MFC. | ||||||||||||||
Q: |
Are there any project wizards for Borland C++ Builder? | ||||||||||||||
A: |
Yes, Christopher Kohlhoff (ch...@kohlhoff.com) has developed these and made them available at
http://www.tenermerx.com/programming/corba/tao_bcb/using/index.html . | ||||||||||||||
| |||||||||||||||
Q: |
Can I build ACE and TAO on Windows 95 or Windows 98? | ||||||||||||||
A: |
ACE and TAO should build with Visual C++ on Windows 95/98. However, there are several differences between these operating systems and Windows NT 4.0 that must be accommodated.
To make sure ACE and TAO (really, it is ACE we are concerned with here) build correctly on Windows 95/98, you have to turn off compilation of certain Windows NT specific features. To do so, insert the following line into
#define ACE_HAS_WINNT4 0 The above line should be inserted just above the line that reads: #include "ace/config-win32.h" See also Can I use IP multicast for service discovery in Windows 95 or Windows 98? | ||||||||||||||
Q: |
Does OCI's version of TAO contain MFC libraries? | ||||||||||||||
A: |
MFC Libraries are libraries built with the ACE_HAS_MFC variable defined. See What issues are involved when using MFC with ACE/TAO? for more details of what this means. The OCI-produced binary installation kits do not contain MFC libraries for Windows platforms. You will need to recompile ACE and TAO in order to build them with MFC libraries. | ||||||||||||||
Q: |
Can I use IP multicast for service discovery in Windows 95 or Windows 98? | ||||||||||||||
A: |
By default, older versions of TAO use IP multicast to discover services such as the Naming Service or Trading Service. For example, when you call CORBA::Object_var obj =
orb->resolve_initial_references("NameService");
an IP multicast request may be sent. If a Naming Service is running and receives the request, it will reply with the IOR of its root naming context.
IP multicast for service discovery is enabled by default on most platforms that support it, such as most UNIX operating systems and Windows NT. To enable it on Windows 95 or Windows 98, however, you must have Winsock2 and you must add the following line to ACE_wrappers\ace\config.h when you build ACE:
#define ACE_HAS_WINSOCK2 1So, your entire config.h might look like this: #define ACE_HAS_WINNT4 0 #define ACE_HAS_WINSOCK2 1 #include "ace/config-win32.h" | ||||||||||||||
Q: |
Has anybody gotten TAO (and ACE) to compile using Borland CBuilder 4? | ||||||||||||||
A: |
[Thoughtfully provided by Charles Frasch cfr...@spawar.navy.mil.]
A good source for how to build ACE and TAO using Borland CBuilder is http://www.tenermerx.com/tao_bcb/index.html. I just followed the steps under the "Building TAO" link with the following changes:
set ACE_ROOT=c:\ACE_wrappers3A. Make sure the CBuilder 4 binaries are in your path, e.g. set PATH=%PATH%;d:\PROGRA~1\CBUILD~1\Bin The one-button tests are not built by default. To build and run them do the following: 1. Set set ACE_ROOT=c:\ACE_wrappers 2. Make sure the CBuilder 4 binaries are in your path, e.g. set PATH=%PATH%;d:\PROGRA~1\CBUILD~1\Bin 3. Change to the ACE tests source directory: cd C:\ACE_wrappers\tests 4. Build the one-button tests: make -f Makefile.bor 5. If you built ACE as a dynamic link library you must put it in your path, e.g. set PATH=%PATH%;%ACE_ROOT%\bin\Dynamic\Release 6. Run the tests. The results go in run_tests borYou can run a particular test by naming it as the second argument, e.g. run_tests bor Atomic_Op_Tests I will be sending in a change to the makefile that will allow you to just make -f Makefile.bor tests I had these problems with the one-button tests: 1. The 2. The 3. The I built the I have not tried any combinations of DEBUG/STATIC/PASCAL other than the defaults, nor have I (yet) tried to use the BCB4 IDE to build an application. This will be the next step. Just saw the new faq "Has anybody gotten TAO (and ACE) to compile using Borland CBuilder 4?", and all I have to say is "Oops!" :) I added the info from the missing steps 1A and 3A into my page at http://www.tenermerx.com/tao_bcb, so you can probably remove them from the faq item.[I've left them in for now.] I haven't added information about building the tests (yet), but I'd like to suggest a few small corrections to what you have: - ACE_Init_Test uses MFC so won't be supported with BCB4 anyway. - The TAO/tests/CDR test was the only test as of TAO 1.0. There are more tests running (but not all) with the recent betas. | ||||||||||||||
Q: |
Why do I encounter linking errors when building Debug applications in Windows NT with Visual C++? | ||||||||||||||
A: |
If you're linking debug versions of an executable or DLL and have unresolved symbols, there are several possible reasons:
| ||||||||||||||
Q: |
How do I export generated classes from DLL's | ||||||||||||||
A: |
According to the TAO Developer's Guide, version 1.1a section 7.12 "Back End Options", the way to export generated classes is thus:
| ||||||||||||||
Q: |
Why doesn't using the Naming Service with Multicast work? | ||||||||||||||
A: |
At least on Windows NT, there's a bug in which the TTL (Time-to-Live) field in multicast IP packets is set to zero. Thus, nobody pays attention to those packets. This particular problem bit OCI in their training lab environment, and for this reason we now use the Naming Service without multicasting as documented in Section
20.2.4 of the Dev Guide (see How do I locate the naming service server without multicast?).
The problem is documented in http://support.microsoft.com/support/kb/articles/Q234/9/80.ASP. Although the notes say to get the latest Service Pack, our experience shows that this doesn't help as of Service Pack 6.
| ||||||||||||||
Q: |
How do I link against multithreaded libraries in Visual C++? | ||||||||||||||
A: |
Select the Project -> Settings menu item Select the C/C++ tab. Set the Category to Code Generation Under Run-time library select one of the multithreaded libraries | ||||||||||||||
Q: |
Why do I get errors while using 'TryEnterCriticalSection'? | ||||||||||||||
A: |
The Visual C++ compiler may report an error like this when using 'TryEnterCriticalSection': C:\projects\bluebox\thom\ace/OS.i(2384) : error C2039: 'TryEnterCriticalSection': is not a member of '`global namespace'' You may get this error because 'TryEnterCriticalSection' is only available on Windows NT and Windows 2000. There are two ways to fix this problem:
| ||||||||||||||
Q: |
When I use the ACE_Process_Manager to launch my process, why does the reactor fail to initialize? | ||||||||||||||
A: |
Either inherit the environment (via ProcessInfo) or set the SystemRoot environment variable to c:\WinNT or the appropriate place for windows install. | ||||||||||||||
Q: |
Which project settings should I change to ensure acemfc.lib is built? | ||||||||||||||
A: |
Change the active configuration: Batch build: | ||||||||||||||
Q: |
How do I instantiate a singleton from a DLL? | ||||||||||||||
A: |
Singletons in DLLs on Windows If you want to instantiate a singleton in a DLL on Windows, follow these steps:
| ||||||||||||||
Q: |
Why does my TAO application leak memory when using Windows threads? | ||||||||||||||
A: |
On Windows, if one spawns a thread with, for example _beginthreadex, and makes CORBA calls from that thread, TAO will leak memory. TAO uses TSS (thread specific storage) for handling requests along the output data paths. With Win32 threads, the underlying type system does not invoke destructors on TSS and the application will leak memory. To get around this problem, please use ACE threads wherever possible. Thanks to <
alexande...@gmx.net> for supplying this FAQ! | ||||||||||||||
| |||||||||||||||
Q: |
I've just built the libraries and they're HUGE...how can I make them smaller? | ||||||||||||||
A: |
See How can I minimize the sizes of the ACE and TAO libraries? for a more general discussion of TAO program/library sizes.
This all depends upon your definition of "huge" and how you built the libraries. If you consider a few megabytes to be huge and you've built optimized, nodebug, and minimum CORBA, then that's the way life is currently. If, on the other hand, you're looking at the size of the files and you built the defaults, then the first thing you need to do is understand that the size of the file is NOT the same as the size of the code. When compiling with debug information, the compiler adds symbol information to the libraries, and that symbol information is
massive. What you need to do is look at the code size. Using the WindRiver GNU toolchain, you can use $ sizeppc libACE.so text data bss dec hex filename 626392 65036 1316 692744 a9208 libACE.so $ ls -l libACE.so -rwxrwxr-x 1 cleeland distcomp 31181587 Mar 16 10:10 libACE.so*So, you can see that the file size is 30Mb, but the code size is 692k. Quite a different number. There are various strategies for making the libraries smaller, and all involve rebuilding. Specifically, you can build:
An often-used technique for keeping library sizes small and still debuggable is to build the entire library nondebug, then only build the pieces you need to debug with debug on. This allows you to debug those pieces, but not suffer through the problems that large file sizes in libraries cause ( e.g., longer download/boot times). Here is a shortcut to rebuilding a lib with debug=0. But:
| ||||||||||||||
Q: |
How do I create shared libraries? | ||||||||||||||
A: |
Shared libraries on VxWorks aren't really shared libraries. If you ever worked on Unix in the days before shared libraries, you might remember "relocatable object files", i.e., object files created by the linker with many of their symbols resolved, but also permitted to have unresolved symbols.
When you see libACE.so on VxWorks, they're simply relocatable object files. Once you realize that, and all it entails, your life will get easier :-) Some implications of this are:
$ make shared_libs_only=1 ACE_SHLIBS=The ACE_SHLIBS make macro usually contains the names of shared libraries to link in, such as "-lTAO -lACE", etc. By making it empty, these do not get linked. | ||||||||||||||
| |||||||||||||||
Q: |
Is there a Java version of TAO? | ||||||||||||||
A: |
Yes, and no. It's called Zen.
Check out What is ZEN?. Note that you can use any CORBA compliant ORB with TAO. The most popular Java-based ORB used with TAO is JacORB. See What is JacORB? for more details. | ||||||||||||||
Q: |
Does TAO support a Java binding? | ||||||||||||||
A: |
TAO is a C++ ORB. Any other CORBA compliant ORB can interoperate with TAO (as well as other CORBA compliant ORBs). There are several free Java ORBs available, such as JacORB. For more information on TAO and JacORB, see
What is JacORB?.
Work on a real-time Java ORB, ZEN, is currently in progress. For more information, see What is ZEN? or http://www.zen.uci.edu/ . | ||||||||||||||
Q: |
Is TAO interoperable with Sun's Java JDK 1.3 ORB? | ||||||||||||||
A: |
Yes, but there is an issue with Codesets supported by Sun's Java 1.3 ORB.
Sun's Java 1.3 ORB does not support character sets UTF-8 and UTF-16. To use Sun's Java 1.3 ORB with TAO, you must disable the generation of optional standard profile components in IORs generated by TAO. To do so, use the following ORB initialization option with TAO servers that generate IORs that will be used by Java 1.3 ORB clients: -ORBStdProfileComponents 0 Thanks to Gordana and Kate Matic gord...@ot.co.nz for posing the original question and Carlos O'Ryan
cor...@uci.edu for providing the answer. | ||||||||||||||
Q: |
Is TAO interoperable with JacORB? | ||||||||||||||
A: |
Yes, TAO is interoperable with JacORB.
TAO and JacORB have been tested using TAO 1.1a, JacORB 1.3.X, JacORB 1.2.3, and Java JDK 1.3. Some tests have also been performed using TAO 1.0a, JacORB 1.0.3, and Java JDK 1.1.8. | ||||||||||||||
Q: |
How can I use TAO with Java's tnameserv? | ||||||||||||||
A: |
Using tnameserv as the naming service implementation.
[From material originally posted to tao-users by Carlos O'Ryan.] $ tnameserv -ORBInitialPort 1050 &; In order for your CORBA application to use this naming service instance, you need to somehow get the IOR for the instance (exercise left to the reader). Once you get it, you can provide it to your TAO-based CORBA application using the -ORBInitRef NameService=... command line option. For example, if you have the IOR as a string, you can use: $ app -ORBInitRef NameService=IOR:....Similarly, if the IOR is in a text file, you can use: $ app -ORBInitRef NameService=file://path/to/file.txt Finally, if you were so lucky for your version of tnameserv to implement the Interoperable Naming Service specification (doubtful at the moment), you could use: $ app -ORBInitRef NameService=corbaloc:iiop:host:port/NameServiceIn older versions of TAO (before 1.1.10) this option takes the following form: $ app -ORBInitRef NameService=iioploc://host:port/NameService | ||||||||||||||
Q: |
How can I use TAO's Naming Service with my Java ORB? | ||||||||||||||
A: |
When I use the TAO name service, JavaORB returns an org.omg.CORBA.INV_OBJREF in resolve_initial_references("NameService").
There's a file called NS_Resolve.java in $TAO_ROOT/examples/Simulator/DOVEBrowserthat contains code which discovers TAO's Naming Service via the multicast discovery mechanism. Hooking that into the initial references table is ORB-specific, however. Alternately, you can bypass the TAO Naming Service's multicast mechanism and connect your Java application to it directly. For an example which uses TAO and JacORB, see How do I use JacORB with TAO's Naming Service? | ||||||||||||||
Q: |
What is ZEN? | ||||||||||||||
A: |
ZEN is a real-time Java ORB being developed by the Distributed Object Computing groups at the University of California, Irvine and Washington University in St. Louis.
ZEN is currently under development. For more information, see http://www.zen.uci.edu/. A ZEN mailing list is available. To subscribe, see http://doc.ece.uci.edu/cgi-bin/mailman/listinfo/zen-users. | ||||||||||||||
| |||||||||||||||
Q: |
What is JacORB? | ||||||||||||||
A: |
JacORB is an open source Java ORB that is most often used with TAO. To learn more visit the home page or OCI's JacORB Support Page
. | ||||||||||||||
Q: |
How can I ensure that the Java JDK is using JacORB rather than its own ORB? | ||||||||||||||
A: |
Java uses a properties file called "orb.properties" to determine which ORB to use. If the Java runtime doesn't find an orb.properties file, it uses the JDK's ORB.
JacORB's orb.properties file is located in the top-level JacORB directory. Copy JacORB's orb.properties file into the Java JDK's ${java.home}/lib directory to enable JacORB. If you're not sure which directory this is, compile and run the following Java program: public class InstallHelper
{
public static void main( String[] args )
{
System.out.print("orb.properties should be copied to ");
System.out.print( System.getProperty("java.home") );
System.out.print( System.getProperty("file.separator")
+ "lib" );
}
}
A sure sign that the Java runtime is not using JacORB is that an exception is thrown, and the stack trace contains methods with the prefix "com.sun.corba".
Instead of the orb.properties file in the lib directory you can just pass the following to the virtual machine: JacORB 1.3.11 or earlier: -Dorg.omg.CORBA.ORBClass=jacorb.orb.ORB -Dorg.omg.CORBA.ORBSingletonClass=jacorb.orb.ORBSingleton JacORB 1.3.21 or later: -Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB -Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton For example: java -classpath %CLASSPATH%;C:\Java\JacORB1_3_21\lib\jacorb.jar
-Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB
-Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton
com.ociweb.appname.Main
A second alternative way to specify which ORB to use is to specify it directly in your code when you initialize the ORB. Instead of copying the orb.properties file in the ${java.home}/lib directory, put the following in your main program: JacORB 1.3.11 or earlier: java.util.Properties props = new java.util.Properties();
props.put( "org.omg.CORBA.ORBClass",
"jacorb.orb.ORB" );
props.put( "org.omg.CORBA.ORBSingletonClass",
"jacorb.orb.ORBSingleton" );
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init( args, props );
JacORB 1.3.21 or later: java.util.Properties props = new java.util.Properties();
props.put( "org.omg.CORBA.ORBClass",
"org.jacorb.orb.ORB" );
props.put( "org.omg.CORBA.ORBSingletonClass",
"org.jacorb.orb.ORBSingleton" );
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init( args, props );
| ||||||||||||||
Q: |
My TAO server publishes an object reference to my JacORB client, but the "narrow" call is failing on the client. What should I do? | ||||||||||||||
A: |
Check to see that Interface Repository Ids generated by TAO and JacORB for each interface are the same. For example, suppose you have an IDL file called "Bank.idl", with an IDL interface called "Bank". TAO generates a file called BankC.cpp; in that file, in the Bank class, there is an "_interface_repository_id" function. That function should return a string that looks something like this: "IDL:Bank: 1.0"JacORB generates a Java file called BankHelper.java. In that file, in the BankHelper class is an "id" function. It also returns a string, and that string must match TAO's _interface_repository_id string exactly: "IDL:Bank:1.0"Incidentally, both TAO and JacORB's IDL compiler support the #pragma prefix directive in IDL files. | ||||||||||||||
Q: |
Does JacORB support the "iioploc" object reference format? | ||||||||||||||
A: |
No, JacORB (as well as versions of TAO 1.1.10 and later) uses the "corbaloc" object reference format. See How do I use a "corbaloc" object reference with a TAO server?
for more information about using "corbaloc" object references between JacORB (or any client) and TAO servers.
| ||||||||||||||
Q: |
How do I use JacORB with TAO's Naming Service? | ||||||||||||||
A: |
JacORB applications can use TAO's Naming Service. Applications implemented with Java JDK 1.2 or later require a workaround to avoid using Sun's org.omg.CosNaming stubs, which are buggy. We'll use the -Xbootclasspath/p runtime option to eliminate that problem, as described below.
The steps for using TAO's Naming Service from JacORB clients are as follows:
For the sake of our example, assume JacORB is installed in /usr/don/JacORB-1_2_3. Java 1.2 or later:
java -Xbootclasspath/p:/usr/don/JacORB-1_2_3/lib/jacorb.jar
-DORBInitRef.NameService=corbaloc:iiop:myhost:9999/NameService
NSTest
Java 1.1:
java -DORBInitRef.NameService=corbaloc:iiop:myhost:9999/NameService
NSTest
Note that the host and port -- "myhost" and "9999" -- in these object references match the host and port passed into the TAO Naming Service's "-ORBEndpoint" argument.
You can also use JacORB's jacorb.properties file to set the Naming Service IOR: #
# jacorb.properties
#
ORBInitRef.NameService=corbaloc:iiop:myhost:9999/NameService
And then run the client and server without the -DORBInitRef: Java 1.2 or later:
java -Xbootclasspath/p:/usr/don/JacORB-1_2_3/lib/jacorb.jar NSTest
Java 1.1:
java NSTest
| ||||||||||||||
Q: |
I've upgraded to JacORB 1.3.21 (or later), and I'm getting an "org.omg.CORBA.INITIALIZE" exception. What's wrong? | ||||||||||||||
A: |
In JacORB 1.3.21, the prefix for all JacORB packages has been changed from "jacorb" to "org.jacorb".
The solution is to edit your orb.properties file to change this: org.omg.CORBA.ORBClass=jacorb.orb.ORB
org.omg.CORBA.ORBSingletonClass=jacorb.orb.ORBSingleton
to this: org.omg.CORBA.ORBClass=org.jacorb.orb.ORB
org.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton
Also, you must edit any script or build.xml file that refers to a JacORB class directly. | ||||||||||||||
Q: |
JacORB is using the wrong Ethernet adapter address. What should I do? | ||||||||||||||
A: |
You can inform JacORB which Ethernet adapter to use by specifing it in the jacorb.properties file (it could also be passed in on the command line). Just set the OAIAddr property to the IP address that you want JacORB to use. For example, on my Windows98 machine which has a DSL modem, JacORB was using the adapter Ethernet address
5.0.0.4 instead of the true public IP address. I modified OAIAddr property and everything worked fine. BTW you can see what address JacORB is attempting to connect to by setting jacorb.verbosity
to 2. For example: java -Djacorb.verbosity=2 -DOAIAddr=12.345.67.89 Client | ||||||||||||||
Q: |
JacORB-only Naming Service example | ||||||||||||||
A: |
A JacORB-only Naming Service example. A JacORB client uses the Naming Service to find its target object. Please see the README and the PDF file in the attached .tgz file (Windows users can use WinZip to open it).
jacorb-ns-example.tgz (3.8 K) ns-example-presentation.pdf (259.6 K) | ||||||||||||||