Java orb

• Contact Us
• Terms of Use

• Home
• Consulting
• Education
• Products
• Articles
• Careers

• Home
•    Purchase TAO Documentation
•    Product Information
•    Downloads & Links
•    Support
•       FAQ
•       Training
•       Release Notes
•       Announcements
•    Policies
•    Partner Information
•    Additional Resources
•    TAO Home

TAO FAQ

 

last updated on: 4/26/2010

Send updates, additions, and corrections to [email protected]

General
Q:	What is this FAQ about?
Q:	Where can I find the source code for the examples in the TAO Developer's Guide?;
Q:	What is the best way to start learning CORBA and TAO ?
Q:	What's the relationship between OCI's TAO and the DOC Group's TAO?
Q:	What's a PRF?
Q:	I want to ask a question about TAO; what can I do?
Q:	With which OMG CORBA specifications is TAO compliant?
Q:	How can I help extend TAO's functionality and add new features?
Q:	Why doesn't TAO support the BOA?
Q:	Is the tao-users mailing list archived anywhere?
Q:	Can I use version X of TAO with version Y of ACE?
Building Distributions of ACE and TAO (basic)
Q:	How do I obtain, configure, and build ACE and TAO on Windows with Visual C++?
Q:	How do I obtain, configure, and build ACE and TAO on Linux?
Q:	How do I generate static project files?
Q:	How can I build debug applications with non-debug libraries?
Q:	GPERF is licensed as GPL2. Will that impact my application?
OCI-Specific Issues
Q:	What's the advantage to buying OCI's Distribution of TAO?
Q:	Does the OCI documentation set include the CD, too?
Q:	If I install TAO from the OCI CD set, do I need to build it?
Q:	Are the Table of Contents and Index for the TAO Developer's Guide available on-line?
Q:	Is it possible to install debug and release versions of TAO on the same Windows machine?
Q:	Why is the TAOd.dll library I install from OCI's CD so large?
Q:	How do I get support from OCI?
Q:	Which platforms (hardware/OS combinations) are supported by OCI's Distribution of TAO?
ORB Services
Q:	I'm having weird problems with the Naming Service. How can I solve them?
Q:	How do I locate the Naming Service without resorting to multicast discovery?
Q:	Why is multicast discovery of the Naming Service failing?
Q:	Is the Naming Service server's object reference "persistent?"
Q:	How do I keep Cos Event Service consumers from blocking suppliers?
Q:	Why does my event channel get so slow when consumers die?
Q:	Does TAO's CosEvent Service support Typed Events?
Q:	What is the difference between TAO's Real-Time Event Service and the OMG Notification Service?
Security Service & SSLIOP
Q:	Is it built automatically or do I have to do something special?
Q:	What additional software do I need to install?
Q:	How do I build TAO to get security and SSLIOP?
Q:	Is it legal for me to have this? What sort of legalities are there in using this?
Q:	How I can enter the certificate password using an API rather than requiring a user to type in the password?
Q:	Why can't I make an SSLIOP connection using a DSA certificate?
Q:	How can I use a non-security enabled Naming Service with a security (SSLIOP) enabled client?
Q:	How can I make access to some objects more secure than access to others?
Boostrapping and Discovery Mechanisms
Q:	Can I use resolve_initial_references() to directly bind to my own servers?
Q:	How do I use a "corbaloc" object reference with a TAO server?
Q:	How do I make my object references persistent?
Q:	Using the Naming Service
Runtime Configuration
Q:	How do I get a TAO server to use IIOP v1.0 or v1.1?
Q:	Why is my "client" thread dispatching requests?
Q:	How can I prevent nested upcalls in my application?
Q:	What's the recommended configuration when using thread-per-connection?
Q:	How can I have some objects available to one interface and the rest available on another?
Q:	Where can I find information about run-time settings that can affect codesets and processing of multibyte character sets in TAO?
Q:	Why do I get this: ACE_DLL::open failed for TAO_Codeset?
Q:	Will TAO run without linking TAO_Codeset?
Q:	I'm not interested in using Codeset Negotiation, how can I disable it?
Q:	I'm building a statically linked application and want to statically link the codeset library.
General/Miscellaneous Questions
Q:	How can I get TAO to use a transport protocol other than TCP/IP?
Q:	Which thread does TAO use to dispatch a request?
Q:	How can I detect when a connection between a client and server is broken?
Q:	What are these CORBA::Environment parameters? Why do I get errors about pure virtual functions?
Q:	What is involved with using std library (inc stl) with ACE/TAO?
Q:	Why does ORB_init change the order of the command line arguments if we pass argv to ORB_init(argc, argv)?
Q:	Why don't signals work with the ORB's reactor?
Q:	What is TransportCurrent library used for ?
Q:	How can my TAO application obtain endpoint information (e.g., IP address and port for IIOP) of the client during a request invocation?
Q:	How can my TAO client obtain information about the endpoint (e.g., IP address and port for IIOP) it is using to send a request?
Q:	How can my TAO clients and servers communicate when the network goes down?
Q:	I am using UIOP and/or SHMIOP and I see artifacts left in the filesystem after a server crash. How do I deal with that?
Errors, and possible solutions
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?
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?
Q:	Why I am getting errors when I try to initialize the first ACE object in an application?
Q:	Why is my application leaking memory when I use local objects?
Q:	Why does my application fail when the client and server are on different hosts?
Q:	Why does my multithreaded server deadlock when I make an invocation from an event handler registered with the ORB's reactor?
Q:	How can I fix the follwing linker errors from VC71 or VC8 when using IDL sequences of basic types?
Q:	Why does one misbehaving Notification service consumer stop events to other consumers of the same channel?
Interoperability Issues
Q:	Why does Orbix 2000 reject large messages from TAO?
Q:	What ORBs does TAO interoperate with?
Q:	Is the TAO Naming Service interoperable with the JDK 1.4 beta 3 ORB?
Realtime/Performance/Embedded Systems Issues
Q:	Where can I see performance comparisons between TAO and ?
Q:	How can I minimize the sizes of the ACE and TAO libraries?
Q:	My platform doesn't have a filesystem; how can I use service configurator directives?
Q:	Running a thread pool ORB
Q:	Does TAO support request/reply timeouts?
Q:	What IDL compiler options help reduce the footprint?
Q:	How can I reduce my compile time during development?
Miscellaneous platform-specific Issues
Q:	What's the minimum set of directories I need to build to be able to develop applications with ACE and TAO?
Q:	Why can't my client connect to a server running on a wintel host with dialup networking?
Q:	What issues are involved when using MFC with ACE/TAO?
Q:	Are there any project wizards for Borland C++ Builder?
Windows-based platforms
Q:	Does OCI's version of TAO contain MFC libraries?
Q:	Why do I encounter linking errors when building Debug applications in Windows with Visual C++?
Q:	How do I export generated classes from DLLs?
Q:	Why doesn't using the Naming Service with Multicast work?
Q:	How do I link against multithreaded libraries in Visual C++?
Q:	When I use the ACE_Process_Manager to launch my process, why does the reactor fail to initialize?
Q:	Which project settings should I change to ensure acemfc.lib is built?
Q:	How do I instantiate a singleton from a DLL?
Q:	Why does my TAO application leak memory when using Windows threads?
VxWorks
Q:	I've just built the libraries and they're HUGE...how can I make them smaller?
Q:	How do I create shared libraries?
Q:	On VxWorks 6.2 upon execution I see the following error message "ERROR: input in scanner failed "?
Q:	How can I configure TAO to disregard the default configuration file 'svc.conf'?
TAO and Java
Q:	Is there a Java version of TAO?
Q:	Does TAO support a Java binding?
Q:	Is TAO interoperable with Sun's Java JDK 1.3 ORB?
Q:	Is TAO interoperable with JacORB?
Q:	How can I use TAO with Java's tnameserv?
Q:	How can I use TAO's Naming Service with my Java ORB?
Q:	What is ZEN?
TAO and JacORB
Q:	What is JacORB?
Q:	How can I ensure that the Java JDK is using JacORB rather than its own ORB?
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?
Q:	Does JacORB support the "iioploc" object reference format?
Q:	How do I use JacORB with TAO's Naming Service?
Q:	I've upgraded to JacORB 1.3.21 (or later), and I'm getting an "org.omg.CORBA.INITIALIZE" exception. What's wrong?
Q:	JacORB is using the wrong Ethernet adapter address. What should I do?
Q:	JacORB-only Naming Service example
Fault Tolerance
Q:	How do I enable Fault Tolerance features in the ORB?
Q:	Why doesn't set_primary() work even though a "primary server" is up-and-running?
Q:	Why does the client receive a failure (COMM_FAILURE) during failover to a secondary server even though the secondary server received the request from the client correctly?
Q:	Does TAO support the HEARTBEAT_POLICY?
Implementation Repository
Q:	How can I minimize the overhead of using both the IORTable and ImR?
Q:	How can I avoid losing my tagged components when I use the ImR and indirect object references?
Q:	Is it possible to register more than one object per POA with the ImR?
Q:	How can I avoid the cost of being redirected twice to my server when using the ImR?

---

General
Q:	What is this FAQ about?
A:	This isa FAQ for The ACE ORB (TAO), an open-source CORBA-compliant ORB born of researchat Washington University in St. Louis' Center for Distributed Object Computing(http://www.cse.wustl.edu/~doc/). If your question isn't answered here, you might want to check out the following links: http://www4.informatik.uni-erlangen.de/~geier/corba-faq/index.html is a general CORBA FAQ http://groups.yahoo.com/group/tao-users is an archive of the DOC Group tao-users mailing list 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 [email protected] 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 ofthe OCI TAODeveloper's Guide is available in the OCITAO source code distribution, itself. SeeACE_wrappers/TAO/DevGuideExamples/. For olderversions of TAO and the TAO Developer's Guide, thesource code for the examples can be downloaded from our website. See http://www.theaceorb.com/downloads/index.htmlfor more details.
Q:	What is the best way to start learning CORBA and TAO ?
A:	Books Advanced 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. The OCI TAO Developer's Guide, which you can purchase viahttp://www.theaceorb.com/purchase/index.html. This book picks up where the Henning and Vinoski book stops, coveringTAO specific topics as well as CORBA standard features omitted from the Henningand Vinoski book. Online The 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. You may surf and search the tao-users mailing list archives. Training Doug Schmidt teaches a course at UCLA Extension. See http://www.cs.wustl.edu/~schmidt/UCLA.html for more details. OCI offers courses on CORBA programming with C++, CORBAprogramming with Java, Advanced CORBA programming using TAO,and programming with ACE. See http://www.ociweb.com/education/services/descrip/dist for more details on these and related courses. Tutorials You can build TAO and work through the online tutorials in $TAO_ROOT/docs.
Q:	What's the relationship between OCI's TAO and the DOC Group's TAO?
A:	OCI's Distribution of TAO is signified with aletter in the version number (e.g., TAO 1.3a, TAO 1.4a),whereas DOC Group release version numbers do not include a letter(e.g., TAO 1.4, TAO 1.5). OCI patch releases also indicate apatch level (e.g., TAO 1.4a_p12), whereas DOC Group beta kitsindicate the beta number after a major release (e.g., TAO1.5.4). Each OCI release is derived from a DOC Group version (forexample, TAO 1.4a was derived from TAO 1.4.3), butan OCI release does not correspond exactly to any DOC Group release. OCI seeks to maintain extremely stable, fully-tested, opensource products backed bycommercial support,training,consulting, andaccompanied byextensivedocumentation and binaries on CD-ROM available forpurchase. Many organizationsdesire a commercially-supported release of TAO as a basis fortheir mission critical applications. The DOC Group'sprimary focus is research and developmentrather than commercial support. Support is provided on a"best effort" basis through the public tao-usersmailing list, and is often excellent. However, more"predictable" support is availble fromOCI andother organizations. OCI selects a reasonably stable DOC Group release as the basisfor each OCI distribution. OCI then builds and tests acrossover 50 combinations of hardware, operating systems, C++compilers, and build flags. As bugs are encountered, they arefixed directly (and the fix is contributed back to DOC), fixedby integrating an existing DOC fix (depending on the severityand the degree of entanglement), or documented (if a fix istoo involved to be accomplished without sponsorship). In addition, OCI applies various enhancements, sponsored by our customers. We also integrate these back into the DOC group repository. OCI also packages select binaries (custom builds are alsoavailable -- see http://www.theaceorb.com/product/index.html)and makes them available for purchase on CD-ROM. Since OCI'sdistribution of TAO is still open source, OCI also distributesthe source code and all patches free of charge (see http://www.theaceorb.com/downloads). In OCI distributions, the original DOC Group ChangeLogs are preserved;OCI changes are documented in OCIChangeLog and OCIReleaseNotes.htmlfiles, included in the source code distribution. See, for example, the latestOCI TAO 1.4a Release Notes.
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 significantlywhen you report problems using the PRF because it insures that developersand 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 tostart debugging. Unless you've got a paid support contract, there's evena 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 notjust "problems").
Q:	With which OMG CORBA specifications is TAO compliant?
A:	Compliance, just like source code and the specificationsthemselves, is a moving target. Each version of TAO iscompliant with various OMG CORBA specifications. Each version of the TAO Developer's Guideincludes an appendix that discusses compliance of that versionof TAO in detail. These appendices are available via http://www.theaceorb.com/downloads/index.html.
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 tothe terms and conditions relating to software submissions inthe ACE, TAO, CIAO, and CoSMIC copyright and licensinginformation:http://www.cs.wustl.edu/~schmidt/ACE-copying.html.In general, incorporation of your code into TAO results in it becoming "open" and the usercommunity being protected by the ACE/TAO copyright and terms. OCI can also provide consulting and software engineering resources to help youadd new functionality into TAO or to span additional platforms. We can alsomanage the inclusion of such code into the supported releases of new opensource versions of TAO. We can provide anonymity if you wish to avoid exposingyour technical strategies in public forums, where your competition may bewatching. Contact [email protected] to discuss your project. Open source software can add immeasurably to the development of arich infrastructure, and the provision of a high degree of application interoperability, from which we all may derive benefit. Readmore 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 underspecificationamong various other shortcomings. The main argument for adding BOA supportto TAO is migration of existing CORBA applications. Because the BOA is implementeddifferently by each vendor, porting to a TAO BOA would probably be the sameamount of work as porting to the POA (which provides true cross-vendor portability). All in all, applications are probably better off making the transition tothe POA.
Q:	Is the tao-users mailing list archived anywhere?
A:	Yes. You can find the tao-users archives on the web at http://groups.yahoo.com/group/tao-users/. The ace-users archive is available at http://groups.yahoo.com/group/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:	Can I use version X of TAO with version Y of ACE?
A:	Only ifX and Y were the versions of TAO and ACE that were released together. Forexample, ACE 5.1/TAO 1.1 or ACE 5.1.12/TAO 1.1.12. There is no attempt tomake 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.
Building Distributions of ACE and TAO (basic)
Q:	How do I obtain, configure, and build ACE and TAO on Windows with Visual C++?
A:	This FAQ provides basic instructions for installing andbuilding ACE+TAO for Windows with Visual C++. ACE+TAO canalso be used on other major modern operating systems, such asLinux, Solaris, AIX, and HP-UX, and some real-time andembedded operating systems, such as VxWorks, LynxOS, TimesysLinux, and Windows CE. Hardware Requirements - CPU: ACE+TAO can be configured to build on a variety of 32 and 64 bit processors (Intel, AMD) - Memory: 512 MB (more memory improves compile speed) - Hard Drive Space: 256MB swap + 500 MB up to several GB free (depending upon how much you build) Operating System Requirements - Windows 2000, 2003, XP, or Vista C++ Compiler Requirements - Microsoft Visual C++ 7.1, 8, or 9 Other Software Requirements - OCI's Distribution of TAO version 1.6a latest patch release or the latest release or micro release of ACE+TAO (see instructions below for obtaining and installing ACE+TAO) - WinZIP or similar tool for extracting software archives - ActiveState Perl v5.6.1 or newer (recommended, but not required) Obtaining and Installing ACE+TAO 1. Download the latest release of OCI TAO 1.6a (with latest patches, if available) from: http://download.ociweb.com/TAO-1.6a/ or download the latest release or micro release of ACE+TAO from: http://download.dre.vanderbilt.edu/ 2. Extract the 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: #include "ace/config-win32.h" 5. Build the Debug or Release configuration of ACE+TAO using the solution file that matches your version of Visual C++. For example, in OCI TAO 1.6a you will see the following solution files: %TAO_ROOT%\TAO_ACE.sln (Visual C++ 7.1) %TAO_ROOT%\TAO_ACE_vc8.sln (Visual C++ 8) %TAO_ROOT%\TAO_ACE_vc9.sln (Visual C++ 9) The projects in the TAO_ACE solution build the ACE and TAO libraries, TAO IDL compiler, gperf, ORB services libraries and executables, and some common utilities. They do not include any examples, tests, or performance tests. (Separate directories and solutions exist for them.) 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. 6. If you don't want to build all of the libraries and executables from the TAO_ACE solution, we recommend just building the Naming_Service project. It, and the projects on which it depends, includes most of the common ACE+TAO libraries that you need for developing your applications. 7. If the solution file you need 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 vc[version] TAO_ACE.mwc where [version] is "71", "8", or "9" for Visual C++ 7.1, 8, or 9, respectively. More information on MPC is available here: http://www.ociweb.com/products/mpc
Q:	How do I obtain, configure, and build ACE and TAO on Linux?
A:	This FAQ provides basic instructions for installing andbuilding ACE+TAO for Linux. ACE+TAO can also be used on othermajor modern operating systems, such as Windows, Solaris,AIX, and HP-UX, and some real-time and embeddedoperating systems, such as VxWorks, LynxOS, Timesys Linux, andWindows CE. Hardware Requirements - CPU: ACE+TAO can be configured to build on a variety of 32 and 64 bit processors (Intel, AMD, PowerPC) - Memory: 512 MB (more memory improves compile speed) - Hard Drive Space: 256MB swap + 500 MB up to several GB free (depending upon how much you build) Operating System Requirements - Linux 2.6.x kernel C++ Compiler Requirements - gcc 3.3.x (or later) Other Software Requirements - OCI's Distribution of TAO version 1.6a latest patch release or the latest release or micro release of ACE+TAO (see instructions below for obtaining and installing ACE+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 release of OCI TAO 1.6a from: http://download.ociweb.com/TAO-1.6a/ or download the latest release or micro release of ACE+TAO from: http://download.dre.vanderbilt.edu/ 2. Extract the 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: 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. They will not build any examples, tests, or performance tests. (Separate directories and GNUmakefiles exist for them.) 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. Note that it is possible to distinguish builds by architecture using the $ARCH environment variable. if $ARCH is set, the libs will be installed in $ACE_ROOT/lib/$ARCH. If you are using $ARCH to control the target, the value must not contain spaces. For example, "Linux" or "x86_64" are acceptible but "Linux x86_64" is not. 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 TAO_ACE.mwc More information on MPC is available here: http://www.ociweb.com/products/mpc
Q:	How do I generate static project files?
A:	If you have Perl installed, you can use the Makefile, Project,and Workspace Creator (MPC) to generate them yourself. Thesteps below, while they assume a UNIX platform, can be used (with minormodifications) on any general purpose platform. Set the MPC_ROOT environment variable to point to the MPC package location. OCI'sTAO release contains the MPC package at $ACE_ROOT/MPC. % export MPC_ROOT= Set the ACE_ROOT environment variable to the root of your ACE+TAO code base and execute thefollowing commands to generate static project files: % cd $ACE_ROOT/TAO % $ACE_ROOT/bin/mwc.pl -type gnuace -static -name_modifier *_Static TAO_ACE.mwc Substitute your build tool's type for gnuace(e.g., use -type vc71 for Visual C++ 7.1). The default configuration can be modified by customising the$ACE_ROOT/bin/MakeProjectCreator/config/default.features file.Use the $ACE_ROOT/bin/MakeProjectCreator/config/global.features file as a template. Example: The following will generate static project files for the Visual C++ 7.1 compiler on Windows: % $ACE_ROOT/bin/mwc.pl -type vc71 -static -name_modifier *_Static TAO_ACE.mwc On UNIX machines you will need to turn on the static_libs_onlyflag in $ACE_ROOT/include/makeinclude/platform_macros.GNUto build static libraries.
Q:	How can I build debug applications with non-debug libraries?
A:	During development, you will normally want to build yourapplication code with debugging enabled. However, you may beusing 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-enabledapplication can link against non-debug ACE, TAO, and CIAOlibraries. On platforms that use GNU Make, all you have to do to enabledebugging in your application is set the debugbuild flag to 1 when you build your applicationcode. You can do this by setting debug=1 on themake command line, as follows: make debug=1 Or, you can set debug=1 in yourplatform_macros.GNU file when you build yourapplication. Note: If you have debug=1 inplatform_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 modifierappended to the library name to indicate whether it was builtwith a debug, static, MFC, or some other configuration. Forexample, in a debug build, the name of the ACE shared librarywill be ACEd.dll, whereas in anon-debug (release) build, the name of the ACE shared librarywill be ACE.dll. On these platforms, if you build your application with a debugconfiguration, and you are using project files generated byMPC, the linker will, by default, look for libraries with the"d" debug modifier appended to the library name. If you arebuilding your debug application against non-debug libraries,you need to tell the linker to look for the unmodified librarynames. You can do this by directly editing the projectsettings (e.g., to remove the "d" from the library names).Or, you can use the-value_template MPC option tooverride the default definition of the library modifier whenyou generate your project files. For example, suppose your application's MPC workspace file isMyApp.mwc and suppose you are using Visual C++7.1. If you want to build your application against the sameset of non-debug ACE, TAO, and CIAO libraries, regardless ofwhether you build the debug or release configuration, you canuse the following command to generate your application'sproject and solution files: $ACE_ROOT/bin/mwc.pl -type vc71 -value_template lib_modifier= The -value_template option in the above commandsets the value of the lib_modifier templatevariable to an empty string, which causes no modifier to beadded to the library names with which your application willlink, regardless of which configuration (debug or release) youbuild. Watch out for build problems if you have any settings in yourconfig.h file that depend upon having debuggingenabled, for example: #if defined(_DEBUG) #undef __ACE_INLINE__ #endif For more information on MPC, see the MPC documentation and theMPC FAQ: http://download.ociweb.com/MPC http://www.ociweb.com/products/mpc/faq.html
Q:	GPERF is licensed as GPL2. Will that impact my application?
A:	No. TAO_IDL simply "fork/execs" a gperf process to generate the hashfunction, so it doesn't contain any GPL'd code internally, and hence isnot a derived work in the GPL sense. (Thanks to Doug Schmidt)There are no other libraries in TAO that use GPERF code, nor any other GPL code. Neither is the generated code affected by the GPL.
OCI-Specific Issues
Q:	What's the advantage to buying OCI's Distribution of TAO?
A:	Dependingupon your circumstances, there may be several advantages to buying OCI'sDistribtution of TAO rather than closely tracking the beta source code kits: Stability: OCI's Distribution of TAO is based on a stable, tested, andsupported release of TAO. If you need a solid, consistent version ofTAO on which to base your product or project, this is the one for you.If you need to stay abreast of new research directions or want to tryout the latest features, you can still obtain TAO beta kits in sourcecode form by visiting http://download.dre.vanderbilt.edu/. Time Savings: Buying and installing a prebuilt binary distribution of TAO, ratherthan downloading source code and building it yourself, can save youhours of work. In addition, you can be sure that it has been builtcorrectly and tested across several platforms, operating systems, andcompilers, and in several different configurations. Installation Support: OCI provides 90 days of installation support for registered purchasersof prebuilt binary distributions of TAO. We want to make sureyou are up and running with TAO as quickly as possible. Documentation: Using OCI's Distribution of TAO is easy with OCI's TAO Developer's Guide (available for purchase athttp://www.theaceorb.com/purchase/index.html).In addition to the documentation set, you can view the latest TAO release notes at http://www.theaceorb.com/releasenotes/index.html. Frequently Asked Questions: OCI maintains a list of frequently asked questions about TAO. Thislist is updated regularly by our staff of distributed object computingtechnology engineers to provide answers to common questions aboutusing TAO. Anyone in the TAO user community can contribute questions(and answers) to the FAQ. Check it first to see if your question hasbeen asked before. The FAQ is located at http://www.theaceorb.com/faq/ Professional Support: If you need further support, beyond installation issues or frequentlyasked questions, such as object technology training, consulting,mentoring, or application development, OCI has several serviceofferings for you. Visit http://www.ociweb.com for more information.
Q:	Does the OCI documentation set include the CD, too?
A:	No, it does not. The documentation set only includes OCI's ownTAODeveloper'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 includespre-built libraries for ACE, TAO, and TAO's CORBAservices, plus executables for TAO's IDL compiler, gperf, and servers for thevarious 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 sourcecode 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 configurationwhich 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 Guideare available in PDF form via: http://www.theaceorb.com/downloads/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 Windows machine?
A:	It ispossible to install both debug and release versions of TAO on one Windows machineby selecting a different installation directory for each installation andsetting $ACE_ROOT and $TAO_ROOT appropriately. More efficienty, the debugand release versions of TAO can be installed in the same directory sincethe different versions of the libraries have slightly different names.
Q:	Why is the TAOd.dll library I install from OCI's CD so large?
A:	The DLLson the CD include all the information you need to debug TAO applications. This information is normally stored by Visual C++ in .pdb files. Our buildsstore them in the .dll in a location independent manner (using the C7 compatibleoption for the debug information). This allows you to step into TAO codein the Visual C++ debugger. If you desire a smaller set of libraries, either install the releaseversions of the CD or rebuild the debug libraries with the default debugconfiguration.
Q:	How do I get support from OCI?
A:	You're always welcome to send a question. However, the disposition of yourrequest depends upon whether or not you have a technical support contractwith OCI: If you have a technical support contract with OCI,someone will begin addressing the issue and will followup with you according to the provisions outlined in yoursupport contract. If you do not have a technical support contract with OCI,someone will still review the support request and may getback to you, but we cannot guarantee that we will havetime to work on the problem without a support contract. If you would like to open a technical support contract withOCI, please contact our sales staff at [email protected] call +1.314.579.0066 extension 206. Please consulthttp://www.theaceorb.com/support for a descriptionof the TAO support model.
Q:	Which platforms (hardware/OS combinations) are supported by OCI's Distribution of TAO?
A:	A full list of platforms (and other support details) is available at http://www.theaceorb.com/support/index.html.
ORB Services
Q:	I'm having weird problems with the Naming Service. How can I solve them?
A:	More thanlikely you're having problems related to multicast discovery of the NamingService. Multicast was the default mechanism for finding theNaming Service in older versions of TAO. Symptoms rangeanywhere from a client not being able to find the NamingService at all, to 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 without resorting to multicast discovery?.
Q:	How do I locate the Naming Service without resorting to multicast discovery?
A:	Here are some common ways to use the -ORBInitRef option to locate the NamingService (where bart is just an example host name): # Store the IOR of the Naming Service'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: Naming_Service -m 0 -ORBListenEndpoints iiop://bart:2809 client -ORBInitRef NameService=corbaloc:iiop:bart:2809/NameService You can also use the NameServiceIOR environment variable to achieve thesame effect. Here, we show what it might look like on a UNIX or UNIX-likesystem using the bash shell: Naming_Service -m 0 -ORBListenEndpoints iiop://bart:2809 export NameServiceIOR=corbaloc:iiop:bart:2809/NameService Now, when your client calls resolve_initial_references("NameService"), nomulticast will be performed. The -m 0 option turns multicast off in theNaming_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:	Therecan be a myriad of reasons, many related to network or OS-level issues ratherthan TAO. Try turning on -ORBDebugLevel 5 to get some sense of what mightbe happening internally. If you're using Windows, 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'simplementation of the OMG Naming Service always creates a persistent IORfor the root Naming Context. That is to say, it creates the object referencein a POA that has the PERSISTENT life span policy. Thus, you can use theIOR across invocations of the Naming Service provided that the service alwaysstarts up on the endpoint used when creating the original reference. Use the -ORBListenEndpoints option to specify that the servershould start on a specific endpoint, e.g., Naming_Service -ORBListenEndpoints iiop://bart:2809 The general form is: Naming_Service -ORBListenEndpoints iiop://name_server_host:name_server_port For more detailed information on using the-ORBListenEndpoints option, see the TAO Developer's Guide For more information on direct binding of persistent objectreferences, see Henning's and Vinoski's Advanced CORBA Programming with C++, 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 threadthat received it from the supplier. When suppliers publish or emit events,they do so using a two-way invocation. When the event channel delivers anevent, 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-waypublication invocation) while the consumers process the event. This behaviorcan be avoided by directing the event channel to use a separate dispatchingthread for the push to the consumers. This is accomplished differently dependingon which COS EC is being used. When using the "native" COS EC, the -CECDispatching option can be used tochange 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 channelserver can be started with the following command: CosEvent_Service_Native -ORBSvcConf ec.conf The -CECDispatchingThreads option is used to control the number of threadsused for consumer deliveries. When using the COS EC that wraps the RTEC (which is the only COS EC in olderversions of TAO), the same effect can be accomplished by using the analogousoptions on the RTEC (-ECDispathing and -ECDispatchingThreads on the EC_Factory). For more information about these and other event channel options, see theTAO Developer's Guide, 14.8 and the online documentation at $TAO_ROOT/docs/cec_options.htmland $TAO_ROOT/docs/ec_options.html.
Q:	Why does my event channel get so slow when consumers die?
A:	By defaultthe event channels (Cos and RTEC) in TAO continue to attempt to push newevents at consumers even after previous pushes to that consumer have failed.If a particular consumer is destroyed without disconnecting from the eventchannel, then all subsequent pushes by the corresponding supplier proxy willfail. Since each of these require the ORB to timeout, they can drasticallyaffect the throughput of the EC. You can modify this behavior via the -ECSupplierControl and -ECConsumerControloptions. The consumer control option sets the strategy used to deal withill-behaved consumers. Put the following in a service configurator optionfile (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 disconnectionof that consumer (and its proxy) from the event channel. The reactive strategyalso polls all the consumers periodically and disconnects them if they failto 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 CosEvent Service support Typed Events?
A:	Yes, as of TAO 1.3.4. See $TAO_ROOT/orbsvcs/examples/CosEC/TypedSimple for asimple example using Typed Events.
Q:	What is the difference between TAO's Real-Time Event Service and the OMG Notification Service?
A:	The NotificationService is an implementation of the OMG's Notification Service specification,which originally came out of the Telecommunications working group withinthe 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 priorto the adoption of the OMG Notification Service specification. The RT EventService was designed to meet the real-time and quality of service needs ofcertain sponsors of the DOC group, but has applicability in a wide varietyof domains. On the surface, the two services provide several similar features,though the specifics of their interfaces and implementations are quite different: similar communications model support for structured events filtering of events support for subscriptions mechanisms for specifying QoS requirements support for delivery of sequences of events In addition, the RT Event Service provides some features that are notpart of the Notification Service, such as event channel federations, eventcorrelation, suspension and resumption of consumer connections, and integrationwith a scheduling service. The RT Event Service is older and perhaps more "mature" in thatit has been through multiple iterations of development and is in active useby many real world applications. However, the Notification Service is alsoquite 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.
Security Service & SSLIOP
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 https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/TAO/docs/Security/SSLIOP-INSTALL.html?view=co. See also the "TAO Security" chapter of the TAO Developer's Guide
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 goodsoftware, but it takes a mind far more twisted than ours to understand USExport 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.bis.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 dothis. However, you can set a password callback function by manuallyusing the OpenSSL functions. For example, something like thefollowing should work: SSL_CTX *ctx = ACE_SSL_Context::instance ()->context (); // SSL_CTX_set_default_passwd_cb() is from OpenSSL. SSL_CTX_set_default_passwd_cb (ctx, your_callback); where "your_callback" is a pointer to your PEM passwork callbackfunction. See and for the requiredcallback 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.pem This 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" // Open the file with the DH parameters FILE * fp = fopen ( "cert.pem", "r" ); // Read in the DH parameters from the open file DH * dh_params = PEM_read_DHparams ( fp , NULL, NULL, NULL ); // Obtain the SSL Context so we can set the DH parameters for it SSL_CTX * ssl_ctx = ACE_SSL_Context::instance()->context(); // Set the DH Parameters for the SSL Context SSL_CTX_set_tmp_dh ( ssl_ctx , dh_params ); 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 securityis enabled in a CORBA client's ORB, all invocations will be attempted usinga secure connection. However, the Naming Service for example may not beset up to use security. Invocations on that Naming Service will result ina CORBA::INV_POLICY exception since the client is unable to make a secure/protectedinvocation on that non-security enabled Naming Service. To correct thisproblem, protected invocations via the Naming Service's object referencemust be disabled. This is achieved by setting a policy override on the NamingService's object reference like so: // Disable protection on Naming Service invocations. Security::QOP qop = Security::SecQOPNoProtection; CORBA::Any no_protection; no_protection <<= qop; // Create the Security::QOPPolicy. CORBA::Policy_var policy = orb->create_policy (Security::SecQOPPolicy, no_protection); CORBA::PolicyList policy_list (1); policy_list.length (1); policy_list[0] = CORBA::Policy::_duplicate (policy.in ()); // Get a reference to Naming Context CORBA::Object_var obj = orb->resolve_initial_references ("NameService"); // Create an object reference that uses plain IIOP (i.e. no // protection). CORBA::Object_var unprotected_obj = naming_context_object->_set_policy_overrides (policy_list, CORBA::SET_OVERRIDE); // Narrow to a CosNaming::NamingContext CosNaming::NamingContext_var naming_context = CosNaming::NamingContext::_narrow (unprotected_obj.in ()); 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 allORBs that support the SecurityLevel2::QOPPolicy quality-of-protection client-sidepolicy. Don'tforget to include "orbsvcs/SecurityC.h" (this is TAO-specific) to pull inthe Security QoP policy related constants and types.
Q:	How can I make access to some objects more secure than access to others?
A:	Use the Security service's AccessDecision interface. This is available in via TAO/orbsvcs/orbsvcs/SecurityLevel2.idl. An example of using this interface is provided in TAO/orbsvcs/Security/mixed_security_test. The AccessDecision interface gives the ability to weaken the security requirements for designated object references. Show here, its single operation is intended to be called from an interceptor, or perhaps from within a servant. module SecurityLevel2 { local interface AccessDecision { # pragma version AccessDecision 1.8 boolean access_allowed ( in SecurityLevel2::CredentialsList cred_list, in Object target, in CORBA::Identifier operation_name, in CORBA::Identifier target_interface_name ); }; }; TAO also extends this interface in order to allow for runtime configuration of the supplied AccessDecision object, for adding or removing objects for consideration. module TAO { module SL2 { local interface AccessDecision : SecurityLevel2::AccessDecision { /* TAO-specific access_allowed that works around deficiencies in the SecurityLevel2::AccessDecision::access_allowed() operation. */ // Parameter object_id should be PortableInterceptor::ObjectId, but // using that type would require including the PI_Forward.pidl file. // By using the real type, we can avoid that dependency. boolean access_allowed_ex (in ::CORBA::ORBid orb_id, in ::CORBA::OctetSeq adapter_id, in ::CORBA::OctetSeq object_id, in ::SecurityLevel2::CredentialsList cred_list, in ::CORBA::Identifier operation_name); /*! Default value returned when a reference is not in the list. */ // Can't come up with a good name for this. attribute boolean default_decision; /*! Establish whether a particular object can be accessed via insecure means. */ void add_object (in ::CORBA::ORBid orb_id, in ::CORBA::OctetSeq adapter_id, in ::CORBA::OctetSeq object_id, in boolean allow_insecure_access); void remove_object (in ::CORBA::ORBid orb_id, in ::CORBA::OctetSeq adapter_id, in ::CORBA::OctetSeq object_id); }; }; }; In addition to adding operations for adding or removing object references for consideration by the AccessDecision object, an extended access allowed operation is also provided, to work around a deficiency in comparing object references. For TAO, serialized object references cannot be used for comparison because they are produced using CDR encoding. This encoding uses padding bytes for alignment of multibyte values, and the padding bytes are uninitialized, meaning they will contain random data, and thus cannot be used when comparing two serialized object references. Typically, your application will initialize the AccessDecision object by supplying it with information used to unambiguously identify the object reference, and rely on the built-in interceptor to make the call to access_allowed. TAO's security interceptor, supplied as part of the TAO_Security library, will first check with the AccessDecision object to see if unrestricted access is allowed, and if not will then evaluate the request based on the regular secure access rules. It is possible to implement your own AccessDecision object to provide even greater control, such as restriction based on the content of the supplied credentials, and even on a per-operation level. To use the AccessDecision interface, you must first obtain a reference to the Level 2 Security Manager from the ORB. From that you get the AccessDecision, and finally narrow that to a TAO::SL2::AccessDecision reference. #include int main (int argc, char *argv[]) { CORBA::ORB_var orb = ORB_init(argc,argv); CORBA::Object_var obj = orb->resolve_initial_references("SecurityLevel2:SecurityManager"); SecurityLevel2::SecurityManager_var secmgr = SecurityLevel2::SecurityManager::_narrow (obj.in()); SecurityLevel2::AccessDecision_var ad = sl2sm->access_decision (); TAO::SL2::AccessDecision_var tao_ad = TAO::SL2::AccessDecision::_narrow (ad.in ()); //... At this point, you supply object references for consideration. It is best to do this when you are creating the references so that you don't have to keep track of the required information. PortableServer::ObjectId_var oid = rootpoa->servant_to_id (server2); CORBA::OctetSeq_var poaid = rootpoa->id(); CORBA::String_var orbid = orb->id(); sl2ad->add_object (orbid.in(), poaid.in(), oid.in(), true); At this point, you are ready to go, the AccessDecision::access_allowed operation effectively adds a -SSLNoProtection SSLIOP attribute only on those object references you added to the AccessDecision object.
Boostrapping and Discovery Mechanisms
Q:	Can I use resolve_initial_references() to directly bind to my own servers?
A:	Insteadof binding object references with the Naming Service and requiring clientsto resolve them by name, you can make it possible for clients to directlybind to objects using CORBA::ORB::resolve_initial_references(),the samemechanism 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'scall it "CORBABank"). Rather than binding this object by name in a namingcontext in the Naming Service, you would like clients to access it directlyby simply calling orb->resolve_initial_references("CORBABank"); There are several ways to accomplish this. Directly bind the object reference into the client ORB's list of references using an ORB initializer and the ORBInitInfo::register_initial_references() function. Use the client ORB's register_initial_reference() member function. Use the -ORBInitRef ORB initialization option on the client ORB The following steps describe one way to use the 3rd method described above. In the server, generate an IOR for the target object as usual. Give the CORBA Object a simple object key by registering its IOR in the server ORB's IOR Table (See How do I use a "corbaloc" object reference with a TAO server? for details) Start the server listening on a particular endpoint using the -ORBListenEndpoints option. Start the client with the -ORBInitRef option and assign the service name to the simple corbaloc-style reference of the CORBA Object. In the client, call resolve_initial_references() and pass it the service name. The combination of the simple object key and the fixed endpoint allows usto reference the object via a corbaloc-style reference in the-ORBInitRef option. For example, we can start our processes as follows: server -ORBListenEndpoints iiop://bart:10200 client -ORBInitRef CORBABank=corbaloc:iiop:bart:10200/BankObject Where BankObject is the simple object key assigned to the CORBA objectin the server. Now, on the client side, we can useresolve_initial_references("CORBABank")to directly bind to the Bank object living inside the Bank server.For example: // 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 theInteroperable 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. Priorto that, TAO supported an earlier version of the specification that usedthe iioploc format. You can use corbaloc references to contact servers builtwith any version of TAO (assuming the client ORB supports them). To simplify use if corbaloc object references, youcan register your CORBA object in the server ORB's IOR table soit can be located via a simple object key. To bind an object reference tothis 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 referencesto locate the specified CORBA object via a simple object key ("CORBABank"). The Bank's object reference doesn't necessarily have to be a persistentobject reference, but it can be. For more information on persistent objectreferences, see How do I make my object references persistent?. When we run the TAO server, we must ensure that it listens on a hostand port that are known to the client. We use TAO's-ORBListenEndpoints command-line option to do this. The format of -ORBListenEndpoints is -ORBListenEndpoints iiop://host:port For example, if I'm running my server on host "myhost", listening on port 11019: server -ORBListenEndpoints iiop://myhost:11019 When running the client, we'll use a "corbaloc" object reference. The format of the "corbaloc" object reference is corbaloc:protocol:host:port/ObjectKey For example: corbaloc:iiop:myhost:11019/CORBABank connects to the server on host "myhost" at port 11019, and findsthe object reference in that servercorresponding to the "CORBABank" key. This object reference can be passedto ORB::string_to_object() and then is used like anyother object reference.
Q:	How do I make my object references persistent?
A:	In CORBAterminology a transient object reference is one that is only good for thelifetime of a given server's execution. If you run a server, distributea transient reference to a client, and then kill the server, then the objectreference is now useless (even if the server is restarted). A persistentreference allows you continue to use the reference even if the server isrestarted. In order to make your object references persistent you must do the following in your server: Create a child POA with the PERSISTENT and USER_ID policies. Create an ObjectId for each servant using PortableServer::string_to_ObjectId(). Activate the object in the child POA using activate_object_with_id(). Start the server listening on a particular endpoint using the -ORBListenEndpoints option. All of this is standard CORBA except for step 4, which requires an ORB-specificoption. An alternative to step 4 is to use the Implementation Repository. 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 invokethe Bank's server, we need to specify a particular endpoint for the ORB. For example: BankServer -ORBListenEndpoints iiop://bart:10200 Now, any clients that receive these object references can use them betweendifferent runs of the server. Note, that you still need to manually restartthe server, unless you use the Implementation Repository.
Q:	Using the Naming Service
A:	The Naming Service is a common boostrapping/discovery mechanism. The following FAQ's address the naming service: I'm having weird problems with the Naming Service. How can I solve them?, How do I locate the Naming Service without resorting to multicast discovery?, Why is multicast discovery of the Naming Service failing?, Is the Naming Service server's object reference "persistent?"
Runtime Configuration
Q:	How do I get a TAO server to use IIOP v1.0 or v1.1?
A:	You mustuse the -ORBListenEndpoints option. For further details, please refer to the TAODeveloper's Guide, the chapter on "ORB Initialization Options." Alternatelyrefer to $TAO_ROOT/docs/Options.html. The short answer is: -ORBListenEndpoints iiop://V.v@[hostname:[port]] The V.v@ portion of this syntax informs the server to use a specificmajor and minor version of the specified protocol. For example, to forcea server to use IIOP v1.1 (instead of the default v1.2) on a host named "barney"at port 22000: -ORBListenEndpoints iiop://1.1@barney:22000 If you always want to force use of IIOP 1.0 or 1.1, you can set thefollowing macro values and rebuild TAO (and your application): #define TAO_DEF_GIOP_MAJOR 1 #define TAO_DEF_GIOP_MINOR 0 [or 1] These macros are typically set in $TAO_ROOT/tao/orbconf.h or $ACE_ROOT/ace/config.h. Correction to the "-ORBListenEndpoints" syntax. It should be: -ORBListenEndpoints iiop://1.0@[host][:port] The hostname is not always required.
Q:	Why is my "client" thread dispatching requests?
A:	By default,TAO attempts to efficiently use all the threads that are given to it. Thisincludes "client" threads that have sent a request and are waiting for areply from the server. While waiting, these threads enter the normal threadpool reactor event loop. This means that any incoming requests (assumingthat the process is also a server) may be dispatched using that thread. Sucha situation is referred to as a "nested upcall". This has a couple of side effects that surpise many people. First,it is possible for even a single threaded server to process more than onerequest at the same time. Second, if you try to allocate threads exclusivelyas "server" threads and "client" threads, the ORB will pay no attention toyour idea of what these threads are and dispatch requests on both. Why is this the default behavior of TAO? Mainly because nested upcalls avoidmany potential deadlock situations. One example is a simple callback operationwith 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'sonly thread is waiting for the reply and not dispatching incoming requests,then a deadlock is now in place. The default behavior allows the clientORB to process the callback request and send a reply to the server whichfrees the server ORB to send its reply back to the client. There however are situations where you may wish to prevent nested upcallsin your application. Some common reasons are: Real-time applications which impose strict response times. Resource limitations which impose concurrency limitations. Short response time. The response will be buffered until the nested upcallunwinds. Recursive nested upcalls may lead to unbounded stack growth, which willeventually crash the application. See entry How can Iprevent nested upcalls in my application? for techniques to prevent nested upcalls.
Q:	How can I prevent nested upcalls in my application?
A:	As discussed in entry Why is my "client" threaddispatching requests? there are situations when we may want todisable nested upcalls in our application. There are several techniques availableto prevent nested upcalls. These are: Use the Receive-Wait(RW) wait strategy. Employ the Two-ORB solution. The RW wait strategy is the most popular and probably theeasiest mechanism to prevent nested upcalls. You can modify the default clientwait strategy via the-ORBWaitStrategy (formerly known as the-ORBClientConnectionHandler)service configurator option.Specifying an "rw" wait strategy causes threads waitingfor replies to not enter the normal event loop and instead block for theirpending reply. This keeps the ORB from dispatching incoming requests onyour "client" threads. One side effect of this option is that your clientis now more susceptible to deadlocks as discussed in Why ismy "client" thread dispatching requests?. Here are the requireddirectives (each directive should appear on one line): static Client_Strategy_Factory "-ORBWaitStrategy rw -ORBTransportMuxStrategy exclusive -ORBConnectStrategy blocked -ORBConnectionHandlerCleanup 1" static Resource_Factory "-ORBFlushingStrategy blocking" Note that you should always set the-ORBTransportMuxStrategy to exclusive, the-ORBConnectStrategy to blocked, the-ORBFlushingStrategy to blocking and the-ORBConnectionHandlerCleanup to 1 when usingthe rw wait strategy. Also note that -ORBConnectionHandlerCleanup is not available in versions of TAO prior to 1.4a_p11. The reason for using exclusivetransport multiplexing is that you must not allow another request tobe sent over a connection if that connection is already being used byanother thread that is waiting for a reply. The blocking connect andflushing strategies are required because the event handler for aconnection used to send a request is not registered with the ORB'sReactor. The Connection Handler Cleanup strategy needs to be enabled toproperly cleanup server side connection closure. Finally, it is important when using -ORBConnectionHandlerCleanup that the ORB event loop be run, at least periodically. The connection handler cleanup option works by using some internal reactor-based messaging. If this option is used and the ORB's event loop is not run, the application will eventually deadlock. The Two-ORB technique relies upon all outbound invocations being made from adesignated 'client ORB'. This will prevent the client threads from entering the'server ORB' thread-pool and hence don't get dispatched for nested upcalls.To make sure invocations on object references always go throughthe "client" ORB, just make sure those object references arealways demarshalled using the client ORB. This can get tricky.For example, if you receive an IOR for a callback object as anin parameter to an operation, it will have been demarshalledthrough the "server" ORB (the one that received the request).To force the IOR to be demarshalled via the "client" ORB, youhave to play some trick like this: // Assume the callback's IOR is in a Callback_var called cb. // First, "remarshal" the callback IOR using the "server" ORB. CORBA::String_var cbstr = server_orb->object_to_string(cb.in()); // Then, demarshal it using the "client" ORB. CORBA::Object_var new_ior = client_orb->string_to_object(cbstr.in()); // Finally, narrow it to the derived interface type // (can reuse cb). cb = Callback::_narrow(new_ior.in()); Now, when your application makes an invocation on the callbackIOR, it will be sent via the "client" ORB, where it cannot be dispatchedfor nested upcalls. Note: Both Two-ORB and RW wait strategy are incompatible with BiDirectional GIOP.
Q:	What's the recommended configuration when using thread-per-connection?
A:	If you wish to use the thread-per-connection server-side concurrency model, a few other settings should also be present in your svc.conf file. Below is an example of this (each directive should appear on one line): static Server_Strategy_Factory "-ORBConcurrency thread-per-connection" static Client_Strategy_Factory "-ORBWaitStrategy rw -ORBTransportMuxStrategy exclusive -ORBConnectStrategy blocked -ORBConnectionHandlerCleanup 1" static Resource_Factory "-ORBFlushingStrategy blocking" Note that -ORBConnectionHandlerCleanup is not available in versions of TAO prior to 1.4a_p11. The rationale behind these settings is as follows: in thread-per-connection a thread is dedicated to servicing requests that come in on a given connection. In order to keep this thread dedicated to its connection, we need to prevent the thread from entering the reactor or the leader-follows pool even in the event that the thread attempts to make a request on a remote object (see the Client_Strategy_Factory settings) or cannot write a large reply back to the socket all at once (the -ORBFlushingStrategy setting). This is closely related to the use of the RW wait strategy in order to prevent nested upcalls.
Q:	How can I have some objects available to one interface and the rest available on another?
A:	There are two key techniques you can use in this situation. You can use multiple ORBs, or you can use a single ORB and use the TAO-specific endpoint policy to filter endpoints on a per-POA basis. The two ORB approach works by passing separate endpoint collections defined with "-ORBEndpoint " to the different ORB_init calls used to initialize each ORB. This way, each ORB will listen their own endpoints and their POAs will only produce object references containing the endpoints associated with the ORB. The trade-off is that each ORB must run its own event loop, and each ORB must create its own root POA along with other resources. The endpoint policy approach allows you to have a process with a single ORB, and thus a single event loop and a single POA hierarchy, and still be able to have some POAs create object references containing a subset of the endpoints owned by the ORB. To see an example of the endpoint policy in action, look at TAO/tests/POA/EndpointPolicy. The endpoint policy implementation is stored in libTAO_EndpointPolicy. If you are using MPC to manage your build environment, have your server project inherit the "endpointpolicy" base project. Somewhere in your application code, you must #include "tao/EndpointPolicy/EndpointPolicy.h". The endpoint policy is initialized using protocol-specific valuetype containers. For each protocol you use in your application, you must also include the definition for the endpoint value. For example, use #include "tao/EndpointPolicy/IIOPEndpointValue_i.h" to include the IIOP-specific endpoint valuetype definition. The policy value for the endpoint policy is a list of endpoints. This way you may supply more than one endpoint value, even for different protocols, to the same endpoint policy. The constructor for IIOP-specific endpoint values takes a hostname and a port number. EndpointPolicy::EndpointList list; list.length (1); list[0] = new IIOPEndpointValue_i("localhost", endpoint_port); CORBA::Any policy_value; policy_value <<= list; Endpoint policy instances are created the way any other custom policy might be, using the ORB's create_policy() operation. CORBA::PolicyList policies; policies.length (1); policies[0] = orb->create_policy (EndpointPolicy::ENDPOINT_POLICY_TYPE, policy_value); Unlike other POA related policies, this policy is applied to a POA manager. This is done via the POAManagerFactory interface. PortableServer::POAManagerFactory_var poa_manager_factory; poa_manager_factory = root_poa->the_POAManagerFactory (); PortableServer::POAManager_var good_pm; good_pm = poa_manager_factory->create_POAManager ("goodPOAManager", policies); You then use this POAManager when you create POA instances. This POA manager is also the one on which you call activate to set all the related POAs to the active state. policies.length(0); PortableServer::POA_var good_poa = root_poa->create_POA ("goodPOA", good_pm.in (), policies); good_pm->activate (); At this point any object references created by the "goodPOA" will contain only the endpoints specified on the list given to the "goodPOAManager". Important Note: The endpoint policy works to select endpoints that were previously passed to the ORB with the -ORBEndpoint or -ORBListenPoints ORB_init options. If you supply any endpoint values to the policy that do not match any of the ORB's endpoints, this by itself will not cause a failure, but that endpoint will be included in any object references. If none of the endpoint values given to the policy match the endpoints known to the ORB, the POA will throw an exception when attempting to create an object reference.
Q:	Where can I find information about run-time settings that can affect codesets and processing of multibyte character sets in TAO?
A:	This is documented in various places: $TAO_ROOT/docs/options.html Sections of OCI's TAO Developer's Guide on -ORBNegotiateCodesets, -ORBNativeCharCodeset, -ORBNativeWCharCodeset, -ORBCharCodesetTranslator, -ORBWCharCodesetTranslator Information about the MPC feature negotiate_codesets (also covered in the TAO Developer's Guide) Other entries in this FAQ on codesets
Q:	Why do I get this: ACE_DLL::open failed for TAO_Codeset?
A:	Codeset negotiation is an optional feature for TAO. It is implemented in aseparate shared library, libTAO_Codeset.so, or TAO_Codeset.dll on Windows.Typically, TAO is not explicitly linked to the codeset library, rather itrelies on the ACE Service Configuration framework to load the library for it. The error in question is reported when ACE cannot find the Codeset library inthe LD_LIBRARY_PATH, or the runtime PATH on Windows. While most error orwarning reports such as the one in question are guarded by a log-level test,this one is not, because the code in question is often used in staticinitializers, which are called before a log-level determination can be made.
Q:	Will TAO run without linking TAO_Codeset?
A:	Yes. However it will not participate in Codeset negotiate with other ORBs.If you are in a mixed environment where you are mixing, say, Unicode, UTF-8,or various Asian codesets, you will have problems with character interchange.
Q:	I'm not interested in using Codeset Negotiation, how can I disable it?
A:	You may disable the codeset negotiation feature completely by passing-ORBNegotiateCodesets 0 to ORB_init. When this is done, the TAO_Codeset libraryis not loaded, thus saving the memory and messaging overhead of codesetnegotiation. TAO may also be built with codeset negotiation off by default. This is done byediting ACE_wrappers/ace/config.h and adding #define TAO_NEGOTIATE_CODESETS 0 This will set the internal default to not load the codeset library, but thiscan be overridden by supplying -ORBNegotiateCodesets 1 to ORB_init.
Q:	I'm building a statically linked application and want to statically link the codeset library.
A:	This may be done via MPC. Edit$ACE_ROOT/bin/MakeProjectCreator/config/default.features file to add the line: negotiate_codesets = 1 This will explicitly add TAO_Codeset to the link line of your application.Somewhere within the body of your code, you must also add#include "tao/Codeset/Codeset_Factory.h"
General/Miscellaneous Questions
Q:	How can I get TAO to use a transport protocol other than TCP/IP?
A:	TAO includes a "pluggable" transport protocol frameworkthat allows the ORB to be configured to work over transportsother than TCP/IP. In fact, the standard Internet Inter-ORBProtocol (IIOP) is implemented in TAO as a pluggable transportprotocol that is based on TCP/IP. Besides IIOP, TAO comeswith several alternate transport protocol implementations,including: Unix Inter-ORB Protocol (UIOP), which is based on Unix Domain Sockets (or local IPC) Shared Memory Inter-ORB Protocol (SHMIOP), which uses shared memory as a transport. Datagram Inter-ORB Protocol (DIOP), which uses UDP for efficient message transfer in limited circumstances. Secure Sockets Layer Inter-ORB Protocol (SSLIOP), which is based on SSL. Multicast Inter-ORB Protocol (MIOP), implemented atop Unreliable IP Multicast (UIPMC). Hypertext Inter-ORB Protocol (HTIOP), which uses HTTP tunneling. Stream Control Transmission Protocol Inter-ORB Protocol (SCIOP), which is based on SCTP (IETF RFC 2960). Currently, the UIOP, SHMIOP, DIOP, and SCIOP implementationsare all found in $TAO_ROOT/tao/Strategies/ andthe TAO_Strategies library. SSLIOP is implemented in theTAO_SSLIOP library in$TAO_ROOT/orbsvcs/orbsvcs/SSLIOP/, MIOP/UIPMC in theTAO_PortableGroup library in$TAO_ROOT/orbsvcs/orbsvcs/PortableGroup/, andHTIOP in the TAO_HTIOP library in$TAO_ROOT/orbsvcs/orbsvcs/HTIOP/. The use of the underlying transport protocol is completelytransparent to the application. In fact, the ORB can actuallybe configured to use more than one transport protocolsimultaneously. If one of the above built-in transport protocols does not meetyour needs, you may need to implement one yourself. If donecorrectly, it should require no changes to the TAO core. Useone of the existing pluggable transport protocolimplementations as guidance. Using and developing pluggable protocols is documented indetail in the TAO Developer's Guide.
Q:	Which thread does TAO use to dispatch a request?
A:	The answer to this depends on a number of conditions: If the client is collocated with the servant and collocation is enabled,then the request is serviced on the client's thread. Collocation can bedisabled via the option: -ORBCollocation no If the client is not in the same process as the servant (or collocationis disabled), then the concurrency strategy of the servant's ORB determinesthe servicing thread. By default, this is the same thread where orb->run()or orb->perform_work() is called. You can also specify a thread-per-connectionmodel via the -ORBConcurrency option and a threadpool model by using thethread pool reactor. See https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/TAO/docs/Options.html?view=co 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 [email protected]) You cannot directly detect when this happens. You could write a pluggableprotocol that informs your application when a connection dies, but that'sabout it. Typically behind this question is the issue: how can I detect ifmy client died. Using connections for that is a very bad idea: the clientor server ORBs may close the connection just because it is idle for too longor there may not be a physical connection between two ORBs (they may be collocatedor using shared memory to communicate). There can also be multiple connectionsbetween a given client-server pair. In CORBA, connections are hidden, andcan come and go as needed. Trying to rely on them to establish if the clientis still there does not work. In general you are better off using some application-level sessionobject that gets destroyed by the client when it terminates gracefully, andthat gets destroyed by an Evictor if it has been idle or unable to contactthe client for too long.
Q:	What are these CORBA::Environment parameters? Why do I get errors about pure virtual functions?
A:	The CORBA::Environment parameters are part ofthe alternate exception mapping defined by the OMG's IDL toC++ language mapping specification. Normally, CORBAexceptions are mapped to C++ exceptions. The mapping alsoallows CORBA to be used when C++ exceptions are unavailable orundesirable by passing exception information via an extraparameter of type CORBA::Environment. TAOversions up to 1.5.1 support both mappings and you can buildACE/TAO to support either mapping by passingexceptions=0 or exceptions=1 to GNUmake or by defining the macro ACE_HAS_EXCEPTIONS. If you build TAO to use native C++ exceptions, the IDLcompiler, by default, does not include theCORBA::Environment parameters. If you build withthe alternate mapping, the IDL compiler includes theCORBA::Environment parameter by default. You canexplicitly tell the IDL compiler what to do with the-Ge option (-Ge 1 includes the extraparameter, -Ge 0 omits it). You need to generatethe skeleton classes in a manner that is compatible with yourservant classes or you will receive compiler errors aboutabstract classes or pure virtual functions. For more information about Exceptions and TAO, see the ErrorHandling chapter of the TAO Developer's Guide.
Q:	What is involved with using std library (inc stl) with ACE/TAO?
A:	There are several conditional directives that are relevant: ACE_HAS_STANDARD_CPP_LIBRARY -- Causes ACE to #include the standard librarieswhere appropriate instead of older style runtime libraries, or defining its own equivalent. (ie instead of or instead of creating its own auto_ptr) ACE_USES_STD_NAMESPACE_FOR_STDCPP_LIB -- This causes ACE to define "using std::xxx" for all the std classes it uses. I've never messed with this one, so I'm not sure of all the ramifications. I notice that it is defined by default for most (all?) windows compilers. ACE_HAS_STDCPP_STL_INCLUDES -- This seems to be used only in ace/IOStream.h.It causes ACE to use instead of . It's not defined for VC++, but is for some other win32 compilers. I've never used this one either. In practice, I typically define ACE_HAS_STANDARD_CPP_LIBRARY, and use stl andother std objects in my code. You can still use std library functions and objects without defining ACE_HAS_STANDARD_CPP_LIBRARY, but it can be a hasslebecause of duplicate definitions. (e.g. std::cout & cout are different, so you have to explicitly use std:: most places, and you can't use them interchangeably) In practice it is fairly common to use ACE_HAS_STANDARD_CPP_LIBRARY. I alwaysuse 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 canbe a portability issue.
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 andefficiently 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 callCORBA::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's reactor?
A:	Signals and the ORB reactor: By default ACE uses the ACE_Select reactor, which works withsignals. TAO defaults to use the thread pool (TP) reactor, which doesnot currently work with signals. See DOC Bug 1031: http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=1031 The call ACE_Reactor::instance() returns an ACE_Select_Reactor.The call TAO_ORB_Core_instance()->reactor() returns anACE_TP_Reactor. Another possible approach for handling signals in a TAOapplication that uses the default TP reactor would be to spawn a separate thread and use ACE_OS::sigwait() to handle the signals.
Q:	What is TransportCurrent library used for ?
A:	It provides an implementation of an interface(Transport::Current) for obtaining common transportinformation and an implementation of IIOP specific interface (Transport::IIOP::Current) for obtainingIIOP specific transport information. On the other hand it also is a framework for implementingtransport-specific plug-ins (for querying specific transport, other than IIOP). Please see $TAO_ROOT/docs/transport_current/index.html for description of the Transport Current feature.
Q:	How can my TAO application obtain endpoint information (e.g., IP address and port for IIOP) of the client during a request invocation?
A:	The TransportCurrent(see What is TransportCurrent library used for ?) library provides the IIOP specific interface (TAO::Transport::IIOP::Current) and implementation. The TAO::Transport::IIOP::Current interfaceprovides access to the information of the local and remote endpoints. Here is an example to obtain endpoint information via TAO::Transport::IIOP::Current interface. // Get the IIOP Current object. CORBA::Object_var tcobject = orb->resolve_initial_references (ACE_TEXT_ALWAYS_CHAR ("TAO::Transport::IIOP::Current")); Transport::IIOP::Current_var tc = Transport::IIOP::Current::_narrow (tcobject.in ()); if (CORBA::is_nil (tc.in ())) { ACE_ERROR ((LM_ERROR, ACE_TEXT ("Tester (%P|%t) ERROR: Could not resolve ") ACE_TEXT ("TAO::Transport::IIOP::Current object.\n"))); throw CORBA::INTERNAL (); } // Access the host and the port of the remote endpoint. ::CORBA::String_var rhost (tc->remote_host ()); ::CORBA::Long rport = tc->remote_port (); // Access the host and the port of the local endpoint. ::CORBA::String_var lhost (tc->local_host ()); ::CORBA::Long lport = tc->local_port (); Note the transport information is only available on server-side at interception points or inside a servant up-call. Specifically, the code above must be calledwithin interceptor hooks(e.g. receive_request_service_contexts(), receive_request(),send_reply() and etc.) or inside a servant implementation method. To use the Transport Current features, the TransportCurrent library must be loaded via Service Configurator, or be statically linked . Here is an example of the Service Configuration file. dynamic TAO_Transport_Current_Loader Service_Object * TAO_TC:_make_TAO_Transport_Current_Loader() "" (Note that this has been split across lines for the purpose of display on this web page. The actual service configuration file should have the above contents all on one line.) One could achieve the same, by using -ORBSvcConfDirective with theabove as a parameter.
Q:	How can my TAO client obtain information about the endpoint (e.g., IP address and port for IIOP) it is using to send a request?
A:	The TAO::Transport::IIOP::Current interface can be used to obtain information about the local and remote endpoints. Please see example code in How can my TAO application obtain endpoint information (e.g., IP. Similar code can be used by the client to obtain information about the endpoint used to send a request. Note since the transport information is only available on client side at interceptor points (within send_request, send_poll(), receive_reply(), receive_exception() and receive_other ()), TAO must be built with support for interceptors if the client side needs Transport::Current functionality.
Q:	How can my TAO clients and servers communicate when the network goes down?
A:	Assuming that the clients and servers are local to one machine, it ispossible by using "localhost". For instance, you could have a Name Servicerunning that is listening on the ethernet adapter and localhost: Naming_Service -ORBListenEndpoints "iiop://hostname:11223;iiop://localhost:11223" If the network for "hostname" goes down, this Name Service could still beaccessed by a server running locally using the following: server -ORBInitRef NameService=corbaloc:iiop:hostname:11223,iiop:localhost:11223/NameService Regardless of the state of the network on which "hostname" is registered, theserver will be able to communicate with the Name Service due to thelocalhost endpoint.
Q:	I am using UIOP and/or SHMIOP and I see artifacts left in the filesystem after a server crash. How do I deal with that?
A:	UIOP uses filesystem tokens to identify endpoints. By default these are named /tmp/TAOsomething, but they can also be whatever you specify. When your server ORB is shut down, it will clean up the token associated with any UIOP or SHMIOP transport. However on a crash, the endpoint token remains in the filesystem, and will cause a re-run of the server to fail. SHMIOP uses a filesystem entry per connection which serves as the shared memory identifier. If you are using a well known UIOP endpoint, such as /tmp/my_uiop_endpoint, you can simply delete the named file in your server startup, before invoking CORBA::ORB_init(). This is easily done using ACE_OS::unlink("/tmp/my_uiop_endpoint"). When using generated endpoints, the files to clean up are anmed /tmp/TAO*. As long as you have no other servers running with UIOP, then just delete all instances of /tmp/TAO*. Otherwise you can use the catior (or tao_catior if catior isn't found) to determine which of the /tmp/TAO* rendesvous points are still active. Identifying leftovers from a crashed SHMIOP session is a little more difficult. The default name for the identifier is /tmp/MEM_Acceptor_port_uniqueid where port is the port number used for the connection establishment and the uniqueid is something that futher distinguishes a specific instance of the connection. For example /tmp/MEM_Acceptor_55957_0x65754014330. The SHMIOP Factory takes a "-MMAPFilePrefix=..." option to override the use of /tmp/MEM_Acceptor_. As with the UIOP endpoints, you can simply delete these files from your filesystem after a crash. Also like UIOP, these temporary files are cleaned up when the connection is successfully closed.
Errors, and possible solutions
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., ACE.dll), and its path appears in the library search path before $ACE_ROOT/lib from your build tree, you will have run-time link errors. The run-time linker tries to link your program against the first occurrence of the library that it finds in the library search path. 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 ldd command on Linux and Unix can be very helpful in tracking down where the out-dated library is located.) To correct the problem, ensure that $ACE_ROOT/lib comes first in the library search path. On Windows, you will need to restart your terminal windows and development environment. 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 determiningthe endpoint for a server, TAO chooses an interface from the interfaces availableto 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 anyother suitable interfaces. Since this address is only visible to local machine,no other machine will be able to connect to the local machine through thataddress. If there are dynamic interfaces that are available to the system,you may need to explicitly specify that TAO should use that interface withthe -ORBListenEndpoints command line option: -ORBListenEndpoints 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. You should also be sure to call ACE::fini() at the end of your application's use of ACE. When you include ACE/TAO headers from the file containing the main() function, the ACE::init() function is called automatically for you at the start of main(). ACE::init() initializes the ACE Object Manager, and must be called before initializing or using any ACE/TAO objects. When you only use ACE/TAO from libraries that are dynamically linked, you may need to explicitly call ACE::init() beforehand. Also, you will need to call ACE::fini() to close down the ACE Object Manager at the end of your application's use of ACE/TAO (e.g., at an exit point from the code in your library).
Q:	Why is my application leaking memory when I use local objects?
A:	It is likely that your objects are using reference counting to managetheir life cycle. The CORBA::LocalObject class provides an emptyimplementation of the _add_ref() and _remove_ref() methods. However, theTAO_Local_RefCounted_Object implements real reference counting through thesemethods. The solution to your memory leak may be as simple as inheriting fromTAO_Local_RefCounted_Object instead of CORBA::LocalObject.
Q:	Why does my application fail when the client and server are on different hosts?
A:	When anapplication works with the client and server on the same host, but failswhen they are on different hosts, the usual culprit is some sort of namingproblem between the hosts. One simple way to test this is to use the pingcommand 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 usedecimal addresses (i.e. 128.252.120.1) instead of host names. You can dothis by passing -ORBDottedDecimalAddresses 1 viaargv[] to CORBA::ORB_init() in each processof your application. Note that you need to do this for every CORBA server inyour system. Because many client applications are also CORBAservers, it is best to use this option for all processes. Assuming yourcode passes command line options toCORBA::ORB_init(), you can do this from the command line: server -ORBDottedDecimalAddresses 1 client -ORBDottedDecimalAddresses 1 Even if this works, you still probably want to get your system administratorsto fix the naming problems. If you want to always force use of decimal addressesadd the following to your $ACE_ROOT/ace/config.h: #define TAO_USE_DOTTED_DECIMAL_ADDRESSES 1 Note: In recent versions of TAO, on Windows, the default is touse dotted decimal addresses rather than hostnames. You may also run into the problem described in this questionif your server happens to be listening on the addressassociated 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 tolocalhost.localdomain. Thus, when your clienttries to resolve the hostname, it resolves it correctly butconnects to itself rather than the host on which theserver is actually running. Use catior (in $TAO_ROOT/utils/catior) to "peek inside" your TAO-generatedIORs; if you see localhost.localdomain (or something similar) in the output,then you might have this problem! Use the-ORBListenEndpoints option (also called the-ORBEndpoint option) to specify the hostname onwhich the server should listen for requests (and, thus, thehostname that it encodes in the IORs it generates). The -ORBListenEndpoints option takes manyarguments and modifiers. See https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/TAO/docs/ORBEndpoint.html?view=coand the TAODeveloper's Guide for more details on the the-ORBListenEndpoints option. Thanks to Tim Fry for posting to the tao-users mailing list the raw material from which this entry was created.
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 select() system call. To fix this problem, you have to abide by the LF protocol. Do the following within your event handler code (e.g., in handle_timeout() or the other handle_* methods): 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 "tao/ORB_Core.h" and "tao/LF_Strategy.h" in your code to get the above code to compile cleanly. Also, when you make the above calls, remember to use the ORB within whose reactor you registered your event handler. Thanks to Milan Cvetkovic for reporting the problem and to Balachandran Natarajan 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. See Why is my "client" thread dispatching requests? for more information. 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 fix the follwing linker errors from VC71 or VC8 when using IDL sequences of basic types?
A:	If you see the following (or similar) linker errors... TAO.lib(TAO.dll) : error LNK2005: "public: void __thiscall TAO::unbounded_value_sequence::length(unsigned int)" ([mangled name removed]) already defined in fooC.obj ...and the IDL file foo.idl contains a typedef of a sequence of basic types like so... (basic types are types defined by the OMG IDL spec like string, long, etc.) typedef sequence MyULongList; ...the problem is that both your library or exe (from fooC.obj) and TAO.dll are exporting the same class (instantated from the sequence template). Until and unless this issue is fixed for good in the IDL compiler (see DOC group bugzilla entry 2703), use one of the following work-arounds: Instead of typedef'ing your own MyULongList, use CORBA::ULongSeq or similar. Add #include (which includes tao/ULongSeq.pidl) to the top of your IDL file, or just the include statement for the sequence type(s) that you are using (such as tao/ULongSeq.pidl). Either of these work-arounds will force the compiler, when building fooC.obj from fooC.cpp, to see the exported class in the TAO library's headers and avoid re-exporting it.
Q:	Why does one misbehaving Notification service consumer stop events to other consumers of the same channel?
A:	The channel's global queue was filled by the bad consumer. When the MaxQueueLength admin property is set on a channel without setting MaxEventsPerConsumer QoS property or setting MaxEventsPerConsumer >= MaxQueueLength then a single slow/misbehaving consumer's queue can fill up the entire channel's queue. The full channel queue results in no events getting queued for some or all of the remaining consumers. The events that are not enqueued can result in a memory leak. When setting the MaxQueueLength admin property, set the MaxEventsPerConsumer QoS property to a value less than the MaxQueueLength.
Interoperability Issues
Q:	Why does Orbix 2000 reject large messages from TAO?
A:	(as related by Balachandran Natarajan [email protected]) 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 theirconfiguration file. The policy is policies:iiop:buffer_sizes_policy:max_buffer_size = "-1";
Q:	What ORBs does TAO interoperate with?
A:	Thereare 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 helpdocument and debug the problem). Other ORB implementors also fix these problemsquite quickly when they are brought to their attention. There is no definitive list of ORBs that a particular version of TAOworks with. Here are some ORBs that users have reported successfully usingwith TAO in the past: Orbix (3.x, 2000) Visibroker JacORB OpenORB Sun JDK ORB ORBExpress INTERSTAGE CorbaScript Orbacus ZEN MICO OmniORB There are probably others.
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 usethe 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 ); } } }
Realtime/Performance/Embedded Systems Issues
Q:	Where can I see performance comparisons between TAO and ?
A:	It's notas easy to compare the performance of ORBs as generically as one might compare,e.g., the performance of microprocessors. There are no standard benchmarksavailable at the present. Thus, any evaluation of performance of an ORBis largely dependent on the application and its characteristics as well asthe environment in which it's running (such as over an ATM network vs. ethernetvs. wireless, etc.). That said, you might be able to get a betterfeeling of the situations in which various ORBs "shine" (performance-wise)by looking at some of the benchmarks available through the following links: Distributed Systems Research Group, Charles University, Prague Dan Kegel's CORBA Page LMCO Advanced Technology Labs' Middleware Comparator Finally, don't forget that nothing comes without a cost, so carefullyevaluate the entire ORB package, not just the performance.
Q:	How can I minimize the sizes of the ACE and TAO libraries?
A:	Thereare several ways to minimize the sizes of the ACE and TAO libraries, at leastin UNIX. They are described briefly here. More details can be found inthe TAO Developer's Guide. Note that all of these solutions are applied at compile time, so if youobtained OCI's Distribution of TAO as pre-built binaries onCD, you will need to re-compile. Turn off debugging. To turn off the generation of extra debugging information in thelibraries, use the debug=0 make flag when building the ACE, TAO, and orbsvcslibraries. You can do this in your$ACE_ROOT/include/makeinclude/platform_macros.GNU file by puttingdebug=0 in the file or when you invoke the makecommand (e.g., make debug=0). Build only the ACE components needed for TAO. By default, all the ACE components are compiled and included in theACE library. But, TAO depends upon only a subset of ACE. To build onlythose components needed for TAO, setACE_COMPONENTS=FOR_TAO either as anenvironment variable or in yourplatform_macros.GNU file. Build only the "Minimum CORBA" features. The TAO library can be built according to the "Minimum CORBA" specificationby excluding support for certain features such as DII, DSI, DynAny, and ServantManagers. To select the Minimum CORBA subset of TAO, definethe TAO_HAS_MINIMUM_CORBApreprocessor macro in $ACE_ROOT/ace/config.h, orset minimum_corba=1 in yourplatform_macros.GNU file, or passminimum_corba=1 on the GNU make commandline. Use the "soreduce" tool to build a minimal set of shared librariesfor your application. "soreduce" allows you to reduce the sizes of theACE and TAO libraries by including only the object files that containsymbols used by the relevant executables. "soreduce" generates MPC filesthat can be used to build subsetted versions of the ACE/TAO libraries. For more information on soreduce, see$ACE_ROOT/apps/soreduce/README. IMPORTANT You should use the size command instead of measuring the size ofeach library file on disk (e.g., with ls -l) to get a more accurate measureof the true size of the code in the library. The ls -lcommand reports the size of the library file ondisk (which can be very large) while the size command("dec" column, which is the total of the "text", "data", and "bss" columns,in decimal) reports the run-time size, which will be muchsmaller. (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 reportedby ls -l,is actually somewhat irrelevant to the run-time size of your executable, forthe following reasons: If you are linking statically, most linkers will link into theexecutable only those parts of the library (the .o's) that you areactually using in your application. If you are linking dynamically, the entire shared library will beloaded into memory, but it will be shared across all processes runningon that host that are using the library. So, you only take the memoryhit for the library once. Also, even in a shared library situation, you are not likely to havethe entire library resident at once. Most modern operating systemswill page portions of the library file in and out of memory as neededby processes. 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 embeddedsystems don't have filesystems, which really puts a cramp in using the svc.conffile and its directives (e.g., for the Resource_Factory). However, you can pass Service Configurator directives on the "commandline" using the -ORBSvcConfDirective (Section 7.4 in the TAO Developer'sGuide). 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 trickis 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 incomingrequests. 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, suchas 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 anyother 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 invokeORB::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 thesvc() method to run the orb, and then use the activate method to start thedesired number of threads. For example: class my_ORB_Pool : public ACE_Task { 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:	TAOsupports the Relative Roundtrip Timeout policy as defined in the CORBA Messagingspecification (OMG Document formal/04-03-12, Chapter 22). This policy allows you tospecify the maximum time allowed (in 100 nanosecond units) for a requestto 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 requestingthread, 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 Timeoutpolicy to a value of 1 millisecond (that is 1.0e-3 * 1.0e7 in 100 nanosecondunits) 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 policies; pols.length(1); policies[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 (policies, CORBA::SET_OVERRIDE); All requests made via this ORB will now timeout if a reply is not receivedwithin 1 millisecond. When a timeout occurs, the ORB will raise a CORBA::TIMEOUTsystem exception. The client can then take whatever action is necessaryto handle the failure. If a reply eventually arrives after the timeout periodhas expired, it will be discarded by the client ORB. The Relative Roundtrip Timeout policy, and other Quality of Servicepolicies defined as part of the CORBA Messaging specification, are describedin more detail in the OCI TAO Developer's Guide, CORBA Messaging chapter, available fromhttp://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 -Sa Suppresses generation of Any insertion/extraction operators, and generates certain portable interceptor operations that use Anys as dummies -St Suppresses type code generation. Since Anys depend on type codes, this options also does what -Sa does. -Gt Generate optimized typecodes. All the string names in a type code except the repository id will be null with this option. This optimization is allowed by the, CORBA spec, but it may cause problems when trying to determine type code equivalence. -Sc Suppresses tie class generation. -Sp Suppresses the generation of thru-POA collocated stub code. -Sd Suppresses the generation of direct collocated stub code. Direct collocation stub code generation is disabled by default, but the option is included for completeness. -Sv Suppresses code generation for valuetypes. Code generation for valuetypes is disabled by default, but the option is included for completeness. 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 ittakes to compile your software by not enabling you compiler's optimizerflags. These often take the form -O. Disabling optimization for your application will come at the cost of runtime performance, so you should normally only do this duringdevelopment, keeping your test and release build optimized. Disable Inlining: When compiler optimization is disabled, it is frequently the case thatno inlining will be performed. In this case the ACE inlining will beadding to your compile time without any appreciable benefit. You cantherefore decrease compile times further by build building yourapplication with the -DACE_NO_INLINE C++ flag. In order for code built with -DACE_NO_INLINE to link, you will need tobe using a version of ACE+TAO built with the "inline=0" make flag. In order to accommodate both inline and non-inline builds of yourapplication it will be necessary to build two copies of your ACE+TAOlibraries, one with inlining and one without. You can then use yourACE_ROOT and TAO_ROOT variables to point at the appropriateinstallation.
Miscellaneous platform-specific Issues
Q:	What's the minimum set of directories I need to build to be able to develop applications with ACE and TAO?
A:	One commonway to build ACE and TAO (once you have your configuration set up) is tosimply run "make" in the $ACE_ROOT directory, then run "make" again in the$TAO_ROOT directory. However, running "make" from $ACE_ROOT not only buildsthe ACE library, it also builds all of the examples, tests, and other thingsyou may not need. Likewise, running "make" from $TAO_ROOT builds not onlythe TAO and orbsvcs libraries, it also builds all the TAO and orbsvcs testsand 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 onlythe 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 theIDL compiler), tao_idl executable, ACEXML library, protocol libraries (extensionsof 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, soyou probably should also add these directories to the list of directoriesin 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 subtleproblems. For instance, you typically can't use an MFC wrapper object createdin one thread in another. (By wrapper object, I mean those that wrap windowshandles. CDC, CWnd, ...) (The typical solution is to pass the handles betweeenthreads.) --- In summary, if you find that you really do need to make MFCcalls from ACE threads then use the MFC build of the ACE library, howeverit is typically not necessary because the layer of software using ACE/TAOis often separated from the layer using MFC.
Q:	Are there any project wizards for Borland C++ Builder?
A:	Yes, Christopher Kohlhoff ([email protected]) has developed these and made them available at http://www.tenermerx.com/programming/corba/tao_bcb/using/index.html.
Windows-based platforms
Q:	Does OCI's version of TAO contain MFC libraries?
A:	MFC Libraries are libraries built with the ACE_HAS_MFC variabledefined. 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:	Why do I encounter linking errors when building Debug applications in Windows with Visual C++?
A:	If you're linking debug versions of an executable or DLL and have unresolved symbols, there are several possible reasons: Is your library path correct? (Check Tools|Options|Directories|Libraries or your project settings.) Are you linking in the ACE, TAO, and possibly orbsvcs libraries? (Check Build|Settings|Link) Are you linking with the right library names? If you are building your application against a Debug configuration of ACE+TAO, the names of the libraries will have the letter "d" in them (e.g., aced.lib, TAOd.lib, CosNamingd.lib). If you are using a Release configuration of ACE+TAO, the "d" will not be present in the library names. Have you installed or built the Debug configuration of ACE+TAO? If you have only installed the non-Debug version of TAO, you will not be able to build Debug executables. To check this, do one of the following: Build the Release configuration of the executable; or Remove _DEBUG from the list of preprocessor definitions. If the build succeeds, then you probably have a non-Debug version of TAO.
Q:	How do I export generated classes from DLLs?
A:	Accordingto the TAODeveloper's Guide, TAO IDL Compiler chapter, section on "Back End Options",the way to export generated classes is as follows: Create an export header file using the perl script%ACE_ROOT%\bin\generate_export_file.pl: generate_export_file.pl Foo > FooExport.h Use the -Wb,export_macro and-Wb,export_include options to the TAO IDLcompiler to include the macros in the generated class declarations: tao_idl -Wb,export_macro=Foo_Export -Wb,export_include=FooExport.h Foo.idl In the project settings, C/C++ tab, preprocessor options,include FOO_BUILD_DLL in the list of definitions. (If you use MPC to generate your project settings, the laststep is done for you automatically.) See the TAODeveloper's Guide for more information and examples.
Q:	Why doesn't using the Naming Service with Multicast work?
A:	At leaston some versions of Windows, there's a bug in which the TTL (Time-to-Live) field in multicastIP packets is set to zero. Thus, nobody pays attention to those packets. This particular problem bit OCI in their training lab environment, and forthis reason we now use the Naming Service without multicasting as documentedin the TAO Developer's Guide (see How do I locate the Naming Service without resorting to multicast discovery?). 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:	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:\WINDOWS 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: From the "Build" pull down menu choose "Set Active Configuration...". In the Configuration popup choose the appropriate (Debug or Release) MFC configuration. Batch build: Go to the Build pull-down in MSC++ and select the Batch Build option. When the batch build window pops up select the ACE MFC build option and deselect all the other options. This will build the acemfc.lib for you. Using batch build option you can build all the flavors of the various ACE and TAO libraries you need.
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: Use generate_export_file.pl (found in ACE_wrappers/bin) to generate the proper Win32 export directives for your dll. For example, "perl generate_export_file.pl MyLib >MyLib_Export.h" generates the following output in the file "MyLib_Export.h": // -*- C++ -*- // generate_export_file.pl,v 1.8 2001/03/04 09:16:29 nanbor Exp // Definition for Win32 Export directives. // This file is generated automatically by generate_export_file.pl // ------------------------------ #ifndef MYLIB_EXPORT_H #define MYLIB_EXPORT_H #include "ace/config-all.h" #if !defined (MYLIB_HAS_DLL) # define MYLIB_HAS_DLL 1 #endif /* ! MYLIB_HAS_DLL */ #if defined (MYLIB_HAS_DLL) && (MYLIB_HAS_DLL == 1) # if defined (MYLIB_BUILD_DLL) # define MyLib_Export ACE_Proper_Export_Flag # define MYLIB_SINGLETON_DECLARATION(T) \ ACE_EXPORT_SINGLETON_DECLARATION (T) # define MYLIB_SINGLETON_DECLARE(SINGLETON_TYPE, CLASS, LOCK) \ ACE_EXPORT_SINGLETON_DECLARE(SINGLETON_TYPE, CLASS, LOCK) # else /* MYLIB_BUILD_DLL */ # define MyLib_Export ACE_Proper_Import_Flag # define MYLIB_SINGLETON_DECLARATION(T) \ ACE_IMPORT_SINGLETON_DECLARATION (T) # define MYLIB_SINGLETON_DECLARE(SINGLETON_TYPE, CLASS, LOCK) \ ACE_IMPORT_SINGLETON_DECLARE(SINGLETON_TYPE, CLASS, LOCK) # endif /* MYLIB_BUILD_DLL */ #else /* MYLIB_HAS_DLL == 1 */ # define MyLib_Export # define MYLIB_SINGLETON_DECLARATION(T) # define MYLIB_SINGLETON_DECLARE(SINGLETON_TYPE, CLASS, LOCK) #endif /* MYLIB_HAS_DLL == 1 */ #endif /* MYLIB_EXPORT_H */ // End of auto generated file. When declaring your singleton, make sure and use the right export directive that you generated for your dll. For instance, if you create a class that is meant to be a singleton in MyLib.dll, you'd typically do this: class MyLib_Export MyClass { }; typedef ACE_Singleton MY_CLASS_SINGLETON; MYLIB_SINGLETON_DECLARE(ACE_Singleton, MyClass, ACE_Null_Mutex);
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 Win32threads, the underlying type system does not invoke destructors onTSS and the application will leak memory.To get around this problem, please use ACE threads wherever possible. Thanks to for supplying this FAQ!
VxWorks
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 alldepends 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 youbuilt the defaults, then the first thing you need to do is understand thatthe size of the file is NOT the same as the size of the code. When compilingwith debug information, the compiler adds symbol information to the libraries,and that symbol information is massive. What you need to do is look atthe code size. Using the WindRiver GNU toolchain, you can use sizeppcto do this, e.g., $ 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. The "size" results can be compared to the available memory on the target system. Use both the "memShow" and "adrSpaceShow" commands from the target-resident VxWorks shell to see how much memory is available. There are various strategies for making the libraries smaller, and all involve rebuilding. Specifically, you can build: nodebug (debug=0) which will eliminate symbols and debugging messages minimumCORBA, which will only compile functionality specified by the Minimum CORBA specification ACE only for TAO, which will only compile the portions of ACE required by TAO An often-usedtechnique for keeping library sizes small and still debuggable is to buildthe entire library nondebug, then only build the pieces you need to debugwith debug on. This allows you to debug those pieces, but not suffer throughthe problems that large file sizes in libraries cause (e.g., longer download/boottimes). Here is a shortcut to rebuilding a lib with debug=0.But: It doesn't remove debugging statements. You have to be careful to not remove relocation symbols on VxWorks, so that you can load the lib. For example, use something like stripppc --strip-unneeded, or strip386 --strip-debug stripppc is broken on Tornado 2, Windows host. It won't let you create the output file, so it's not of any use.
Q:	How do I create shared libraries?
A:	Sharedlibraries on VxWorks aren't really shared libraries. If you ever workedon Unix in the days before shared libraries, you might remember "relocatableobject files", i.e., object files created by the linker with many of theirsymbols 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: You should not use "-lACE" when linking libTAO.so, then try toload both libACE.so and libTAO.so. This will lead to duplicate symbols becausethe creation of libTAO.so will resolve all the ACE symbols. Thus, when youload libTAO.so after having loaded libACE.so, you will, effectively, loadall the symbols in libACE.so again (they're in libTAO.so, too). Similar to the previous point, you should not link libACE.so or libTAO.so into your application. A command line to create a shared library on VxWorks might look like: $ make shared_libs_only=1 ACE_SHLIBS= The ACE_SHLIBS make macro usually contains the names of shared librariesto link in, such as "-lTAO -lACE", etc. By making it empty, these do notget linked.
Q:	On VxWorks 6.2 upon execution I see the following error message "ERROR: input in scanner failed "?
A:	This message indicates that the service configurator failed to read the configuration file for some reason. On VxWorks 6.2 we have seen this message because of a bug in the NFS V2 driver wherein the driver returns a corrupt file handle when opening a non-existent file. If a config file hasn't been specified, the service configurator tries to open the default config file 'svc.conf'. Trying then to read in from the returned corrupt file handle results in the above message. This issue is documented in defect #55808. A fix for this is documented this whcih requires a kernel rebuild. A quick work around is to create a dummy svc.conf file. Another workaround is How can I configure TAO to disregard the default configuration file 'svc.conf'?.
Q:	How can I configure TAO to disregard the default configuration file 'svc.conf'?
A:	In the past this was done by setting 'fakesvcconf =1' in the platform_macros.GNU. However this has been deprecated in 1.5a. The current recommendation is to define TAO_PLATFORM_SVC_CONF_FILE_NOTSUP in $ACE_ROOT/ace/config.h. This is also backwards compatible with 1.4a and 1.3a.
TAO and Java
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 isa C++ ORB. Any other CORBA compliant ORB can interoperate with TAO (as wellas 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 optionalstandard profile components in IORs generated by TAO. To do so, use thefollowing ORB initialization option with TAO servers that generate IORs thatwill be used by Java 1.3 ORB clients: -ORBStdProfileComponents 0 Thanks to Gordana and Kate Matic [email protected] for posing the original question and Carlos O'Ryan [email protected] for providing the answer.
Q:	Is TAO interoperable with JacORB?
A:	Yes, TAO is interoperable with JacORB. In fact, severalversions of both TAO and JacORB have been tested together overthe last several years.
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.] Suppose that you have a CORBA application written with TAO, and you wantto use the Java naming service implementation (tnameserv): $ 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 applicationusing 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 implementthe Interoperable Naming Service specification (doubtful at the moment),you could use: $ app -ORBInitRef NameService=corbaloc:iiop:host:port/NameService In 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_OBJREFin resolve_initial_references("NameService"). There's a file called NS_Resolve.java in $TAO_ROOT/examples/Simulator/DOVEBrowser that containscode 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 mechanismand connect your Java application to it directly. For an example which usesTAO and JacORB, see How do I use JacORB with TAO's Naming Service?
Q:	What is ZEN?
A:	ZEN isa real-time Java ORB being developed by the Distributed Object Computinggroups at the University of California, Irvine and Washington Universityin 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.
TAO and JacORB
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 usesa 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'sORB. 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 directoryto enable JacORB. If you're not sure which directory this is, compile andrun 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 exceptionis thrown, and the stack trace contains methods with the prefix "com.sun.corba". An alternative way to specify which ORB to use is to specify it directly to the Java runtime. Instead of the orb.properties file in the lib directory you can just passthe 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 returna 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 returnsa string, and that string must match TAO's _interface_repository_id stringexactly: "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:	JacORBapplications can use TAO's Naming Service. Applications implemented withJava JDK 1.2 or later require a workaround to avoid using Sun's org.omg.CosNamingstubs, which are buggy. We'll use the -Xbootclasspath/p runtime option toeliminate that problem, as described below. The steps for using TAO's Naming Service from JacORB clients are as follows: Start TAO's Naming Service, specifying a well-known listening endpoint $TAO_ROOT/orbsvcs/Naming_Service/Naming_Service \ -ORBListenEndpoints iiop://myhost:2809 Write your JacORB Naming Service clients as you normally would, usingorb.resolve_initial_references("NameService") to find the Naming Service. import org.omg.CORBA.ORB; import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; public class NSTest { public static void main(String args[]) { try{ ORB orb = ORB.init(args, null); org.omg.CORBA.Object o = orb.resolve_initial_references( "NameService" ); NamingContext rootNC = NamingContextHelper.narrow( o ); // ...etc... } catch ( Exception e ) { System.err.println("ERROR : " + e) ; e.printStackTrace( System.err ); } } } Run your Java application using the -ORBInitRef command-line optionto tell JacORB where to find the Naming Service. If the Java applicationis implemented using Java JDK 1.2 or later, then the -Xbootclasspath/p optionwill be needed to use JacORB's CosNaming stubs instead of the Sun's. 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:2809/NameService NSTest Java 1.1: java -DORBInitRef.NameService=corbaloc:iiop:myhost:2809/NameService NSTest Note that the host and port -- "myhost" and "2809" -- in these object referencesmatch the host and port passed into the TAO Naming Service's "-ORBListenEndpoints"argument. You can also use JacORB's jacorb.properties file to set the Naming Service IOR: # # jacorb.properties # ORBInitRef.NameService=corbaloc:iiop:myhost:2809/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-onlyNaming Service example. A JacORB client uses the Naming Service to findits 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)
Fault Tolerance
Q:	How do I enable Fault Tolerance features in the ORB?
A:	Make sure the FTORB library is loaded. See $TAO_ROOT/orbsvcs/tests/FaultTolerance/IOGR/svc.conf or svc.conf.xml for an example. Note: The FT CORBA capabilities of TAO are still under development. The information in this category is subject to change. The status of TAO's Fault Tolerance support is summarizedhere.
Q:	Why doesn't set_primary() work even though a "primary server" is up-and-running?
A:	Make sure Fault Tolerance features have been enabled in the ORB. See How do I enable Fault Tolerance features in the ORB?
Q:	Why does the client receive a failure (COMM_FAILURE) during failover to a secondary server even though the secondary server received the request from the client correctly?
A:	If you use the FTORB library, request/retry should be transparent to the application. If you don't use the FTORB library, you will not get the transparent behavior. See How do I enable Fault Tolerance features in the ORB?
Q:	Does TAO support the HEARTBEAT_POLICY?
A:	No, not yet.
Implementation Repository
Q:	How can I minimize the overhead of using both the IORTable and ImR?
A:	Simply register a direct object reference with the IORTable instead of the indirect one.To obtain the direct object reference you must call a special version of POA::id_to_reference():TAO_Root_POA* tpoa = dynamic_cast(poa.in());bool use_indirect = false;Object_var obj = tpoa->id_to_reference_i(oid.in(), use_indirect);String_var direct_ior = orb->object_to_string(obj.in());ior_table->bind("POAName/ObjectName", direct_ior.in());
Q:	How can I avoid losing my tagged components when I use the ImR and indirect object references?
A:	While we don't have an example to showcase this problem, it should be possible to register a direct object reference with the IORTable, as discussed above, to work around this problem.
Q:	Is it possible to register more than one object per POA with the ImR?
A:	This is a trick question, because the ImR doesn't know anything about your object references. Any objects activated in a persistent POA will automatically use indirect object references (assuming -orbuseimr 1). However, if you want to support corbaloc URLs such as those generated using "tao_imr ior" then you will need to additionally register your IORs in an IORTable in the server. This is actually completely orthogonal to whether your object references are indirect. However, you *can* avoid unnecessary additional performance overhead by registering *direct* IORs in your IORTable.Here's a short example that registers two objects with one POA. const char* poa_name = "MessengerService"; POA_var poa = createPersistentPOA(root_poa.in(), poa_name); Messenger_i servant1, servant2; ObjectId_var id1 = string_to_ObjectId("Object1"); poa->activate_object_with_id(id1.in(), &servant1); ObjectId_var id2 = string_to_ObjectId("Object2"); poa->activate_object_with_id(id2.in(), &servant2); obj = poa->id_to_reference(id1.in()); String_var ior1 = orb->object_to_string(obj.in()); obj = poa->id_to_reference(id2.in()); String_var ior2 = orb->object_to_string(obj.in()); obj = orb->resolve_initial_references("IORTable"); IORTable::Table_var ior_table = IORTable::Table::_narrow(obj.in()); ior_table->bind("MessengerService/Object1", ior1.in()); ior_table->bind("MessengerService/Object2", ior2.in());The problem with the above code is that the ImR will redirect clients to the correct server, but then because you are using a corbaloc URL, the server will redirect the clients to the IOR registered in the IORTable. Since these object use inderect references, you'll end up being redirected *back* to the ImR again, which will then finally forward you back to the server where your invocation can continue. The solution is to modify the program to register *direct* object references with the IORTable. TAO_Root_POA* tpoa = dynamic_cast(poa.in()); bool use_indirect = false; obj = tpoa->id_to_reference_i(id1.in(), use_indirect); String_var ior1 = orb->object_to_string(obj.in()); obj = tpoa->id_to_reference_i(id2.in(), use_indirect); String_var ior2 = orb->object_to_string(obj.in());Now the ImR will redirect clients to the correct server, and then the server will redirect clients back to itself without going back through the ImR.
Q:	How can I avoid the cost of being redirected twice to my server when using the ImR?
A:	When using corbaloc URLs, the ImR simply redirects clients to the correct server, however the URL-based object reference doesn't contain enough information to actually do anything. Therefore the server must include an IORTable entry that will be used to redirect the client back to the server itself again with the correct full IOR-based object reference. This extra round-trip can be avoided by simply *not* using URLs to invoke the operations in the first place. This typically means that you'll have to run the server and have it either output the IOR or register it with a NameService. As long as you start the server on a consistent endpoint(s) then the IOR will remain valid.

---

Send updates, additions, and corrections to [email protected]

Copyright © 2013 Object Computing, Inc. All rights reserved. | Privacy Policy | Visitor