BEA WebLogic Enterprise 4.2    Developer Center     

        HOME   |   SITE MAP   |   SEARCH   |   CONTACT   |   GLOSSARY  |   PDF FILES |   WHAT'S NEW 
 
        C++ REFERENCE    |   TABLE OF CONTENTS   |   PREVIOUS TOPIC   |   NEXT TOPIC  

Development Commands

This chapter is an alphabetical reference that describes each WLE development command and Interface Repository administration command for the Windows NT and UNIX environments. A list of valid parameters and options is shown for each command.

The following commands are described:

Before executing a WLE command, you must ensure that the bin directory is in
your defined path:

On Windows NT

Set Path=%TUXDIR%\Bin;%Path%

On UNIX

For c shell (csh): set path = ($TUXDIR/bin $path)

For Bourne (sh) or Korn (ksh): PATH=$TUXDIR/bin:$PATH
export PATH

To set environment variables:

On Windows NT

set var=value

On UNIX:

For c shell: setenv var value

For Bourne and Korn (sh/ksh): var=value
export var

buildobjclient

Synopsis

Constructs a WLE client application.

Syntax

buildobjclient [-v][-o name] [-f firstfile-syntax] [-l
       lastfile-syntax] -P

Description

Use the buildobjclient command to construct a WLE client application. The command combines the files specified in the -f and -l options with the standard WLE libraries to form a client application. The client application is built using the default C++ language compile command defined for the operating system in use.

All specified .c and .cpp files are compiled in one invocation of the compilation system for the operating system in use. Users may specify the compiler to invoke by setting the CC environment variable to the name of the compiler. If the CC environment variable is not defined when buildobjclient is invoked, the default C++ language compile command for the operating system in use will be invoked to compile all .c and .cpp files.

Users may specify options to be passed to the compiler by setting the CFLAGS or the CPPFLAGS environment variables. If CFLAGS is not defined when buildobjclient is invoked, the buildobjclient command uses the value of CPPFLAGS if that variable is defined.

Options

-v
Specifies that the buildobjclient command should work in verbose mode. In particular, it writes the compile command to its standard output.

-o name
Specifies the name of the client application generated by this command. If the name is not supplied, the application file is named client<.type>, where type is an extension that is dependent on the operating system for an application (for example, on a UNIX system, there would not be a type; on a Windows NT system, the type would be .EXE).

-f firstfile-syntax
Specifies a file to be included first in the compile and link phases of the buildobjclient command. The specified file is included before the WLE libraries are included. There are three ways of specifying a file or files, as shown in Table 10-1.

Table 10-1 Specifying the First Filename(s)
Filename Specification Definition

-f firstfile

One file is specified.

-f "file1.cpp file2.cpp file3.cpp ..."

Multiple files may be specified if they are enclosed in quotation marks and are separated by white space.

Note: Filenames that include spaces are not supported

Note: The -f option may be specified multiple times.

-l lastfile-syntax
Specifies a file to be included last in the compile and link phases of the buildobjclient command. The specified file is included after the WLE libraries are included. There are three ways of specifying a file, as shown in Table 10-2.

Table 10-2 Specifying the Last Filename(s)
Filename Specification Definition

-l lastfile

One file is specified.

-l "file1.cpp file2.cpp file3.cpp ..."

Multiple files may be specified if they are enclosed in quotation marks and are separated by white space.

Note: The -l option may be specified multiple times.

-P
Specifies that the appropriate POA libraries should be linked into the image (that is, libraries that allow a client to also function as a server). The resulting image can act as a server and can use the Callbacks wrapper class for creating objects. The resulting joint client/server cannot take advantage of the object state management and transaction management provided by the WLE TP Framework. The -P switch should have been passed to the IDL compiler when generating the client. Use buildobjserver to build a server with all the support provided by the TP Framework. The default is to not link in the server libraries; that is, the default is to create a client only, not a joint client/server.

-h or -?
Provides help that explains the usage of the buildobjclient command. No other action results.

Environment
Variables

TUXDIR
Finds the WLE libraries and include files to use when compiling the client applications.

CC
Indicates the compiler to use to compile all files with .c or .cpp file extensions. If not defined, the default C++ language compile command for the operating system in use will be invoked to compile all .c and .cpp files.

CFLAGS
Indicates any arguments that are passed as part of the compiler command line for any files with a .c or .cpp file extensions. If CFLAGS does not exist in the buildobjclient command environment, the buildobjclient command checks for the CPPFLAGS environment variable.

CPPFLAGS

Note: Arguments passed by the CFLAGS environment variable take priority over the CPPFLAGS variable.

Contains a set of arguments that are passed as part of the compiler command line for any files with a .c or .cpp file extensions.
This is in addition to the command line option "-I$(TUXDIR)/include" for UNIX systems or the command line option /I%TUXDIR%\include for Windows NT systems, which is passed automatically by the buildobjclient command. If CPPFLAGS does not exist in the buildobjclient command environment, no compiler commands are added.

LD_LIBRARY_PATH (UNIX systems)
Indicates which directories contain shared objects to be used by the compiler, in addition to the objects shared by the WLE software. A colon (:) is used to separate the list of directories.

LIB (Windows NT systems)
Indicates a list of directories within which to find libraries. A semicolon (;) is used to separate the list of directories.

Portability

The buildobjclient command is not supported on client-only platforms.

Examples

The following example builds a WLE client application on an NT system: 

set CPPFLAGS=-I%APPDIR%\include
buildobjclient -o empclient.exe -f emp_c.cpp -l userlib1.lib
The following example builds a WLE client application on a UNIX system using the c shell:
 
setenv CPPFLAGS=$APPDIR/include
buildobjclient -o empclient -f emp_c.cpp -l userlib1.a

buildobjserver

Synopsis

Constructs a WLE server application.

Syntax

buildobjserver [-v] [-o name] [-f firstfile-syntax] 
       [-l lastfile-syntax] [-r rmname]

Description

Use the buildobjserver command to construct a WLE server application. The command combines the files specified in the -f and -l options with the main routine and the standard WLE libraries to form a server application. The server application is built using the default C++ compiler provided for the platform.

All specified .c and .cpp files are compiled in one invocation of the compilation system for the operating system in use. Users may specify the compiler to invoke by setting the CC environment variable to the name of the compiler. If the CC environment variable is not defined when buildobjserver is invoked, the default C++ language compile command for the operating system in use will be invoked to compile all .c and .cpp files.

Users may specify options to be passed to the compiler by setting the CFLAGS or the CPPFLAGS environment variables. If CFLAGS is not defined when buildobjserver is invoked, the buildobjserver command uses the value of CPPFLAGS if that variable is defined.

Options

-v
Specifies that the buildobjserver command should work in verbose mode. In particular, it writes the compile command to its standard output.

-o name
Specifies the name of the server application generated by this command. If the name is not supplied, the application file is named server<.type>, where type is the extension that is dependent on the operating system for an application (for example, on UNIX systems, there would not be a type; on Windows NT systems, the type would be .EXE).

-f firstfile-syntax
Specifies a file to be included first in the compile and link phases of the buildobjserver command. The specified file is included before the WLE libraries are included. For a description of the three ways to specify a file or files, see Table 10-1, "Specifying the First Filename(s)," on page 10-4.

-l lastfile-syntax
Specifies a file to be included last in the compile and link phases of the buildobjserver command. The specified file is included after the WLE libraries are included. For a description of the three ways to specify a file or files, see Table 10-2, "Specifying the Last Filename(s)," on page 10-4.

-r rmname
Specifies the resource manager associated with this server. The value rmname must appear in the resource manager table located in $TUXDIR/udataobj/RM on UNIX systems or %TUXDIR%\udataobj\RM on Windows NT systems.
Each entry in this file is of the form rmname:rmstructure_name:library_names.
Using the rmname value, the entry in $TUXDIR/udataobj/RM or %TUXDIR%\udataobj\RM automatically includes the associated libraries for the resource manager and properly sets up the interface between the transaction manager and the resource manager. The value TUXEDO/SQL includes the libraries for the BEA TUXEDO System/SQL resource manager. Other values can be specified as they are added to the resource manager table. If the -r option is not specified, the default is to use the null resource manager.

-h or -?
Provides help that explains the usage of the buildobjserver command. No other action results.

Environment
Variables

TUXDIR
Finds the WLE libraries and include files to use when compiling the server application.

CC
Indicates the compiler to use to compile all files with .c or .cpp file extensions that are passed in through the -l or -f options.

CFLAGS
Specifies any arguments that are passed as part of the compiler command line for any files with .c or .cpp file extensions. If CFLAGS does not exist in the buildobjserver command environment, the buildobjserver command checks for the CPPFLAGS environment variable.

CPPFLAGS

Note: Arguments passed by the CFLAGS environment variable take priority over the CPPFLAGS environment variable.

Contains a set of arguments that are passed as part of the compiler command line for any files with a .c or .cpp file extensions.This is in addition to the command line option -I$(TUXDIR)/include for UNIX systems or the command line option /I%TUXDIR%\include for Windows NT systems, which is passed automatically by the buildobjserver command. If CPPFLAGS does not exist in the buildobjserver command environment, no compiler commands are added.

LD_LIBRARY_PATH (UNIX systems)
Indicates which directories contain shared objects to be used by the compiler, in addition to the WLE shared objects. A colon (:) is used to separate the list of directories.

LIB (Windows NT systems)
Indicates a list of directories within which to find libraries. A semicolon (;) is used to separate the list of directories.

Portability

The buildobjserver command is not supported on client-only WLE systems.

Examples

The following example builds a WLE server application on a UNIX system using the emp_s.cpp and emp_i.cpp files:

buildobjserver -r TUXEDO/SQL -o unobserved
-f "emp_s.cpp emp_i.cpp"

The following example shows how to use the CC and CFLAGS environment variables with the buildobjserver command. The example also shows how to link in the math library on UNIX systems using the Bourne or Korn shells using the -f and -lm options: 

CFLAGS=-g CC=/bin/cc \
buildobjserver -r TUXEDO/SQL -o TLR -f TLR.o -f util.o -l -lm

The following example shows how to use the buildobjserver command on UNIX systems with no resource manager specified: 

buildobjserver -o PRINTER -f PRINTER.o

Sample RM Files

The following are sample RM files for all the supported operating system platforms:

Windows NT 

Oracle_XA;xaosw;C:\Orant\rdbms73\xa\xa73.lib
    C:\Orant\pro22\lib\msvc\sqllib18.lib

Solaris 

Oracle_XA:xaosw:-L$ORACLE_HOME/rdbms/lib
    -L$ORACLE_HOME/precomp/lib -lc
    -L/home4/m01/app/oracle/product/7.3.2/lib -lsql -lclntsh         
    -lsqlnet -lncr -lcommon -lgeneric -lepc -lnlsrtl3 -lc3v6 
    -lcore3 -lsocket -lnsl -lm -ldl -lthread

Tru64 UNIX 

Oracle_XA:xaosw:-L${ORACLE_HOME}/lib -lxa
    ${ORACLE_HOME}/lib/libsql.a -lsqlnet -lncr -lsqlnet
    ${ORACLE_HOME}/lib/libclient.a -lcommon -lgeneric -lsqlnet
    -lncr -lsqlnet ${ORACLE_HOME}/lib/libclient.a -lcommon
    -lgeneric -lepc -lepcpt 	-lnlsrtl3 -lc3v6 -lcore3     
    -lnlsrtl3 -lcore3 -lnlsrtl3 -lm

AIX 

Oracle_XA:xaosw:-L${ORACLE_HOME}/lib -lxa -lsql -lsqlnet 
    -lncr -lclient -lcommon -lgeneric -lepc -lnlsrtl3 -lc3v6 
    -lcore3 -lm -lld

HP-UX : Oracle 8.04

Oracle_XA:xaosw:-L${ORACLE_HOME}/lib -lclntsh

genicf

Synopsis

Generates an ICF file.

Syntax

genicf [options] idl-filename...

Description

Given the idl-filename(s), generates an ICF file that provides the code generation process with additional information about policies on implementations and the relationship between implementations and the interface they implement. If an ICF file is provided as input to the idl command, the idl command generates server code for only the implementation/interface pairs specified in the ICF file.

The generated ICF file has the same filename as the first idl-filename specified on the command line, but with a .icf extension.

If incorrect OMG IDL syntax is specified in the idl-filename(s) file, appropriate errors are returned.

Options

-D identifier=[definition]
Performs the same function as the #define C++ preprocessor directive; that is, the -D option defines a token string or a macro to be substituted for every occurrence of a given identifier in the definition file. If a definition is not specified, the identifier is defined as 1. Multiple -D options can be specified. White space between the -D option and the identifier is optional.

-I pathname
Specifies directories within which to search for include files, in addition to any directories specified with the #include OMG IDL preprocessor directive. Multiple directories can be specified by using multiple -I options.
There are two types of #include OMG IDL preprocessor directives: system (for example, <a.idl>) and user (for example, "a.idl"). On UNIX systems, the path for system #include directories is /usr/include and any directories specified with the -I option; the path for user #include directives is the location of the file containing the #include directive, followed by the path specified for the system #include directive. On Windows NT systems, no distinction is made between the system #include directories and the user #include directives.

-h and -?
Provides help that explains the usage of the genicf command. No other action results.

Example

This command creates the emp.icf file: genicf emp.idl.

idl

Synopsis

Compiles the Object Management Group (OMG) Interface Definition Language (IDL) file and generates the files required for the interface.

Syntax

idl [-i] [-Did[=value]] [-I pathname][-h] [-P] [-T] idl-filename...
          [ icf-filename...]

Description

Given the provided idl-filename() file(s) and optional icf-filename() file(s), the idl command generates the following files:

idl-filename_c.cpp
Client stub (includes embedded user-defined data type functions).

idl-filename_c.h
Class definitions for interfaces.

idl-filename_s.cpp
Server skeleton containing an implementation of the POA_skeleton classes.

idl-filename_s.h
POA_skeleton class definitions.

idl-filename_i.cpp
Example version of the implementation. This file is generated only when the -i option is given.

idl-filename_i.h
Class definition of an example implementation that inherits from the POA_skeleton class. This file is generated only when the -i option is given.

Note: If any ICF files are specified, the information within the ICF files is used to provide the code generator with information about the interface/implementations that override the defaults. Typically, an activation policy and a transaction policy for an implementation may be specified in the ICF file. If no ICF files are specified, default policies are in effect for all of the interfaces specified in the OMG IDL file, and skeleton code for all of the interfaces is generated. If an icf-filename is provided as input to the idl command, only the implementation/interfaces specified in the icf-filename are generated as part of the server. For information about ICF syntax, see "ICF Syntax" on page 2-2.

The IDL compiler places the generated client stub information in the filename_c.cpp and filename_c.h files. The generated server skeleton information is placed in the filename_s.cpp and filename_s.h files.

The IDL compiler overwrites the generated client stub files (filename_c.cpp and filename_c.h), and the generated server skeleton files (filename_s.cpp and filename_s.h). Any previous versions are destroyed.

When using the -i option, the IDL compiler overwrites the sample implementation class definition file (filename_i.h). Previous versions are destroyed. The sample implementation file (filename_i.cpp) is overwritten, however, any code contained within the code preservation blocks is preserved and restored in the newly generated file. To avoid the loss of data, it is recommended that you copy the sample implementation files (filename_i.h and filename_i.cpp) to a safe location before regenerating these files.

If an unknown option is passed to this command, the offending option and a usage message is displayed to the user, and the compile is not performed.

For more information about OMG IDL syntax, see Chapter 1, "OMG IDL Syntax".

Parameter

idl filename

The name of one or more files that contain OMG IDL statements.

Options

-D identifier[=definition]

Performs the same function as the #define C++ preprocessor directive; that is, the -D option defines a token string or a macro to be substituted for every occurrence of a given identifier in the definition file. If a definition is not specified, the identifier is defined as 1. Multiple -D options can be specified. White space between the -D option and the name is optional.

-I pathname
Specifies directories within which to search for include files, in addition to any directories specified with the #include OMG IDL preprocessor directive. Multiple directories can be specified by using multiple -I options.

There are two types of #include OMG IDL preprocessor directives: system (for example, <a.idl>) and user (for example, "a.idl"). The path for system #include directories is the system include directory and any directories specified with the -I option. The path for user #include directives is the location of the file containing the #include directive, followed by the path specified for the system #include directive.

By default, the text in files included with an #include directive is not included in the client and server code that is generated.

-i
Results in idl-filename_i.cpp files being generated. These files contain example templates for the implementations that implement the interfaces specified in the OMG IDL file.

Note: When using the idl command -i option to update your implementation files, proceed as follows to update your implementation files:

  1. Back up your implementation files.

  2. If you are migrating from BEA ObjectBroker to WLE, edit your generated implementation files to change the code preservation block delimiters from "OBB_PRESERVE_BEGIN" and "OBB_PRESERVE_END" to "M3_PRESERVE_BEGIN" and "M3_PRESERVE_END".

  3. If you added include files to your method implementation file (*_i.cpp), edit the file and move the includes inside the INCLUDES preservation block.

  4. Regenerate your edited implementation files (using the idl command with the -i option).

  5. If you previously made modifications to the implementation definition file (*_i.h), edit the newly generated definition file and add your modifications back in. Be sure to put your modifications inside the code preservation blocks so subsequent updates will automatically retain them. Pay particular attention to the implementation constructor and destructor functions; the function signatures have been changed in this release.

  6. If you previously made modifications outside the preservation blocks of the method implementation file (*_i.cpp) or to the implementation constructor and destructor functions, edit the newly generated file and add those modifications. Be sure to put the modifications inside a preservation block so subsequent updates will automatically retain them.

-P
Generates server code that uses the POA instead of the TP Framework. With this option specified, the skeleton class does not inherit from the TP Framework Tobj_ServantBase class, but instead inherits directly from the PortableServer::ServantBase class. By default, the skeleton class uses the TP Framework. So you must use this switch when you are developing joint client/servers as these servers do not use the TP framework.
Not having the Tobj_ServantBase class in the inheritance tree for a servant means that the servant does not have activate_object and deactivate_object methods. In WLE servers these methods are called by the TP Framework to dynamically initialize and save a servant's state before invoking a method on the servant. For WLE joint client/servers, user-written code must explicitly create a servant and initialize a servant's state; therefore, the Tobj_ServantBase operations are not needed. When using the -P option, ICF files are not used because the TP Framework is not available.

-T
Generates tie-based servant code that allows the use of delegation to tie an instance of a C++ implementation class to the servant. This option allows classes that are not related to skeletons by inheritance to implement CORBA object operations. This option is set to off by default.

Note: When using tie classes with the Digital C++ V6.0 compiler for Tru64 UNIX, include the -noimplicit_include option in the definition of the CFLAGS and CPPFLAGS environment variables used by the buildobjserver command. This option prevents the Digital C++ compiler from automatically including the server skeleton definition file (_s.cpp) everywhere the server skeleton header file (_s.h) is included. This is necessary to avoid multiply-defined symbol errors. See Using DIGITAL C++ for Tru64 Unix Systems for additional information on using class templates (such as the tie classes) with Digital C++.

-h or -?
Provides help that explains the usage of the idl command. No other action results.

Examples

idl emp.idl
idl emp.idl emp.icf

Copyright © 1999 BEA Systems, Inc. All Rights Reserved.
Required browser version: Netscape Communicator version 4.0 or higher, or Microsoft Internet Explorer version 4.0 or higher.
Last update: July 06, 1999.