CORBA Programming Reference
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.
class Server {
public:
CORBA::Boolean initialize(int argc, char** argv);
};
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.
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 reason
is a string supplied by application code. For example:
"TPFW_CAT:1: ERROR: Exception in Server::initialize():
exception. Reason = unknown"
Where exception
is the interface ID of the CORBA exception that was raised.
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
:
TP::register_factory()
operation.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. initialize
method after invoking the Tobj::TransactionCurrent::open_xa_rm()
or TP::open_xa_rm
method. However, any transactions that are started in initialize()
must be terminated by the server application before initialize()
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 after Server::initialize()
returns. This condition is an error.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.