|
|
Commands Reference
The WebLogic Enterprise system provides the following commands to build and manage WebLogic Enterprise CORBA applications and WebLogic Enterprise EJBs:
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:
Environment
Variables
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
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
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.
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.
Environment
Variables
Note: Arguments passed by the CFLAGS environment variable take priority over the CPPFLAGS variable.
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
Environment
Variables
Note: Arguments passed by the CFLAGS environment variable take priority over the CPPFLAGS environment variable.
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
UNIX
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
Digital 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
buildtms
See the description of the buildtms command in the BEA Tuxedo Reference manual.
buildXAJS
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
Environment
Variables
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
ejbc
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:
If you specify the -nodeploy option, the ejbc command does not generate any wrapper classes.
Options
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).
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
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:
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
Options
Note: When using the idl command -i option to update your implementation files, proceed as follows to update your implementation files:
Examples
idl emp.idl
idl emp.idl emp.icf
idl2ir
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
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.
Note: Additional definitions loaded into the interface repository while the server process for the Interface Repository is running are not accepted until the server process for the Inteface Repository is stopped and started again.
idltojava
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 WebLogic Enterprise specific revisions are summarized here.
The BEA WebLogic Enterprise idltojava compiler:
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 WebLogic Enterprise server. Neither the client nor the server has any of the WebLogic Enterprise administrative and infrastructure components, such as tmadmin, JNDI registration, and ISL/ISH (hence, none of scalability and reliability attributes of WebLogic Enterprise)
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.
Option |
Description |
---|---|
-j javaDirectory |
Specifies that generated Java files should be written to the given directory. This directory is independent of the -p option, if any. |
-J filesFile |
Specifies that a list of the files generated by idltojava should be written to filesFile |
-p package-name |
Specifies the name of an outer package to enclose all the generated Java. It has the same function as #pragma javaPackage. Note: You must include an outer package. The compiler does not do this for you. If you do not have an outer package, the idltojava compiler will still generate Java files for you but you will get a Java compiler error when you try to compile the *.java files. |
The following options are identical to the equivalent C/C++ compiler options (cpp): |
|
-Idirectory |
Specifies a directory or path to be searched for files that are #included in IDL files. This option is passed to the preprocessor. |
-Dsymbol |
Specifies a symbol to be defined during preprocessing of the IDL files. This option is passed to the preprocessor. |
-Usymbol |
Specifies a symbol to be undefined during preprocessing of the IDL files. This option is passed to the preprocessor. |
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.
Flag |
Description |
-flist-flags |
Requests that the state of all the -f flags be printed. The default value of this flag is off. |
-flist -debug-flags |
Provides a list of debugger flags |
-fcaseless |
Request that case not be significant in keywords and identifiers. The default value of this flag is 'on'. |
-fclient |
Requests the generation of the client side of the IDL files supplied. The default value of this flag is \Qoff'. |
-fcpp |
Requests that the idl source be run through the C/C++ preprocessor before being compiled by the idltojava compiler. The default value of this flag is on. |
-fignore-duplicates |
specifies that duplicate definitions be ignored. This may be useful if compiling multiple idl files at one time. The default value of this flag is off. |
-flist-options |
Lists the options specified on the command line. The default value of this flag is off. |
-fmap-included-files |
Specifies that java files be generated for definitions included by #include preprocessor directives. The default value for this flag is off which specifies that the java files for included definitions not be generated. |
-fserver |
Requests the generation of the server side of the IDL files supplied. The default value of this flag is off. |
-fverbose |
Requests that the compiler comment on the progress of the compilation. The default value of this flag is off. |
-fversion |
Requests that the compiler print its version and timestamp. The default value of this flag is off. |
-fwarn-pragma |
Requests that warning messages be issued for unknown or improperly specified #pragma's. The default value of this flag is on. |
-fwrite-files |
Requests that the derived java files be written. The default value of this flag is 'on'. You might specify -fno-write-files if you wished to check for errors without actually writing the files. |
The BEA WebLogic Enterprise 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.
ir2idl
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
irdel
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
ISL
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 ]
[-E principal_name]
[ -K {client|handler|both|none} ]
[ -m minh ]
[ -M maxh ]
[ -T Client-timeout]
[ -x mpx-factor ]
[-H external-netaddr]
[-O]
[-o outbound-max-connections]
[-s Server-timeout]
[-u out-mpx-users]"
[-R renegotiation-interval]
[-S secure port]
[-v {detect|warn|none} ]
[-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
You specify the following options in the CLOPT string after the double-dash (--) in the CLOPT parameters:
"//#.#.#.#:port_number"
Note: The hostname must begin with a letter character.
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.
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).
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.
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.
Depending on the type of remote object and the desired outbound IIOP configuration, you may have to perform additional programming tasks. lists the requirements for each type of object and outbound IIOP configuration.
Types of Objects |
Asymmetric Requirements |
Paired-connection Requirements |
Bidirectional Requirements |
Remote joint client/servers |
Set ISL CLOPT -O option. |
Use the Tobj_Bootstrap::register_callback_port method to register the callback port. |
Use the CORBA::ORB::create_policy method to set BiDirPolicy on the POA. |
Foreign (non-WLE) ORBs |
Set ISL CLOPT -O option. |
Not applicable. |
If the foreign ORB supports the POA and BiDirPolicy, use the CORBA::ORB::create_policy method to set BiDirPolicy on the POA. |
Remote clients |
Remote clients are not servers, so outbound IIOP is not possible. |
||
Native joint client/servers |
Outbound IIOP is not used. |
||
Native clients |
Outbound IIOP is not used. |
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"
m3idltojava
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:
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
Options
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
tmadmin
See the description of the tmadmin command in the BEA Tuxedo Reference manual.
tmboot
See the description of the tmboot command in the BEA Tuxedo Reference manual.
tmconfig
See the description of the tmconfig command in the BEA Tuxedo Reference manual.
tmloadcf
See the description of the tmloadcf command in the BEA Tuxedo Reference manual.
tmshutdown
See the description of the tmshutdown command in the BEA Tuxedo Reference manual.
tmunloadcf
See the description of the tmunloadcf command in the BEA Tuxedo Reference manual.
tpgrpadd
See the description of the tpgrpadd command in the BEA Tuxedo Reference manual.
tpgrpdel
See the description of the tpgrpdel command in the BEA Tuxedo Reference manual.
tpgrpmod
See the description of the tpgrpmod command in the BEA Tuxedo Reference manual.
tpusradd
See the description of the tpusradd command in the BEA Tuxedo Reference manual.
tpusrdel
See the description of the tpusrdel command in the BEA Tuxedo Reference manual.
tpusrmod
See the description of the tpusrmod command in the BEA Tuxedo Reference manual.
weblogic.rmc
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.
Option |
Description |
---|---|
-help |
Prints the complete list of command line options. |
-version |
Prints version information. |
-d <dir> |
Indicates (top-level) directory for compilation. |
-notransactions |
Skip transaction context propagation |
-verbosemethods |
Instruments proxies to print debug information to std err. |
-descriptor <example> |
Associates or creates a descriptor for each remote class. |
-visualCafeDebugging |
Instruments proxies to support distributed debugging under VisualCafe. |
-v1.2 |
Generates Java 1.2 style stubs |
-keepgenerated |
Keeps the generated .java files. |
-commentary |
Emit commentary. |
-compiler <JavaCompiler> |
Explicitly indicate which Java compiler to use. For example: java weblogic.rmic -compiler sj examples.hello.HelloImpl |
-g |
Compile debugging info into class file. |
-O |
Compile with optimization on. |
-debug |
Compile with debugging on. |
-nowarn |
Compile without warnings. |
-verbose |
Compile with verbose output. |
-nowrite |
Do not generate .class files. |
-deprecation |
Warn about deprecated calls. |
-normi |
Passed through to the Symantec sj compiler. |
-J<option> |
Flags passed through to java runtime. |
-classpath <path> |
Classpath to use during compilation. |
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 © 2000 BEA Systems, Inc. All rights reserved.
|