CORBA Programming Reference
|
 |
 |
|
 |
 |
Server::initialize()
Synopsis
Allows the application to perform application-specific initialization procedures, such as logging into a database, creating and registering well-known object factories, initializing global variables, and so forth.
C++ Binding
class Server {
public:
CORBA::Boolean initialize(int argc, char** argv);
};
Arguments
The argc and argv arguments are passed from the command line. The argc argument contains the name of the server. The argv argument contains the first command-line option that is specific to the application, if there are any.
Command-line options are specified in the UBBCONFIG file using the CLOPT parameter in the entry for the server in the SERVERS section. System-recognized options come first in the CLOPT parameter, followed by a double-hyphen (--), followed by the application-specific options. The value of argc is one greater than the number of application-specific options. For details, see ubbconfig(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference.
Exceptions
If an exception is raised in Server::initialize(), the TP Framework catches the exception. The TP Framework behavior is the same as if initialize() returned FALSE (that is, an exception is considered to be a failure). In addition, an error message is written to the user log (ULOG) file, as follows, for each exception type:
"TPFW_CAT:1: ERROR: Exception in Server::initialize():IDL:beasys.com/TobjS/InitializeFailed:1.0. Reason =reason"Where
reasonis a string supplied by application code. For example:"TPFW_CAT:1: ERROR: Exception in Server::initialize():exception. Reason = unknown"Where
exceptionis the interface ID of the CORBA exception that was raised.
Description
The initialize callback method, which is invoked as the last step in server initialization, allows the application to perform application-specific initialization.
Typically, a server application does the following tasks in Server::initialize:
- Creates references for CORBA object factories implemented in the server application and registers them with the FactoryFinder using the
TP::register_factory()operation. - Initializes global variables, if any are used.
- Opens XA resource managers if any are used by the server application.
It is the responsibility of the server application to open any required XA resource managers. This is done by invoking either of the following methods:
TP::open_xa_rm()This is the preferred technique for server applications, since it can be done on a static function, without the need to obtain an object reference.
Note: You must use the TP::open_xa_rm() method if you use the INS bootstrap mechanism to obtain initial object references.
Tobj::TransactionCurrent::open_xa_rm()A reference to the TransactionCurrent object can be obtained from the Bootstrap object. For an explanation of how to obtain a reference to the Bootstrap object, see the section TP::bootstrap(). For more information about the TransactionCurrent object, see the CORBA Bootstrapping Programming Reference section and Using CORBA Transactions.- Transactions may be started in the
initializemethod after invoking theTobj::TransactionCurrent::open_xa_rm()orTP::open_xa_rmmethod. However, any transactions that are started ininitialize()must be terminated by the server application beforeinitialize()returns. If the transactions are still active when control is returned, the server application fails to boot, and it exits gracefully. This happens because the server application has no logical way of either committing or rolling back the transaction afterServer::initialize()returns. This condition is an error.
Return Value
Boolean TRUE or FALSE. TRUE indicates success. FALSE indicates failure. If an error occurs in initialize(), the application code should return FALSE. The application code should not call the system call exit(). Calling exit() does not give the TP Framework a chance to release resources allocated during startup and may cause unpredictable results.
