|
|
|
|
|
|
This topic describes these commands.
buildjavaserver
Synopsis
Constructs a Java WLE server application jar file.
Syntax
buildjavaserver [-s searchpath] input_file
Description
Once the class files that make up a server application have been created and specified, along with interface activation and transaction policies, in the Server Description File, you use the buildjavaserver command to create the jar file. The jar file contains all the server application class files and a server descriptor. The server descriptor is a serialized Java object that contains:
- Information about all the servant classes implemented by the server application
- Activation and transaction policies for all the interfaces that have been defined in the application's OMG IDL file
- The name of the Server object, which initializes and stops the server application and performs object housekeeping
- -s
- Specifies a path to be used by the buildjavaserver command to locate the classes and packages needed for building the jar file. If you do not specify this option, the buildjavaserver command uses the class path by default.
- input_file
- Specifies the name of the Server Description File.
Environment
Variables
- TUXDIR
- Finds the WLE libraries and include files to use when compiling the server application.
- 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 buildjavaserver command is not supported on client-only WLE systems.
Example
The following example builds a Java WLE server application jar file on a UNIX system. This example uses the com/acme path for locating classes and packages for the archive and also uses the Server Description File MyServer.xml .
buildjavaserver -s com/acme MyServer.xml
Synopsis
Constructs a WLE client application.
Syntax
buildobjclient [-v][-o name] [-f firstfile-syntax]
[-l lastfile-syntax] -PDescription
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 1-1.
Table 1-1 Specifying the First Filename(s)
Filename Specification
Definition
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 1-2.
Table 1-2 Specifying the Last Filename(s)
Filename Specification
Definition
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.libThe 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
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 1-1, "Specifying the First Filename(s)," on page 1-6.
- -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 1-2, "Specifying the Last Filename(s)," on page 1-6.
- -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 -lmThe 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.libUNIX
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 -lthreadDigital 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 -lmAIX
Oracle_XA:xaosw:-L${ORACLE_HOME}/lib -lxa -lsql -lsqlnet
-lncr -lclient -lcommon -lgeneric -lepc -lnlsrtl3 -lc3v6
-lcore3 -lm -lldHP-UX : Oracle 8.04
Oracle_XA:xaosw:-L${ORACLE_HOME}/lib -lclntsh
See the description of the buildtms command in the BEA TUXEDO Reference manual.
Synopsis
Constructs an XA resource manager to be used with a Java server application group.
Syntax
buildXAJS [-v] -r rmname [-o outfile]
Description
Use this command to build an XA resource manager that you want to use with a Java server application group. In the application's UBBCONFIG file, you use the JavaServerXA element in place of the JavaServer element to associate the XA resource manager with a specified server group. Note that a server application configured to use the default XA resource manager (that is, NULL ) cannot coexist in a server group that uses a nondefault XA resource manager, such as Oracle. Refer to the Administration Guide for more information about configuring server groups with an XA resource manager.
Options
- -v
- Specifies that the buildXAJS command should work in verbose mode. In particular, it writes the build command to its standard output.
- -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.
- On UNIX systems, each entry in this file is of the form rmname:rmstructure_name:library_names . On 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.
- -o outfile
- Specifies the name of the output file. If no name is specified, the default is JavaServerXA .
Environment
Variables
- TUXDIR
- Finds the WLE libraries and include files to use when compiling the server application.
- 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 buildXAJS command is not supported on client-only WLE systems.
Example
The following example builds a Java server XA resource manager on a UNIX system:
buildXAJS -r oracle7
Synopsis
Produces a deployable EJB JAR file.
Syntax
java com.beasys.ejb.utils.ejbc options jar-file archive-files
Description
The ejbc command produces a deployable EJB JAR file. You can also use this command to generate a standard EJB JAR file for distribution. The primary input to the ejbc command is a standard EJB deployment descriptor file specified in XML, and optionally an XML deployment descriptor file specifying the WebLogic EJB extensions to the deployment descriptor DTD.
The ejbc command performs the following steps:
- Parses the standard EJB deployment descriptor XML file and the WebLogic EJB extensions to the deployment descriptor DTD. You can provide this input as separate input files, or as an existing EJB JAR file. The XML file names are ejb-jar.xml and weblogic-ejb-extensions.xml . If you use the -nodeploy option, the file containing the WebLogic EJB extensions to the deployment descriptor DTD, if specified, is ignored.
- Checks the deployment descriptors for semantic consistency, and writes any inconsistencies to standard output.
- Generates the wrapper java classes and compiles them. This is performed for each EJB in the deployment descriptor. Note that the ejbc command does not compile the bean classes; the bean classes must be compiled before you use the ejbc command.
If you specify the -nodeploy option, the ejbc command does not generate any wrapper classes.
- Packages the XML deployment descriptors and the generated class files into a deployable EJB JAR file. The ejbc command ignores the archive arguments; the ejbc command simply packages the contents of the destination directory (which may be the current dirrectory) and the standard deployment descriptor and WebLogic EJB extensions to the deployment descriptor DTD files into the EJB JAR file.
Options
- -help
- Prints a short description of the arguments for the command.
- -i input-file
- Specifies the input file, which can be either an existing EJB JAR file or a standard EJB deployment descriptor file. If you do not specify an input file, the ejbc command checks for an existing EJB JAR file and uses that for input. You must name the standard EJB deployment descriptor file ejb-jar.xml .
- -x wldd-file
- Optional. Identifies the WebLogic EJB extensions to the deployment descriptor DTD. If you do not specify this file, but you do provide an input EJB JAR file, the ejbc command attempts to read the WebLogic EJB extensions to the deployment descriptor DTD from the EJB JAR file instead. You must name the extended EJB deployment descriptor file wlejb-jar.xml .
- -classpath path
- Sets the CLASSPATH for the ejbc command. This overrides the system or shell CLASSPATH .
- -d directory
- Sets the destination directory for the generated class files. If you do not enter this option, the ejbc command uses the current directory.
- -compiler javac
- Sets the Java compiler. The default is javac .
- -keepgenerated
- Saves the intermediate Java files generated for deployment.
- -nodeploy
- Creates a standard EJB JAR file. When you use this option, the ejbc command does not generate wrapper classes, and only processes standard XML. If a file specifying the WebLogic EJB extensions to the deployment descriptor DTD is present in the input to the ejbc command, that XML descriptor is ignored and is not written to the archive.
- jar-file
- Optional. This specifies the output deployable EJB JAR file for the WLE JavaServer. This file also serves as the default input for the deployment descriptors, if you do not specify them explicitly using the -i or -x option. If you do not specify this argument, any generated class files are placed only in the destination directory.
- archive-files
Identifies the files to be included in the output EJB JAR file. This argument uses the same syntax as the standard JDK jar utility, and can specify one or more files or directories. If any of the files is a directory, the ejbc command processes the directory recursively. You may use wildcards in the file specification. This archive-files argument is optional. If you do not specify this argument, the ejbc command places the generated classes in the destination directory (specified with the -d option).
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 .
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.
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.
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:
- Back up your implementation files.
- 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" .
- If you added include files to your method implementation file (*_i.cpp ), edit the file and move the includes inside the INCLUDES preservation block.
- Regenerate your edited implementation files (using the idl command with the -i option).
- 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.
- 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.
- -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
Synopsis
Creates the Interface Repository and loads interface definitions into it.
Syntax
idl2ir [options] definition-filename-list
Options
The options are as follows:
[-f repository-name] [-c]
[-D identifier[=definition]]
[-I pathname [-I pathname] [...]] [-N{i|e}]Description
Use this command to create the Interface Repository and to load it with interface definitions. If no repository file exists, this command creates it. If a repository file does exist, this command loads the specified interface definitions into it and, in effect, updates the file.
One of the side effects of doing this is that a new Interface Repository database file is created.
Parameters
- definition-filename-list
- A list of file specifications containing the repository definitions. These files are treated as one logical file and are loaded in one operation.
- -f repository-name
- The filename of the Interface Repository file. If you do not specify the -f option, the idl2ir command creates repository.ifr as the Interface Repository file on UNIX systems and repository_1.ifr on Microsoft Windows NT systems.
- -c
- Indicates that a new repository is to be created. If a repository exists and this option is specified, the idl2ir command ignores the existing repository and replaces it with a new one. If a repository exists and this option is not specified, the idl2ir command updates the existing repository.
- -D identifier[=definition]
- Performs the same function as the #define 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.You can specify multiple -D options.
- -I pathname
- Specifies a directory within which to search for include files, in addition to any directories specified with the #include OMG IDL preprocessor directive.
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 directives is /usr/include for UNIX systems, and any directories specified with the -I option. The path for system #include directives is the local directory for Windows NT systems, and any directories specified with the -I option.
The path for user #include directives is the current directory and any directories specified with the -I option. Multiple -I options can be specified.
Synopsis
Compiles IDL files to Java source code based on IDL to Java mappings defined by the OMG.
The idltojava compiler provided with BEA WebLogic Enterprise (WLE) includes several enhancements, extensions and additions that are not present in the original Sun Microsystems, Inc. version of the compiler. The WLE specific revisions are summarized here.
The BEA WLE idltojava compiler:
- Differs from that described in the Sun Microsystems, Inc. documentation in behavior and defaults of the flags.
- Includes a new #pragma tag: #pragma ID < name> <Repostitory_id>
- Includes a new #pragma tag: #pragma version < name> <m.n>
- Extends the #pragma prefix to work on inner scope. A blank prefix reverts.
- Allows unions with boolean discriminators
- Allow declarations nested inside complex types
Syntax
idltojava [idltojava Command Flags] [idltojava Command Options] filename ...
m3idltojava [idltojava Command Flags] [idltojava Command Options] filename ...
To run idltojava on Client-side IDL files, use the following command:
idltojava <flags> <options> <idl-files>
The idltojava command requires a C++ pre-processor, and is used to generate deprectated names. The command idltojava generates Java code as is appropriate for the client-side ORB.
Note: A remote joint client/server is a client that implements server objects to be used as callback objects. The server role of the remote joint client/server is considerably less robust than that of a WLE server. Neither the client nor the server has any of the WLE administrative and infrastructure components, such as tmadmin , JNDI registration, and ISL/ISH (hence, none of scalability and reliability attributes of WLE)
To run m3idltojava on Server-side IDL files, use the following command:
m3idltojava <flags> <options> <idl-files>
The server-side ORB is built to use non-deprecated names. The command m3idltojava generates Java code using non-deprecated names as is appropriate for the server-side ORB.
Description
The idltojava command compiles IDL source code into Java source code. You then use the javac compiler to compile that source to Java bytecodes.
The command idltojava is used to translate IDL source code into generic client stubs and generic server skeletons which can be used for callbacks. The command m3idltojava is used to translate IDL into generic client stubs and WebLogic Enterprise server skeletons.
The IDL declarations from the named IDL files are translated to Java declarations according to the mappings specified in the OMG IDL to Java mappings.
Options
Note: Several option descriptions have been added here that are not documented in the original Sun Microsystems Inc. idltojava compiler documentation.
Command Flags
The flags can be turned on by specifying them as shown, and they can be turned off by prefixing them with the letters no- . For example, to prevent the C preprocessor from being run on the input IDL files, use -fno-cpp .
The table below includes descriptions of all flags.
Notes
The BEA WLE idltojava compiler processes #pragma somewhat differently from the Sun Microsystems, Inc. idltojava compiler.
RepositoryPrefix="prefix"
A default repository prefix can also be requested with the line #pragma prefix "requested prefix" at the top-level in the IDL file itself.
#pragma javaPackage "package"
Wraps the default package in one called package. For example, compiling an IDL module M normally creates a Java package M. If the module declaration is preceded by:
#pragma javaPackage browser
the compiler will create the package M inside package browser. This pragma is useful when the definitions in one IDL module will be used in multiple products. The command line option -p can be used to achieve the same result
#pragma ID scoped-name "IDL:<path>:<version>"
specifies the repository ID of the identifier scoped-name. This pragma may appear any where in an IDL file. If the pragma appears inside a complex type such as structure or union then only as much of scoped-name need be specified to specify the element. A scoped-name is of the form outer_name::name::inner_name . The <path> component of the repository id is a series of identifiers separated by forward slashes (/) . The <version> component is a decimal number MM.mm , where MM is the major version number and mm is the minor version number.
Synopsis
Shows the contents of an Interface Repository.
Syntax
ir2idl [options] [interface-name]
Options
The options are as follows:
[-f repository-name] [-n]
[-t interface-type] [-o filename]Description
This command shows the contents of an Interface Repository. By directing the output to a file with the -o option, you can extract the OMG IDL file from the repository. By default, the repository file is repository.ifr .
Parameters
- interface-name
- The name of the interface whose contents are to be shown. If you do not specify an interface name, all interfaces in the repository are shown.
- -f repository-name
- The name of the repository to search for the interface definitions. If you do not specify the -f option, repository.ifr is used.
- -n
- Specifies that the output should not include those objects that were inherited.
- -t interface-type
- Indicates the type of objects to display. The object type must be one of the following keywords:
- Attribute
- Constant
- Exception
- Interface
- Method
- Module
- Operation
- Typedef
- If you do not specify this option, the default is to display all of the types.
- -o filename
- The file specification for the file in which to write the retrieved OMG IDL statements. The default is standard output.
Synopsis
Deletes the specified object from an Interface Repository.
Syntax
irdel [-f repository-name] [-i id] object-name
Description
This command deletes the specified interface from the repository. Only interfaces not referenced from another interface can be deleted. By default, the repository file is repository.ifr .
Parameters
- -f repository-name
- An optional parameter that specifies an Interface Repository. The repository-name value is the file specification of an Interface Repository. If this option is not specified, the repository.ifr is used as the default.
- -i id
- The repository id for the specified object. The id is used as a secondary level of lookup. If the id does not match the id of the named object, the object is not deleted.
- object-name
- The name of the interface to delete from the repository. The name can be a simple object name or a scoped name, for example, MOD1::INTERF2::OP3 (operation OP3 is within interface INTERF2 , which is in application MOD1 ).
Synopsis
Enables access to WLE objects by remote WLE clients using IIOP.
Syntax
ISL SRVGRP="identifier"
SRVID="number"
CLOPT="[ -A ] [ servopts options ] -- -n netaddr
[-a]
[ -C {detect|warn|none} ]
[ -d device ]
[ -K {client|handler|both|none} ]
[ -m minh ]
[ -M maxh ]
[ -T Client-timeout]
[ -x mpx-factor ]
[-H external-netaddr]
#NEW options for Outbound IIOP
[-O]
[-o outbound-max-connections]
[-s Server-timeout]
[-u out-mpx-users]"
[-R renegotiation-interval]
[-S secure port]
[-z [0|40|56|128]]
[-z [0|40|56|128]]
Description
The IIOP Server Listener (ISL) is a WLE-supplied server command that enables access to WLE objects by remote WLE clients using IIOP. The application administrator enables access to the application objects by specifying the IIOP Server Listener as an application server in the SERVERS section. The associated command-line options are used to specify the parameters of the IIOP Server Listener and IIOP Server Handlers.
The location, server group, server ID , and other generic server-related parameters are associated with the ISL using the standard configuration file mechanisms for servers. ISL command-line options allow for customization.
Each ISL booted as part of an application facilitates application access for a large number of remote WLE clients by providing access via a single, well-known network address. The IIOP Server Handlers are started and stopped dynamically by the ISL, as necessary, to meet the incoming load.
For joint client/servers, if the remote joint client/server ORB supports bidirectional IIOP connections, the ISL can use the same inbound connection for outbound invokes to the remote joint client/server. The ISL also allows outbound invokes (outbound IIOP) to objects located in a joint client/server that is not connected to an ISH. This capability is enabled when the -O option is specified. The associated command-line options (those shown above in boldface text) allow configuration of outbound IIOP support:
Parameters
- -A
- Indicates that the ISL is to be booted to offer all its services. This is a default, but it is shown to emphasize the distinction between system-supplied servers and application servers. The latter can be booted to offer only a subset of their available services. The double-dash (-- ) marks the beginning of parameters that are passed to the ISL after it has been booted.
You specify the following options in the CLOPT string after the double-dash (-- ) in the CLOPT parameters:
- -n netaddr
- Specifies the network address to be used by a server listener to accept connections from remote CORBA clients. The remote client must set the environment variable (TOBJADDR ) to this value, or specify the value in the Bootstrap object constructor. See the C++ Programming Reference for details. This is the only required parameter.
- TCP/IP addresses must be specified in one of the following two formats:
- "//hostname:port_number"
"//#.#.#.#:port_number"
- In the first format, the domain finds an address for hostname using the local name facilities (usually DNS). The host must be the local machine, and the local name resolution facilities must unambiguously resolve hostname to the address of the local machine.
Note: The hostname must begin with a letter character.
- In the second format, the "#.#.#.#" is the dotted decimal format. In dotted decimal format, each # must be a number from 0 to 255. This dotted decimal number represents the IP address of the local machine.
- In both of the above formats, port_number is the TCP port number at which the domain process listens for incoming requests. port_number can be a number between 0 and 65535 or a name. If port_number is a name, it must be found in the network services database on your local machine.
Note: The Java Tobj_Bootstrap object uses a short type to store the port_number . Therefore, you must use a port_number in the range of 0 to 32767 if you plan to support connections from Java clients.
Note: The network address that is specified by programmers in the Bootstrap constructor or in TOBJADDR must exactly match the network address in the application's UBBCONFIG file. The format of the address as well as the capitalization must match. If the addresses do not match, the call to the Bootstrap constructor will fail with a seemingly unrelated error message:
ERROR: Unofficial connection from client at
<tcp/ip address>/<port-number>:
For example, if the network address is specified as //TRIXIE:3500 in the ISL command line option string, specifying either //192.12.4.6:3500 or //trixie:3500 in the Bootstrap constructor or in TOBJADDR will cause the connection attempt to fail.
On UNIX systems, use the uname -n command on the host system to determine the capitalization used. On Windows NT systems, see the host system's Network control panel to determine the capitalization used.Note: Unlike the BEA TUXEDO system Workstation Listener (WSL), the format of the network addresses is limited to //host:port . The reason for this limitation is that the host name and port number are used by WLE servers; the host name does not appear as such in the hexadecimal format, and it could only be passed to the servers using the dotted IP address format.
- [-a]
- Specifies that certificate-based authentication should be enabled when accepting an SSL connection from a remote application.
- [-C detect|warn|none]
- Determines how the IIOP Listener/Handler will behave when unofficial connections are made to it. The default value is detect.
- The official way for the CORBA client to connect to the IIOP Listener/Handler is via a Bootstrap object. The unofficial connection is established directly from an IOR. For example, a client could connect to one IIOP Listener/Handler via a Bootstrap object and then, perhaps inadvertently, connect to a second IIOP Listener/Handler by using an IOR that contains the host and port of the second IIOP Listener/Handler. Typically, this is not the case. Usually, the client uses IORs that contain the host and port of the IIOP Listener/Handler that the client connected to via a Bootstrap object. Use of such IORs does not cause an additional connection to be made.
Caution: The use of unofficial connections can cause problems for remote client applications that use transactions. The application may have the notion that invocations on both the official and unofficial connections within the same transaction have succeeded; however, in reality, only invocations on the official connection are ACID (Atomicity, Consistency, Isolation, and Durability).
- A value of detect causes the ISL/ISH to raise a NO_PERMISSION exception when an unofficial connection is detected. A value of warn causes the ISL/ISH to log a message to the user log exception when an unofficial connection is detected; no exception will be raised. A value of none causes the ISL/ISH to ignore unofficial connections.
- [-d device]
- Specifies the device filename used for network access by the server listener and its server handlers. This parameter is optional because some transport providers (for example, sockets) do not require a device name. However, other providers (for example, TLI) do require a device name. In the case of TLI, this option is mandatory. There is no default for this parameter. (This does not apply to Windows NT systems.)
- [-K {client|handler|both|none}]
- Directs the client, or the ISH process, or both, to activate the network provider's KEEPALIVE option. This option improves the speed and reliability of network failure detection by actively testing an idle connection's state at the protocol stack level. The availability and timeout thresholds for this feature are determined by operating system tunable parameters.
- A value of client configures this option for the client; a value of handler configures this option for the ISL; and a value of both will configure both sides of the connection. The default value is none, in which case neither side has the KEEPALIVE option configured.
Note: The KEEPALIVE interval is an operating system parameter, so changing the value affects any other applications that enable KEEPALIVE . Many platforms have a two-hour default value that may be longer than desired.
- This option is not available on all platforms. A userlog warning message is generated if the KEEPALIVE option is specified but is not available on the ISH's machine. If KEEPALIVE is requested but is not available on the client's machine, the setting is ignored.
- [-m minh]
- Specifies the minimum number of handlers that should be available in conjunction with this ISL at any given time. The default is 0. The The ISL will start this many ISHs immediately upon being booted and will not deplete the supply of ISHs below this number until the administrator issues a shutdown to the ISL. The default value for this parameter is 0. The legal range is between 0 and 255.
- [-M maxh]
- Specifies the maximum number of handlers that should be available in conjunction with this ISL at any given time. The Handlers are started as necessary to meet the demand of remote WLE clients attempting to access the system. The default value for this parameter is equal to the setting for MAXWSCLIENTS on the logical machine, divided by the multiplexing factor for this ISL (see -x option below), rounded up by one. The legal range for this parameter is between 1 and 4096. The value must be equal to or greater than minh .
- [-T Client-timeout]
- Allows more time for a client to join an application when there is a large number of clients attempting to join simultaneously. The value is multiplied by the SCANUNIT parameter. The default is 3 in a nonsecure application and 6 in a secure application.
- [-x mpx-factor]
- This is an optional parameter used to control the degree of multiplexing desired within each ISH. The value for this parameter indicates the number of remote WLE clients that can be supported simultaneously by each ISH. The ISH ensures that new handlers are started as necessary to handle new remote WLE clients. This value must be greater than or equal to 1 and less than or equal to 4096. The default value for this parameter is 10.
- [-H external netadder]
- Specifies the external network address to be set as the host and port in interoperable object references returned to clients of the ISL. It has the same format as the ISL CLOPT -n netaddr option. This feature is useful when an IIOP, or remote, client needs to connect to an ISL through a firewall.
- [-O]
- This option (uppercase letter O) enables outbound IIOP to objects that are not located in a client that is connected to an ISH. Since the -O option requires a small amount of extra resources, the default is to not allow outbound IIOP.
- [-o outbound-max-connections]
- This option (lowercase letter o) specifies the maximum number of outbound connections that each ISH may have. In effect, it limits the number of simultaneous Outbound IIOP sockets that any single ISH under the control of this ISL will have active at one time.
- This option requires that the -O (uppercase letter O) option is also specified. The value of this option must be greater than 0, but not more than 4096. An additional requirement is that the value of this option, (outbound-max-connections ) times the maximum number of handlers, must be less than 32767. The default for this option is 20.
- [-R renegotiation-interval]
- Specifes the renegotiation internal in minutes. If a connection does not have a renegotiation in the specified interval, the IIOP Listener/Handler will request that the client renegotiate the session for inbound connections or actually perform the renegotiation in the case of outbound connections. The default is 0 minutes which results in no periodic session renegotiations.
- [-S secure-port]
Specifies the port number that the IIOP Listener/Handler should use to listen for secure connections using the SSL protocol. You can configure the IIOP Listener/Handler to allow only secure connections by setting the port numbers specified by the -S and -n options to the same value.
- [-s Server-timeout]
- Server-timeout is the time, in minutes, allowed for a remote server to remain idle. If a remote server does not receive any requests within this time period, the ISL disconnects the outbound IIOP connection to the server. The ISH reconnects to the remote server on subsequent requests. This option can be used for server platforms that are unstable. Note that this is a best-attempt value in that the ISL does not disconnect the connection before this time is up, but does not guarantee to disconnect the connection once the exact time has elapsed. This option requires that the -O (uppercase letter O) option is also specified. The value must be greater than or equal to 1. If this option is not specified, the default is 60 (one hour).
- [-u out-mpx-users]
- An optional parameter used to control the degree of outbound multiplexing desired within each ISH. The value for this option indicates the number of outbound IIOP users (native clients or servers) that can be supported simultaneously by each outbound IIOP connection in the ISH. The ISL ensures that new ISHs are started, as necessary, to handle new users up to the value of this option (out-mpx-users) . This option requires that the -O (uppercase letter O) option is also specified. This option must be greater than 0 (zero), but not more than 1024; the default value is 10.
- [-z |0|40|56|128]]
Specifies the minimum level of encryption when establishing a network connection between a client and the IIOP Listener/Handler. 0 means no encryption while 40, 56, and 128 specify the length (in bits) of the encryption key. If this minimum level of encryption cannot be met, a connection will not be established. This option is only available if the WLE Security Pack is installed.
- [-Z |0|40|56|128]]
Specifies the maximum level of encryption when establishing a network connection between a client and the IIOP Listener/Handler. 0 means no encryption while 40, 56, and 128 specify the length (in bits) of the encryption key. The default is whatever capability is specified by the license. This option is only available if the WLE Security Pack is installed
Portability
The IIOP Server Listener is supported as a WLE-supplied server on UNIX and Microsoft Windows NT operating systems.
Interoperability
The ISL works with any IIOP compliant ORB.
Network Addresses
Suppose the local machine on which the ISL is being run is using TCP/IP addressing and is named backus.company.com , with address 155.2.193.18 . Further suppose that the port number at which the ISL should accept requests is 2334. The address specified by the -l option could be:
//155.2.193.18:2334
//backus.company.com:2334
Examples
*SERVERS
ISL SRVGRP="ISLGRP" SRVID=1002 RESTART=Y GRACE=0
CLOPT="-A -- -n //piglet:1900 -d /dev/tcp"
Synopsis
Compiles the Object Management Group (OMG) Interface Definition Language (IDL) file and generates client stub and server skeleton files required for the interface definitions being implemented in Java. Use this command only when you are creating a Java server application.
Syntax
m3idltojava [-p] [-j javaDirectory] [-Idirectory][-Dsymbol]
[-Usymbol] [-foptions] idl-filename...Description
The m3idltojava command compiles OMG IDL source files into Java source code. You then use the javac compiler to compile that source into Java bytecodes. The OMG IDL declarations from the named OMG IDL files are translated to Java declarations according to the mapping from OMG IDL to Java.
Given the provided idl-filename file(s), the m3idltojava command generates the following files for each interface defined in the server application's OMG IDL file:
- interface-name .java
- Contains the Java version of the interface definitions in the OMG IDL file. Each interface implementation extends the org.omg.CORBA.Object class.
- _interface-name Stub.java
- Is the client stub file.
- _interface-name ImplBase.java
- Is the Server skeleton file, which is extended by the server application's object implementation classes.
- interface-name Helper.java
- Contains the helper class for the object.
- interface-name Holder.java
- Contains the holder class for the object.
The m3idltojava compiler generates the client stub and server skeleton files. Any previous versions are overwritten.
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.
Parameter
idl-filename
Represents the name of one or more files that contain OMG IDL statements. Options
- -p package
- Specifies that generated Java classes should be part of the given package. The compiler creates the appropriate directory hierarchy and stores the generated files in the directory that corresponds to their package. If you specify the -j option, the hierarchy is created under the specified directory. Otherwise, the hierarchy is created under the current directory. You can override this option by using #pragma javaPackage in the OMG IDL source file.
- -j javaDirectory
- Specifies that generated Java files should be written to the specified directory. This directory is independent of the -p option, if used.
- -I directory
- 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.
- -D symbol
- Specifies a symbol to be defined during OMG IDL file preprocessing. The m3idltojava command passes this symbol to the preprocessor.
- -U symbol
- Specifies a symbol to be undefined during OMG IDL file preprocessing. The m3idltojava command passes this symbol to the preprocessor.
- -f options
- You can enable the following options by specifying them as shown, and disable them by appending the string no- . For example, to prevent the C preprocessor from being run on the input OMG IDL files, specify -fno-cpp .
- -flist-flags
- Displays the state of all -f flags. By default, this option is disabled.
- -fclient
- Generates the client application files. By default, this option is enabled.
- -fserver
- Generates the server application files. By default, this option is enabled.
- -fverbose
- Specifies that the m3idltojava command should work in verbose mode. In particular, it writes command output to its standard output. By default, this option is disabled.
- -fversion
- Specifies that the compiler prints its version and timestamp. By default, this option is disabled.
Examples
The following command generates only the server application files for Simple.idl :
m3idltojava -fno-client Simple.idl
The following command generates only the client application files for Simple.idl :
m3idltojava -fno-server Simple.idl
See the description of the tmadmin command in the BEA TUXEDO Reference manual.
See the description of the tmboot command in the BEA TUXEDO Reference manual.
See the description of the tmconfig command in the BEA TUXEDO Reference manual.
See the description of the tmloadcf command in the BEA TUXEDO Reference manual.
See the description of the tmshutdown command in the BEA TUXEDO Reference manual.
See the description of the tmunloadcf command in the BEA TUXEDO Reference manual.
See the description of the tpgrpadd command in the BEA TUXEDO Reference manual.
See the description of the tpgrpdel command in the BEA TUXEDO Reference manual.
See the description of the tpgrpmod command in the BEA TUXEDO Reference manual.
See the description of the tpusradd command in the BEA TUXEDO Reference manual.
See the description of the tpusrdel command in the BEA TUXEDO Reference manual.
See the description of the tpusrmod command in the BEA TUXEDO Reference manual.
Synopsis
A proxy is a class used by the clients of a remote object to handle the marshaling and unmarshaling of parameters across a network. In RMI, the stub and skeleton class files generated by the RMI compiler are proxies for the RMI client and RMI server objects, respectively.
The Weblogic RMI compiler (weblogic.rmic ) is a tool for generating stubs for RMI clients and skeletons for RMI servers.
To generate stubs and skeletons, run the WebLogic RMI compiler on the fully-qualified package name of the compiled class that contains the remote object implementation. (Note that you must first have generated class files by running the javac compiler on the Java source files.)
Syntax
The syntax for using the WebLogic RMI compiler is as follows:
java weblogic.rmic [options] ClassName
Options
The options to the java weblogic.rmic command are shown in the following table.
The weblogic.rmic command also accepts any option supported by javac -the options are passed directly to the Java compiler.
Description
To create a proxy stub file for the client and skeleton file for the server, you must run the weblogic.rmic compiler on the fully-qualified package names of compiled class files that contain remote object implementations, like my.package.MyImpl_WLstub . The weblogic.rmic command takes one or more class names as an argument and produces class files of the form MyImpl_WLStub.class and MyImpl_WLSkel.class .
(Note that you must first have generated class files by running the javac compiler on the Java source files.)
For example, to generate the stub and skeleton class files for the class classes/my/package/MyImpl.class , you would change directories (cd ) into the classes directory and run the weblogic.rmic command on the generated class file as follows:
java weblogic.rmic -d . my.package.MyImpl
The weblogic.rmic command accepts any option supported by javac -the options are passed directly to the Java compiler. In the example, the -d option indicates the root directory in which to place the compiled stub and skeleton class files. So the preceding command creates the following files in the directory classes/my/package :
MyImpl_WLStub.class
MyImpl_WLSkel.class
The generated stub class implements exactly the same set of remote interfaces as the remote object itself, and handles the necessary encoding (marshaling) and decoding (unmarshaling) of parameters sent across the network.
The skeleton class is also generated by the WebLogic RMI compiler but the skeleton is not used in WebLogic RMI. Generally, the RMI skeleton would unmarshal the invoked method and arguments on the remote object, invoke the method on the instance of the remote object, and then marshal the results for return to the client. WebLogic Enterprise handles the unmarshaling, method invocation, and marshalling on the RMI server side using reflection. If necessary, you can discard the generated skeleton class files to save disk space.
Copyright © 1999 BEA Systems, Inc. All rights reserved.
Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.