| Oracle® Containers for J2EE Deployment Guide 10g (10.1.3.1.0) Part Number B28951-01 |
|
|
View PDF |
| Oracle® Containers for J2EE Deployment Guide 10g (10.1.3.1.0) Part Number B28951-01 |
|
|
View PDF |
OC4J provides a command-line utility, admin_client.jar, for performing deployment tasks on active OC4J instances in an Oracle Application Server clustered environment as well as on a standalone OC4J server. In addition, you can use admin_client.jar to restart or stop an OC4J instance or group of instances.
The admin_client.jar utility is also part of an administration client for performing operations remotely, available on the companion CD for Oracle Application Server 10g Release 3 (10.1.3.1.0) or for downloading from Oracle Technology Network.
You can perform deployment operations on a specific OC4J instance or simultaneously on all OC4J instances in a group. In Oracle Application Server 10g Release 3 (10.1.3.1.0), a group is a synchronized set of OC4J instances that belong to the same cluster topology, which is two or more loosely connected Oracle Application Server nodes. With the admin_client.jar command-line utility, you can perform the following operations on an OC4J instance or group of instances within a cluster:
Deploy an application (EAR), a standalone Web module (WAR), a standalone EJB module (EJB JAR), or a standalone resource adapter (RAR)
Undeploy an application, Web module, EJB module, or resource adapter
Incrementally update a deployed EJB module with modified classes
Create, modify, or remove shared libraries for an application
Start, restart, or stop applications
Restart or stop an OC4J instance or group of instances
Add, test, and remove data sources and data source connection pools
Add and remove JMS connection pools and destinations
You can perform similar operations through Application Server Control Console or the OC4J Ant tasks. For more information, see Chapter 9, "Using the Application Server Control Console for Deployment" or Chapter 10, "Using OC4J Ant Tasks for Deployment".
This chapter includes the following topics:
The admin_client.jar utility is installed by default in the ORACLE_HOME/j2ee/instance directory in each OC4J instance. This is the preferred command-line tool for performing operations on OC4J. This utility is also in the administration client for performing operations remotely, available on the companion CD for Oracle Application Server 10g Release 3 (10.1.3.1.0) or for downloading from Oracle Technology Network.
Before this utility can perform operations on an OC4J instance, the instance must be started.
This section covers these topics:
The admin_client.jar utility uses the following syntax:
java -jar admin_client.jar uri adminId adminPassword command
The key parameter passed on the command line is uri, which specifies the target for the command or commands supplied. The syntax for the URI varies depending on the instance or instances being targeted. See the following topics for the format of this URI:
The OC4J administration user name and password are also passed to the admin_client.jar utility. The user name for the default administrator account is oc4jadmin.
As an example, the following command will start the petstore application, which is installed in the OC4J instance named oc4j_2 on node1, a member of a cluster:
java -jar admin_client.jar deployer:oc4j:opmn://node1.company.com/oc4j_2 oc4jadmin password -application petstore -start
Figure 11-1 shows four processes that are configured to run from an OC4J instance named OC4J_home in one of the Oracle Application Server instances within a cluster.
Figure 11-1 OC4J Instance Running on Multiple JVMs in an Oracle Application Server Instance Within a Cluster
|
Note: The OC4J instance namedhome typically cannot be configured to run with multiple processes because it hosts the Application Server Control application, which is not suitable for running in the multiple-process model. |
Use the following URI to specify all OC4J instances in a group as the deployment target. A group is a synchronized set OC4J instances that belong to the same cluster topology. You can perform deployment operations simultaneously on all OC4J instances in the group. For example, you could specify default_group as the target to perform a deployment operation simultaneously on all OC4J instances that belong to the default group (named default_group) in a cluster.
The URI utilizes the OPMN-based clustering framework, in which cluster nodes are aware of one another. You need to supply only the host name and, optionally, the OPMN request port for any Oracle Application Server node within the cluster. The application is then able to retrieve the host names and OPMN ports for all other nodes within the cluster.
The URI syntax follows:
deployer:cluster:[rmis]:opmn://opmnHost[:opmnPort]/groupName
For example:
deployer:cluster:opmn://node1.company.com/default_group
Table 11-1 URI Parameters for Targeting a Group
| Parameter | Description |
|---|---|
|
rmis |
Optional. Include if the target utilizes ORMI over SSL, or ORMIS. |
|
|
Required. The host name of an Oracle Application Server node within a cluster. Any node can be specified; the list of other nodes in the cluster will be retrieved from this node. |
|
|
Optional. The OPMN request port, as specified in |
|
|
Required. The name of the group to which the OC4J instances belong, within a cluster. |
Use the following URI syntax to target a specific OPMN-managed OC4J instance, including an instance within a cluster. In the prefix, oc4j replaces cluster.
Specify the host name for the Oracle Application Server node hosting the instance. If you are not sure of the host name or port for the node, you can specify the host name for another node within the cluster, as well as the name of the Oracle Application Server instance. The application will then use the OPMN clustering framework to locate the node hosting the Oracle Application Server instance.
The URI syntax follows:
deployer:oc4j:[rmis]:opmn://host[:opmnPort]/[iASInstanceName]/oc4jInstanceName
For example:
deployer:oc4j:opmn://server.company.com:6004/instance2/home
Table 11-2 URI Parameters for Targeting a Specific Instance
| Parameter | Description |
|---|---|
|
|
Optional. Include if the target utilizes ORMI over SSL, or ORMIS. |
|
|
Required. The host name of the Oracle Application Server node to target within the cluster to use as the OPMN server. |
|
|
Optional. The OPMN request port, as specified in |
|
|
Optional. The name of the Oracle Application Server instance to target, if it does not reside on the node specified for |
|
|
Required. The name of the target OC4J instance. |
Use one of the following URIs to target a standalone OC4J server instance.
If you are using RMI, specify the URI as follows:
deployer:oc4j:host:rmiPort
If you are using ORMI over SSL (ORMIS), specify the URI as follows:
deployer:oc4j:rmis:host:ormisPort
For example:
deployer:oc4j:myserver:23791 deployer:oc4j:rmis:myserver:23943
Table 11-3 URI Parameters for Targeting Standalone OC4J
| Parameter | Description |
|---|---|
|
|
Required if the target utilizes ORMI over SSL, or ORMIS. |
|
|
Required. The host name of an Oracle Application Server node within the cluster. Any node can be specified; the list of other nodes in the cluster will be retrieved from this node. |
|
|
Required if RMI used. The RMI port, as specified in the instance-specific |
|
|
Required if ORMIS used. The SSL port, as specified in the instance-specific |
The administration client distribution contains the admin_client.jar command-line utility. This utility can connect to OC4J or Oracle Application Server targets and perform a range of lifecycle, deployment, and resource configuration operations.
Consider the scenario in which a remote system needs to perform regular operations against an Oracle Application Server instance. For example, a remote system might have some automated build or test process, such as deployment operations or querying or manipulating some application-specific or server JMX MBeans for administrative purposes. Or perhaps the remote system performs a regularly scheduled test to production set of configuration and deployment operations. The administration client distribution can be used to do this, removing the need for the remote system to have a full OC4J or Oracle Application Server installation.
The administration client, a separate distribution for Oracle Application Server 10g Release 3 (10.1.3.x), is available for downloading from the Oracle Technology Network and is on the Oracle Application Server companion CD. The oc4j_admin_client_101310.zip file contains all you need to manage OC4J instances remotely:
The Java libraries required to establish remote JMX connections, using the ORMI protocol, to either an OC4J or Oracle Application Server target
The executable admin_client.jar utility with the libraries it requires to operate
The standard J2EE libraries relevant to the remote client role
To get started with the administration client distribution:
Download oc4j_admin_client_101310.zip from the Oracle Technology Network:
http://download.oracle.com/otn/java/oc4j/10131/oc4j_admin_client_101310.zip
Extract the contents of oc4j_admin_client_101310.zip into a local directory. For example:
>mkdir oc4j_admin_client >cd oc4j_admin_client >jar xvf d:\software\oc4j_admin_client_101310.zip
The resulting directory structure looks like this:
\j2ee
\home
oc4jclient.jar
admin_client.jar
\lib
ejb.jar
mail.jar
adminclient.jar
javax88.jar
javax77.jar
jmx_remote_api.jar
jmxri.jar
\lib
xmlparserv2.jar
dms.jar
\opmn
\lib
optic.jar
\jlib
oraclepki.jar
ojpse.jar
The following URIs use different patterns for different OC4J targets:
Standalone OC4J server:
deployer:oc4j:test-cycle.oracle.com:23791
Specific OC4J instance on Oracle Application Server:
deployer:oc4j:opmn://test-cycle.oracle.com/testunit
Group of OC4J instances within a cluster:
deployer:cluster:opmn://test-cycle.oracle.com/[groupName]
Connect admin_client.jar to a target OC4J instance or instances and test the connection. For example:
>cd j2ee\home
>java -jar admin_client.jar
deployer:oc4j:opmn://test-cycle.oracle.com/testunit
oc4jadmin welcome1
–validateURI
URI deployer:oc4j:opmn://test-cycle.oracle.com/testunit is valid and connected
To print the online help text for the admin_client.jar commands to the console, simply type -help on the command line. For example:
java -jar admin_client.jar -help
To view detailed help for a specific command, type -usage followed by the command identifier. For example:
java -jar admin_client.jar -usage [command]
To help troubleshoot errors that occur when running admin_client.jar, you can enable Java logging when running this tool. Log messages will be output to the console.
To enable logging:
Create a logging.properties file containing a single line:
oracle.oc4j.admin.jmx.client.CoreRemoteMBeanServer.level=INFO
If you create this file in a location other than ORACLE_HOME/j2ee/instance, you must include the path to the file in the following command.
Set -Djava.util.logging.config.file=logging.properties on the admin_client.jar command line as follows:
java -Djava.util.logging.config.file=logging.properties -jar admin_client.jar uri adminId adminPassword command
You can set the value in the logging.properties file to one of the Java log-level values in Table 11-4.
Table 11-4 Java Log Levels
| Java Log Level | Description |
|---|---|
SEVERE |
Log system errors requiring attention from the system administrator. |
WARNING |
Log actions or a conditions discovered that should be reviewed and may require action before an error occurs. |
INFO |
Log normal actions or events. This could be a user operation, such as login completed, or an automatic operation, such as a log file rotation. |
CONFIG |
Messages or problems related to log configuration. |
FINE |
Log trace or debug messages used for debugging or performance monitoring. Typically contains detailed event data. |
FINER |
Log fairly detailed trace or debug messages. |
FINEST |
Log highly detailed trace or debug messages. |
For example:
oracle.oc4j.admin.jmx.client.CoreRemoteMBeanServer.level=FINE
You can use the admin_client.jar utility to deploy an application (EAR), a standalone Web module (WAR), or a standalone resource adapter (RAR) to a specific OC4J instance or to a group of instances within a cluster.
This chapter covers the following topics:
|
Note: Deploying an archive across a cluster requires that all instances have the sameoc4jadmin account password. |
Use the -deploy command to deploy or redeploy a J2EE application packaged as an EAR file. The EAR-specific syntax follows:
java -jar admin_client.jar uri adminId adminPassword -deploy -file path/filename -deploymentName appName [-bindAllWebApps [webSiteName]] [-targetPath path] [-parent appName] [-deploymentDirectory path] [-enableIIOP] [-iiopClientJar path/filename] [-deploymentPlan path/filename] [-removeArchive]
Ideally, you should include the -bindAllWebApps subswitch to bind all Web modules within the EAR to the Web site through which they will be accessed. If no Web site is specified, modules will be bound to the default Web site.
For example, the following command deploys the utility application to all OC4J instances that belong to the group default_group within a cluster. All Web modules within the application will be bound to the default Web site.
java -jar admin_client.jar deployer:cluster:opmn://node1.company.com/default_group oc4jadmin password -deploy -file C:/dev/utility.ear -deploymentName utility -bindAllWebApps
Table 11-5 -deploy Command Subswitches for EAR Deployment
| Subswitch | Description |
|---|---|
|
|
Required. The path and file name of the EAR file to deploy. |
|
|
Required. The user-defined application deployment name, used to identify the application within OC4J. |
|
|
Optional. Binds all Web modules to the specified Web site, or to the You can optionally supply a value for |
|
|
Optional. The directory to deploy the EAR to. If not specified, the EAR is deployed to the The deployed EAR file is also copied to this directory. Each successive deployment will cause this EAR file to be overwritten. |
|
|
Optional. The parent application of this application. The default is the |
|
|
Optional. The path and file name for a deployment plan to apply to the application. The plan would have been saved during a previous deployment as an XML file. The file must exist on the local host. |
|
|
Optional. The directory containing the OC4J-specific deployment descriptors and generated files, such as compiled JSP classes and EJB wrapper classes. The default directory is |
|
|
Optional. Include to deploy the archive to each OC4J instance within a cluster in sequence. Requests will not be routed to an instance while the EAR is being deployed to it. If not included, the archive is simultaneously deployed to all instances by default. This option is valid in a clustered environment only; it is not valid for standalone OC4J. |
|
|
Optional. Include to generate IIOP client stubs on the OC4J server. The application-level stubs generated for all EJB modules are output to an archive named The |
|
|
Optional. The path and filename of the JAR to output IIOP client stubs to. The application-level stubs generated for all EJB modules are output to an archive named In addition, stubs for each individual EJB module are generated in an archive with the same name in the Note that the |
|
|
Optional. Include to delete the EAR file from the server's file system after deployment. |
The following example shows how to deploy an EAR from a remote client to a specific OC4J instance on Oracle Application Server:
cd j2ee/home >java -jar admin_client.jar deployer:oc4j:opmn://test-cycle.oracle.com/testunit oc4jadmin welcome1 -deploy -file d:\temp\rupg\testru.ear -deploymentName testru –bindAllWebApps 06/06/20 17:00:16 Notification ==>Uploading file testru.ear ... 06/06/20 17:00:18 Notification ==>Application Deployer for testru STARTS. 06/06/20 17:00:19 Notification ==>Copy the archive to /scratch/sbutton/m1_060618/j2ee/admin/applications/testru.ear 06/06/20 17:00:19 Notification ==>Initialize /scratch/sbutton/m1_060618/j2ee/admin/applications/testru.ear begins... 06/06/20 17:00:19 Notification ==>Unpacking testru.ear 06/06/20 17:00:20 Notification ==>Done unpacking testru.ear 06/06/20 17:00:20 Notification ==>Unpacking testru-web.war 06/06/20 17:00:20 Notification ==>Done unpacking testru-web.war 06/06/20 17:00:20 Notification ==>Initialize /scratch/sbutton/m1_060618/j2ee/admin/applications/testru.ear ends... 06/06/20 17:00:20 Notification ==>Starting application : testru 06/06/20 17:00:20 Notification ==>Initializing ClassLoader(s) 06/06/20 17:00:20 Notification ==>Initializing EJB container 06/06/20 17:00:20 Notification ==>Loading connector(s) 06/06/20 17:00:20 Notification ==>Starting up resource adapters 06/06/20 17:00:20 Notification ==>Initializing EJB sessions 06/06/20 17:00:20 Notification ==>Committing ClassLoader(s)06/06/20 17:00:20 Notification ==>Initialize testru-web begins... 06/06/20 17:00:20 Notification ==>Initialize testru-web ends... 06/06/20 17:00:21 Notification ==>Started application : testru 06/06/20 17:00:21 Notification ==>Binding web application(s) to site default-web-site begins... 06/06/20 17:00:21 Notification ==>Binding testru-web web-module for application testru to site default-web-site under context root /testru 06/06/20 17:00:22 Notification ==>Binding web application(s) to site default-web-site ends... 06/06/20 17:00:22 Notification ==>Application Deployer for testru COMPLETES. Operation time: 3785 msecs
Use the -deploy command to deploy or redeploy a standalone Web module packaged as a WAR file.
The WAR-specific syntax follows:
java -jar admin_client.jar uri adminId adminPassword -deploy -file path/filename -deploymentName appName [-bindAllWebApps [webSiteName]] [-targetPath path] [-parent appName] [-deploymentDirectory path] [-contextRoot context] [-removeArchive]
The WAR can be designated a child of another deployed application that does not already contain a Web module component; otherwise, it will be deployed to the default application.
A WAR cannot be deployed as the child of an application that already contains a Web module. That is, if the acme application already contains acme-web.war, an additional WAR file cannot be deployed into that application. Repackage the WAR in the application's EAR file and redeploy the application instead.
The following command deploys the standalone acme-web.war Web module to the default application in all OC4J instances that belong to default_group within the cluster of which node1 is a member. Because the -bindAllWebApps subswitch is included, but a Web site to bind to is not specified, the module will be bound to the default Web site.
java -jar admin_client.jar deployer:cluster:opmn://node1.company.com/default_group oc4jadmin password -deploy -file C:/dev/acme-web.war -deploymentName utility -bindAllWebApps -parent default
Table 11-6 -deploy Command Subswitches for WAR Deployment
| Subswitch | Description |
|---|---|
|
|
Required. The path and file name of the archive to deploy. |
|
|
Required. The user-defined Web module name, used to identify it within OC4J. |
|
|
Optional. Binds all Web modules to the specified Web site, or to the You can optionally supply a value for |
|
|
Optional. The directory to deploy the archive to. If not specified, the archive is deployed to the The generated EAR file containing the standalone WAR file is also copied to this directory. Each successive deployment will cause this archive to be overwritten. |
|
|
Optional. The parent application the module will be deployed to. The default is the |
|
|
Optional. The directory containing the OC4J-specific deployment descriptors and generated files, such as compiled JSP classes. The default directory is |
|
|
Optional. The Web module context, which will be appended to the URL used to access the application through a Web browser. If not specified, the value passed in for For example, if you supply
|
|
|
Optional. Include to delete the WAR file from the server's file system after deployment. |
Use the -deploy command to deploy or redeploy a Java Connector Architecture-compliant resource adapter packaged as a RAR file. By default, resource adapters are deployed to the ORACLE_HOME/j2ee/instance/connectors directory.
Redeploying or undeploying a standalone RAR does not require a restart of the default application.
The RAR-specific syntax follows:
java -jar admin_client.jar uri adminId adminPassword -deploy -file path/filename -deploymentName connectorName [-nativePathLib path] [-grantAllPermissions] [-removeArchive]
The following command deploys the acme-rar.rar module to all OC4J instances that belong to default_group within a cluster.
java -jar admin_client.jar deployer:cluster:opmn://node1.company.com/default_group oc4jadmin password -deploy -file /dev/acme-rar.rar -deploymentName acme-rar -grantAllPermissions -removeArchive
Table 11-7 -deploy Command Subswitches for RAR Deployment
| Subswitch | Description |
|---|---|
|
|
Required. The path and file name of the RAR file to deploy. |
|
|
Required. The user-defined connector name, used to identify the connector within OC4J. |
|
|
Optional. The path to the directory containing native libraries (such as DLLs) within the RAR file. |
|
|
Optional. Include to grant all runtime permissions requested by the resource adapter, if required. |
|
|
Optional. Include to delete the RAR file from the server's file system after deployment. |
For more information, see Chapter 6, "Deploying Resource Adapters".
You can specify a script file that contains deployment commands on the admin_client.jar command line. If you specify a file in the -script command, admin_client.jar can do a list of commands with only one connection to the deployment manager. The syntax for batch deployment follows:
java -jar admin_client.jar uri adminId adminPassword -script filename
The script file, filename, contains multiple lines, like the lines in this example:
-deploy -file /scratch/rpan/apps/hello-planet.ear -deploymentName hello-planet -bindWebApp -appName hello-planet -webModuleName hello-planet-web -stop hello-planet -start hello-planet -redeploy -file /scratch/rpan/apps/hello-planet.ear -deploymentName hello-planet -bindAllWebApps -undeploy hello-planet -validateURI
You can convert to batch mode by looking at the script or logs from an installation and extracting the relevant lines used by an existing configuration assistant.
Every Web module deployed to OC4J must be bound to a Web site through which it will be accessed.
Typically, you will bind Web modules packaged as WAR files within an EAR at the time the EAR is deployed using the -bindAllWebApps subswitch on the -deploy command. However, if the -bindAllWebApps subswitch was not specified when the EAR was deployed, you can bind modules to a Web site after deployment, as the following topics describe:
Use the -bindAllWebApps command to bind all Web modules within a J2EE application to the same Web site, or to default-web-site by default. The syntax for this command follows:
java -jar admin_client.jar uri adminId adminPassword -bindAllWebApps -appName appName -webSiteName siteName
Table 11-8 -bindAllWebApps Command Subswitches
| Subswitch | Description |
|---|---|
|
|
Required. The name of the parent application as specified at deployment time. |
|
|
Optional. The name of the |
Use the -bindWebApp command to bind a single Web module within a J2EE application to a specific Web site, or to default-web-site by default. You can also optionally set the context root that will be used to access the module.
The syntax follows:
java -jar admin_client.jar uri adminId adminPassword -bindWebApp -appName appName -webModuleName moduleName -webSiteName siteName -contextRoot contextRoot
Table 11-9 -bindWebApp Command Subswitches
| Subswitch | Description |
|---|---|
|
|
Required. The name of the parent application as specified at deployment time. |
|
|
Required. The name of the Web module to be bound. This should be the name of the WAR file contained within the EAR file, without the |
|
|
Optional. The name of the |
|
|
Optional. The context root for the Web module. This will be appended to the URL used to access the application through a Web browser; for example:
If not supplied, the context root specified in the parent application's |
Use the -redeploy command to redeploy a previously deployed archive.
This operation performs a graceful redeployment because it stops the application if it is running and then undeploys the archive. It then deploys and restarts the application. Redeploying an archive with the -deploy command, in contrast, does not stop the application but simply undeploys, redeploys, and then restarts it.
The syntax follows:
java -jar admin_client.jar uri adminId adminPassword -redeploy -file path/filename -deploymentName appName [-keepSettings] [-sequential] -removeArchive
Table 11-10 -redeploy Command Subswitches
| Subswitch | Description |
|---|---|
|
|
Required. The path and file name of the EAR file to deploy. |
|
|
Required. The user-defined application deployment name, used to identify the application within OC4J. This value must exactly match the name of the existing application on the server. |
|
|
Optional. If included, the redeployed application will fetch and use the deployment plan from the previous deployment. Values set in deployment descriptors packaged within the archive will be ignored. If not specified, values will be set to those in the deployment descriptors packaged with the archive. |
|
|
Optional. Include to deploy the archive to each OC4J instance within a cluster in sequence. The redeployment on each target must complete before continuing on to the next target. Requests will not be routed to an instance while the EAR is being deployed to it. If not included, the archive is simultaneously deployed to all instances by default. This option is valid in a clustered environment only; it is not valid for standalone OC4J. |
|
|
Optional. Include to delete the EAR file from the server's file system after deployment. |
The -undeploy command removes an application or standalone Web or connector module from the target OC4J instances, as the following topics describe:
Undeploying an EAR or standalone Web module removes it from the OC4J runtime. Existing Web site bindings are also deleted.
The syntax for undeploying an EAR or standalone WAR follows. The name of the application or module must be supplied.
java -jar admin_client.jar uri adminId adminPassword -undeploy appName
The syntax for undeploying a standalone RAR follows. The -isConnector subswitch must be included along with name of the connector.
java -jar admin_client.jar uri adminId adminPassword -undeploy connectorName -isConnector
Undeploying a standalone RAR does not require a restart of the default application.
The -updateEJBModule command performs incremental or partial redeployment of EJB modules within an application running in an OC4J instance or in a group of instances within a cluster. This feature makes it possible to redeploy only those beans within an EJB JAR that have changed, without requiring the entire module to be redeployed.
|
Note: Incremental redeployment may be more efficient than redeploying the entire application for CMP or BMP entity beans but not for session beans, message-driven beans, or EJB 3.0 JPA entities. For details about whether to use this feature, see "Incremental Redeployment of Updated EJB Modules". |
The syntax for updating modified classes in a deployed EJB module follows. The name of the application the EJB JAR is part of must be supplied. If updating a standalone EJB module, specify the default application.
java -jar admin_client.jar uri adminId adminPassword -updateEJBModule -appName appName -ejbModuleName ejbJarName -file path/ejbJarName
For example:
java -jar admin_client.jar deployer:cluster:opmn://node1.company.com/default_group oc4jadmin password -updateEJBModule -appName petstore -ejbModuleName customerEjb.jar -file build/customerEjb.jar
Table 11-11 -updateEJBModule Syntax
| Option | Description |
|---|---|
|
|
Required. The name of the application the EJB is part of. If updating a standalone EJB module, specify the |
|
|
Required. The name of the EJB JAR file to be updated as defined in |
|
|
Required. The path and file name of the updated EJB JAR. |
You can use the admin_client.jar utility to create and manage shared libraries in an OC4J instance or in a group of instances within a cluster, as the following topics describe:
You can use the -publishSharedLibrary command to create the shared library directory structure and install the binaries that compose the library within it in a specific OC4J instance or in a group of instances within a cluster. The shared library will be created in the ORACLE_HOME/j2ee/instance/shared-lib directory of each OC4J instance.
The command will also declare the shared library within a <shared-library> element in the server.xml file on each OC4J instance, making it available to applications.
The syntax for installing a shared library follows. The path and file names for multiple code sources, binaries that will compose the shared library, can be specified, each separated from the next by a space.
java -jar admin_client.jar uri adminId adminPassword -publishSharedLibrary -name libName -version libVersion [-parentName parentLibName] [-parentVersion parentLibVersion] [-installCodeSources path [path ...]] [-addCodeSources path [path ...]] [-imports sharedLibName [:min-version][,max-version] [sharedLibName ...]]
The following command deploys the acme.common:2.5 shared library to a group of OC4J instances (all the members of default_group) within a cluster.
java -jar admin_client.jar deployer:cluster:opmn://server.company.com:6004/default_group oc4jadmin password -publishSharedLibrary -name acme.common -version 2.5 -installCodeSources /myserver/tmp/acme-apis.jar /myserver/tmp/acmeImpl.jar
The resulting directory structure within a target OC4J server would be as follows:
ORACLE_HOME/j2ee/home/shared-lib
/acme.common
/2.5
acme-apis.jar
acmeImpl.jar
Table 11-12 -publishSharedLibrary Command Subswitches
| Subswitch | Description |
|---|---|
|
|
Required. The name of the shared library. Where common APIs are implemented by multiple vendors, the name should include both the vendor name and the name of the technology; for example, |
|
|
Required. The version number of the shared library. This value should ideally reflect the code implementation version. |
|
|
Optional. The name of the parent shared library, if applicable. |
|
|
Optional. The version number of the parent shared library, if applicable. |
|
|
The path and file names for one or more JAR or ZIP files to be uploaded to the OC4J instance or instances and installed as part of the shared library. Separate each path/file name string from the next with a space. |
|
|
Optional. The path and file names for JAR or ZIP files that have already been uploaded to the OC4J instance or instances to add to the shared library. Separate each path/file name string from the next with a space. |
|
|
Optional. The name of one or more existing shared libraries to import into this shared library. Separate each name string from the next with a space. You can specify the maximum or minimum version, or both, of the library to import. |
You can use the -modifySharedLibrary command to modify the contents of an existing shared library. The command will also update the shared library definition within the server.xml file on each OC4J instance.
The syntax for modifying an existing shared library follows. The path and file names for multiple code sources, binaries that will compose the shared library, can be specified, each separated from the next by a space.
java -jar admin_client.jar uri adminId adminPassword -modifySharedLibrary -name libName -version libVersion [-installCodeSources path [path ...]] [-addCodeSources path [path ...]] [-removeCodeSources path [path ...]] [-addImports sharedLibName[:min-version][,max-version] [sharedLibName ...]] [-removeImports sharedLibName[:min-version][,max-version] [sharedLibName ...]]
The following command updates the acme.common:2.5 shared library.
java -jar admin_client.jar deployer:cluster:opmn://server.company.com:6004/default_group oc4jadmin password -modifySharedLibrary -name acme.common -version 2.5 -addCodeSources /myserver/tmp/acme-helpers.jar
Table 11-13 -modifySharedLibrary Command Subswitches
| Subswitch | Description |
|---|---|
|
|
Required. The name of the shared library to update. |
|
|
Required. The version number of the shared library to update. |
|
|
Optional. The path and file name to a JAR or ZIP file to be uploaded to the OC4J instance or instances and installed as part of the shared library. Separate each path/file name string from the next with a space. |
|
|
Optional. The path and file name for one or more JAR or ZIP files that have already been uploaded to the OC4J instance or instances to add to the shared library. Separate each path/file name string from the next with a space. |
|
|
Optional. The path and file name for one or more JAR or ZIP files to remove from the shared library. Separate each path/file name string from the next with a space. |
|
|
Optional. The name of one or more existing shared libraries to import into this shared library. Separate each name string from the next with a space. You can specify the maximum or minimum version, or both, of the library to import. |
|
|
Optional. The name of one or more existing shared libraries to remove from this shared library. You can specify the maximum or minimum version, or both, of the library to remove. |
Use the -describeSharedLibrary command to view the code sources and imported shared libraries that compose the specified shared library. The syntax follows:
java -jar admin_client.jar uri adminId adminPassword -describeSharedLibrary -name libName -version libVersion
Use the -listSharedLibraries command to output a list of all shared libraries defined on the target OC4J instance or instances. The syntax follows:
java -jar admin_client.jar uri adminId adminPassword -listSharedLibraries
You can use the admin_client.jar utility to start, restart, or stop an application and its child applications in a specific OC4J instance or in a group of instances within a cluster. If a file within the application has been modified, the application will be automatically redeployed at startup.
You can even stop and start Application Server Control Console (ascontrol) using these commands.
The syntax follows:
java -jar admin_client.jar uri adminId adminPassword -start|-stop appName
The following example starts the petstore application on node2 within the cluster:
java -jar admin_client.jar deployer:oc4j:opmn://node2.company.com:6004/home oc4jadmin password -start petstore
You can use the admin_client.jar utility to stop a standalone OC4J server, a specific OC4J instance in a managed environment, or a group of instances within a cluster. The -shutdown command shuts down the specified OC4J instance or instances and for any OPMN-managed instance, notifies OPMN that it is being shut down. The -restart command restarts the specified instance or instances.
The following topics provide the syntax and examples for these commands:
Use the admin_client.jar -restart command, as follows, to restart an OC4J instance or group of instances within a cluster:
java -jar admin_client.jar uri adminId adminPassword -restart
For example, the following command restarts a standalone OC4J server:
java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin password -restart
The following command restarts all of the OC4J instances that are members of default_group in each Oracle Application Server within the cluster topology:
java -jar admin_client.jar deployer:cluster:opmn://node1.company.com/default_group oc4jadmin password -restart
Use the admin_client.jar -shutdown command, as follows, to stop an OC4J instance or group of instances within a cluster:
java -jar admin_client.jar uri adminId adminPassword -shutdown
For example, the following command stops a standalone OC4J server:
java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin password -shutdown
This command shuts down the entire OC4J server, terminating all threads immediately, as if the host machine were unplugged. If you use this command, the current state for clustered applications will not be replicated.
The following command stops the specified OC4J instance in an Oracle Application Server managed environment:
java -jar admin_client.jar deployer:oc4j:opmn://localhost/home oc4jadmin password -shutdown
The next command stops all of the OC4J instances that are members of default_group in each Oracle Application Server within the cluster topology:
java -jar admin_client.jar deployer:cluster:opmn://node1.company.com/default_group oc4jadmin password -shutdown
These commands shut down the specified instance or instances and terminate all threads immediately. If you use the -shutdown command, the current state for clustered applications will not be replicated. For each OPMN-managed OC4J instance, admin_client.jar notifies OPMN that the server is being shut down on purpose, to prevent OPMN from attempting to restart it.
You can use the admin_client.jar utility to manage data sources in an OC4J instance or in a group of instances within a cluster, as the following topics describe:
You can use the admin_client.jar utility to add, test, and remove data source connection pools in an OC4J instance or in a group of instances within a cluster, as the following topics describe:
Use the -addDataSourceConectionPool command to add a data source connection pool for an application in an OC4J instance or in each OC4J instance of a group within a cluster.
The syntax for adding a data source connection pool follows:
java -jar admin_client.jar uri adminId adminPassword -addDataSourceConectionPool -applicationName applicationName -name name -factoryClass factoryClass -user user -password password -url url [-factoryProperties name1 value1 [name2 value2 [...]]]
For example:
java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 -addDataSourceConectionPool -applicationName default -name ScottConnectionPool -factoryClass oracle.jdbc.pool.OracleDataSource -user scott -password tiger -url jdbc:oracle:thin:@localhost:1521:xe
Table 11-16 -addDataSourceConectionPool Command Subswitches
| Subswitch | Description |
|---|---|
|
|
Required. The name of the application for which to add the data source connection pool. |
|
|
Required. The name of the connection pool. |
|
|
Required. The fully qualified path of the connection factory implementation. |
|
|
Required. The default user name to use to get connections. |
|
|
Required. The default password to use to get connections. |
|
|
Required. The connection factory URL to use to get connections. |
|
|
Optional. One or more property name and value pairs to set on the connection factory definition. |
Use the -testDataSourceConnectionPool command to test an application's connection to a data source connection pool in an OC4J instance or in each OC4J instance of a group within a cluster.
The syntax for testing a connection to a data source connection pool follows:
java -jar admin_client.jar uri adminId adminPassword -testDataSourceConnectionPool -connectionPoolName connectionPoolName -sqlStatement sqlStatement [-applicationName applicationName] [-user user] [-password password]
For example:
java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 -testDataSourceConnectionPool -sqlStatement "select * from dual" -applicationName default -connectionPoolName ScottConnectionPool
Table 11-17 -testDataSourceConnectionPool Command Subswitches
| Subswitch | Description |
|---|---|
|
|
Required. The name of the connection pool. |
|
|
Required. The SQL statement to use to test the connection |
|
|
Optional. The name of the application for which to test the data source connection pool. |
|
|
Optional. The default user name to use to get connections. |
|
|
Optional. The default password to use to get connections. |
Use the -removeDataSourceConnectionPool command to remove a data source connection pool from an application in an OC4J instance or in each OC4J instance of a group within a cluster. The syntax for removing a data source connection pool follows:
java -jar admin_client.jar uri adminId adminPassword -removeDataSourceConnectionPool -name name [-applicationName applicationName]
For example:
java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 -removeDataSourceConnectionPool -name ScottConnectionPool -applicationName default
You can use the admin_client.jar utility to add, test, and remove data sources in an OC4J instance or in a group of instances within a cluster, as the following topics describe:
Use the -addManagedDataSource command to add a managed data source for an application in an OC4J instance or in each OC4J instance of a group within a cluster. The syntax for adding a managed data source follows:
java -jar admin_client.jar uri adminId adminPassword -addManagedDataSource -applicationName applicationName -dataSourceName dataSourceName -jndiLocation jndiLocation -connectionPoolName connectionPoolName [-user user] [-password password] [-loginTimeout loginTimeout] [-txLevel txLevel] [-dbSchema dbSchema] [-manageLocalTransactions true|false]
For example:
java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 -addManagedDataSource -applicationName default -dataSourceName ScottDataSource -jndiLocation jdbc/ScottDataSource -connectionPoolName ScottConnectionPool
Table 11-19 -addManagedDataSource Command Subswitches
| Subswitch | Description |
|---|---|
|
|
Required. The name of the application for which to add the data source. |
|
|
Required. The name of the data source. |
|
|
Required. The location to use to bind the new data source into JNDI. |
|
|
Required. The name of the connection pool with which the data source interacts. |
|
|
Optional. The default user for the new data source. |
|
|
Optional. The default password for the new data source. |
|
|
Optional. The login timeout for the new data source. |
|
|
Optional. The transaction level ( |
|
|
Optional. The database schema to use if the EJB CMP implementation being used is Orion CMP. (TopLink CMP is the default.) |
|
|
Optional. Indicates whether or not OC4J should manage local transactions. The default value is |
Use the -removeManagedDataSource command to remove a managed data source from an application in an OC4J instance or in each OC4J instance of a group within a cluster. The syntax for removing a managed data source follows:
java -jar admin_client.jar uri adminId adminPassword -removeManagedDataSource -dataSourceName dataSourceName [-applicationName applicationName]
For example:
java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 -removeManagedDataSource -dataSourceName ScottDataSource -applicationName default
Use the -addNativeDataSource command to add a native data source for an application in an OC4J instance or in each OC4J instance of a group within a cluster. The syntax for adding a native data source follows:
java -jar admin_client.jar uri adminId adminPassword -addNativeDataSource -dataSourceName dataSourceName -user user -password password -jndiLocation jndiLocation -loginTimeout loginTimeout -dataSourceClass dataSourceClass -url url [-applicationName applicationName] [-properties name1 value1 [name2 value2 [...]]]
For example:
java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 -addNativeDataSource -dataSourceName ScottDataSource -user scott -password tiger -jndiLocation jdbc/ScottNativeDataSource -loginTimeout 5 -dataSourceClass com.acme.DataSourceImpl -url jdbc:oracle:thin:@localhost:1521:xe
Table 11-21 -addNativeDataSource Command Subswitches
| Subswitch | Description |
|---|---|
|
|
Required. The name of the new data source. |
|
|
Required. The default user for the new data source. |
|
|
Required. The default password for the new data source. |
|
|
Required. The location to use to bind the new data source into JNDI. |
|
|
Required. The login timeout for the new data source. |
|
|
Required. The fully qualified class of the new data source. |
|
|
Required. The url used by the new data source to connect to the database. |
|
|
Optional. The name of the application for which to add the data source. |
|
|
Optional. The property or properties for the new data source. |
Use the -removeNativeDataSource command to remove a native data source from an application in an OC4J instance or in each OC4J instance of a group within a cluster. The syntax for removing a native data source follows:
java -jar admin_client.jar uri adminId adminPassword -removeNativeDataSource -dataSourceClass dataSourceClass [-applicationName applicationName]
For example:
java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 -removeNativeDataSource -dataSourceName ScottDataSource
Use the -testDatabaseConnection command to test an application's connection to a database in an OC4J instance or in each OC4J instance of a group within a cluster.
The syntax for testing a database connection follows:
java -jar admin_client.jar uri adminId adminPassword -testDatabaseConnection -sqlStatement sqlStatement -factoryClass factoryClass -user user -password password -url url [-applicationName applicationName]
For example:
java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 -testDatabaseConnection -sqlStatement "select * from dual" -factoryClass oracle.jdbc.pool.OracleDataSource -user scott -password tiger -url jdbc:oracle:thin:@localhost:1521:xe -applicationName default
Table 11-23 -testDatabaseConnection Command Subswitches
| Subswitch | Description |
|---|---|
|
|
Required. The SQL statement to use to test the connection |
|
|
Required. The JDBC factory to test (instance of Driver, DataSource, ConnectionPoolDataSource, or XADataSource). |
|
|
Required. The user to use. |
|
|
Required. The password to use. |
|
|
Required. The URL to set on the JDBC factory. |
|
|
Optional. The name of the application. |
Use the -testDataSource command to test an application's connection to a data source in an OC4J instance or in each OC4J instance of a group within a cluster.
The syntax for testing a data source follows:
java -jar admin_client.jar uri adminId adminPassword -testDataSource -datasourceName datasourceName -sqlStatement sqlStatement [-applicationName applicationName] [-user user] [-password password]
For example:
java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 -testDataSource -datasourceName ScottDataSource -sqlStatement "select * from dual" -applicationName default -user scott -password tiger
Table 11-24 -testDataSource Command Subswitches
| Subswitch | Description |
|---|---|
|
|
Required. The data source to test. |
|
|
Required. The SQL statement to use to test the connection |
|
|
Optional. The name of the application. |
|
|
Optional. The user to use. |
|
|
Optional. The password to use. |
Use the -getDataSourcesDescriptor command to retrieve an application's data sources descriptor. The syntax for getting a data sources descriptor follows:
java -jar admin_client.jar uri adminId adminPassword -getDataSourcesDescriptor [-applicationName applicationName]
You can use the admin_client.jar utility to manage data JMS resources in an OC4J instance or in a group of instances within a cluster, as the following topics describe:
You can use the admin_client.jar utility to manage the OC4J JMS connection factories, as the following topics describe:
Use the -addJMSConnectionFactory command to add a JMS connection factory to an OC4J instance or to each instance of a group within a cluster. The syntax for this command follows:
java -jar admin_client.jar uri adminId adminPassword -addJMSConnectionFactory -domain domain -location location [-host host] [-port port] [-username username] [-password password] [-clientID clientID] [-isXA true|false]
For example:
java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 -addJMSConnectionFactory -domain Queue -location jms/ExampleQueueCF
Table 11-26 -addJMSConnectionFactory Command Subswitches
| Subswitch | Description |
|---|---|
|
|
Required. The JMS domain of this connection factory ( |
|
|
Required. The JNDI location to which this connection factory will be bound. |
|
|
Optional. The host name associated with this connection factory (defaults to the containing OC4J JMS server host). |
|
|
Optional. The port number associated with this connection factory (defaults to the containing OC4J JMS server port). |
|
|
Optional. The user name associated with this connection factory (defaults to |
|
|
Optional. The password associated with this connection factory (defaults to null). |
|
|
Optional. The JMS client ID associated with this connection factory (defaults to null). |
|
|
Optional. Whether or not this an XA connection factory (defaults to |
Use the -removeJMSConnectionFactory command to remove a JMS connection factory from an OC4J instance or instances. The syntax for this command follows:
java -jar admin_client.jar uri adminId adminPassword -removeJMSConnectionFactory -location location
For example:
java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 -removeJMSConnectionFactory -location jms/ExampleQueueCF
Use the -getJMSConnectionFactories command to return the attributes for each of the JMS connection factories in an OC4J instance or in a group of OC4J instances within a cluster. The syntax for this command follows:
java -jar admin_client.jar uri adminId adminPassword -getJMSConnectionFactories
For example:
java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 -getJMSConnectionFactories
You can use the admin_client.jar utility to manage the OC4J JMS destinations, as the following topics describe:
Use the -addDestination command to add a JMS destination. The syntax for this command follows:
java -jar admin_client.jar uri adminId adminPassword -addDestination -domain domain -name name -jndiLocation jndiLocation [-persistenceFile persistenceFile] [-description description]
For example:
java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 -addDestination -domain Queue -name ExampleQueue -jndiLocation jms/ExampleQueue
Table 11-28 -addDestination Command Subswitches
| Subswitch | Description |
|---|---|
|
|
Required. The JMS domain of this destination ( |
|
|
Required. The OC4J JMS provider-specific name of the destination. |
|
|
Required. The JNDI location to which this destination will be bound. |
|
|
Optional. The persistence file associated with this destination (defaults to null). |
|
-description |
Optional. A textual description of this destination (defaults to null). |
Use the -removeDestination command to remove a JMS destination from an OC4J instance or from each OC4J instance of a group within a cluster. The syntax for this command follows:
java -jar admin_client.jar uri adminId adminPassword -removeDestination -name name [-force true|false] [-removePFile true|false]
For example:
java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 -removeDestination -name ExampleQueue -removePFile true
Table 11-29 -removeDestination Command Subswitches
| Subswitch | Description |
|---|---|
|
|
Required. The OC4J JMS provider-specific name of the destination to remove. |
|
|
Optional. Removes the destination regardless of whether messages or consumers exist on it (defaults to |
|
-removePFile |
Optional. Remove the persistence file from the file system (defaults to |
Use the -getDestinations command to return the attributes for each of the OC4J JMS destinations in an OC4J instance or in a group of OC4J instances within a cluster. The syntax for this command follows:
java -jar admin_client.jar uri adminId adminPassword -getDestinations
For example:
java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 -getDestinations
You can use a remote client to manage OC4J after you install the files from the remote administration client, as "Downloading and Extracting the Remote Administration Client" describes. Then you can use admin_client.jar through the command-line tool or the JMX Remote API.
After you connect to an OC4J application server target, as explained in "Downloading and Extracting the Remote Administration Client", you can issue admin_client.jar commands from a remote client. Use the same syntax that you would use from within an OC4J instance.
JConsole is a JMX GUI console included in JDK 5.0. JConsole can connect to any JVM and hook into its running MBeanServer, displaying a series of pages on which various system details such as Thread and Memory usage of the JVM are displayed. JConsole can connect to a local JVM, or it can use the JMX Remote API and connect to a remote JVM.
The administration client distribution contains the required libraries to enable JConsole to connect to a remote OC4J or Oracle Application Server instance. To connect to the target instance, the JConsole utility (which is provided as a native executable on Windows platforms) needs to be configured with the relevant details of the administration client distribution.
To connect to an Oracle Application Server instance:
Add /j2ee/instance/admin_client.jar to the CLASSPATH environment variable:
set CLASSPATH=j2ee/home/admin_client.jar
Add the JConsole libraries to the CLASSPATH environment variable:
set CLASSPATH=%CLASSPATH%;%JAVA_HOME%\lib\jconsole.jar set CLASSPATH=%CLASSPATH%;%JAVA_HOME%\lib\tools.jar
Configure the JMX connector to use the OC4J ORMI protocol:
set PROPS= jmx.remote.protocol.provider.pkgs=oracle.oc4j.admin.jmx.remote
Run jconsole:
%JAVA_HOME%\bin\jconsole -J-Djava.class.path=%CLASSPATH% -J-D%PROPS%
This will launch JConsole.
On the Advanced Tab of the Connect to Agent screen, enter the connect string for the OC4J or Oracle Application Server target as well as the administration user name and password for the target.
The pattern of the JMX URL is different for OC4J targets from the pattern for Oracle Application Server targets. Table 11-30 shows examples of these URL patterns.
Table 11-30 JMX URLs for OC4J and Oracle Application Server Targets
| Target | JMX URL |
|---|---|
|
OC4J Standalone Server |
|
|
OC4J Instance on Oracle Application Server |
|
|
Oracle Application Server Cluster |
service:jmx:rmis:///opmn://stadp69:6003/cluster/as101/admin |
The JConsole utility will show the OC4J MBeans from the target instance. These MBeans can be used to view and manage the configuration of the OC4J instance.
On Windows, the environment used by JConsole can be modified by using a special System property form:
-J-Dname=value
A sample command script follows:
setlocal set URL=service:jmx:rmi:///opmn://test-cycle.oracle.com:6010/testunit set JAVA_HOME=C:\java\jdk150_07 set JCONSOLE_CPset JCONSOLE_CP=%JCONSOLE_CP%;%JAVA_HOME%\lib\jconsole.jar set JCONSOLE_CP=%JCONSOLE_CP%;%JAVA_HOME%\lib\tools.jar set ORACLE_HOME=D:\oc4j_admin_client set ORACLE_CP= set ORACLE_CP=%ORACLE_CP%;%ORACLE_HOME%\j2ee\home\admin_client.jar; set CLASSPATH=%JCONSOLE_CP%;%ORACLE_CP% set PROPS= set PROPS=%PROPS% -J-Djmx.remote.protocol.provider.pkgs=oracle.oc4j.admin.jmx.remote set PROPS=%PROPS% -J-Djava.class.path=%CLASSPATH% jconsole %PROPS% %URL% endlocal
The administration client distribution provides a full client environment for JMX client applications to connect to remote OC4J instances. You can use a JMX programmatic client to manage OC4J remotely through the JMX Remote API (JSR160), which can establish a connection to the MBeanServer. The only JAR files you need to run with JDK 5.0 are oc4jclient.jar and admin_client.jar, which the administration client distribution provides.
The following example uses these JAR files with the JMX API:
// A URL is of the form "service:jmx:rmi://127.0.0.1:23791"
JMXServiceURL serviceURL = new JMXServiceURL(_url);
Hashtable credentials = new Hashtable();
credentials.put("login", _username);
credentials.put("password", _password);
// Properties required to use the OC4J ORMI protocol
Hashtable env = new Hashtable();
env.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES,
"oracle.oc4j.admin.jmx.remote");
env.put(JMXConnector.CREDENTIALS, credentials);
JMXConnector jmxCon =
JMXConnectorFactory.newJMXConnector(serviceURL, env);
jmxCon.connect();
MBeanServerConnection mbeanServer =
jmxCon.getMBeanServerConnection();
In JDK 5.0 this code compiles with no Oracle libraries required, just the libraries provided by JDK 5.0:
clear @echo off @setlocal set J2EE_HOME=c:\java\oc4j-1013-prod\j2ee\home set JAVA_HOME=c:\java\jdk50 set CLASSPATH=. rem rem Uncomment below if using JDK14 rem set CLASSPATH=%CLASSPATH%;%J2EE_HOME%\lib\jmxri.jar rem set CLASSPATH=%CLASSPATH%;%J2EE_HOME%\lib\jmx_remote_api.jar rem set CLASSPATH=%CLASSPATH%;%J2EE_HOME%\lib\javax77.jar rem %JAVA_HOME%\bin\javac -classpath %CLASSPATH% -d . *.java @endlocal
To run the code with the oc4j_admin_client_101310.zip distribution:
Create a runnable JAR file.
Drop the JAR file into the j2ee/home directory of the administration client distribution.
Connect to a remote OC4J instance.
The code runs in JDK 5.0 with $ORACLE_HOME/j2ee/home/oc4jclient.jar and $ORACLE_HOME/j2ee/home/admin_client.jar:
@echo off @setlocal clear set J2EE_HOME=c:\java\oc4j-1013-prod\j2ee\home set JAVA_HOME=c:\java\jdk50 rem Runtime classpath set CLASSPATH=. set CLASSPATH=%CLASSPATH%;%J2EE_HOME%\oc4jclient.jar; set CLASSPATH=%CLASSPATH%;%J2EE_HOME%\admin_client.jar; rem rem Uncomment if using JDK14 rem set CLASSPATH=%CLASSPATH%;%J2EE_HOME%\lib\jmxri.jar rem set CLASSPATH=%CLASSPATH%;%J2EE_HOME%\lib\jmx_remote_api.jar rem set CLASSPATH=%CLASSPATH%;%J2EE_HOME%\lib\javax77.jar @endlocal
The connection URL in the main method of the example is set to connect to a local OC4J instance. If you want to connect to an Oracle Application Server through an ORMI port, use a Service URL of the following form:
service:jmx:rmi|ormi:///opmn://stadp57.us.oracle.com:6003/home
A service URL will obtain the ORMI port from the OPMN daemon. The ORMI port is assigned at runtime. Using the OPMN connection string path will connect you to the specified OC4J instance.
For more information about how to use a JMX client to manage OC4J instances remotely, see "Remote Management Using the JMX Remote API (JSR-160)" in the Oracle Containers for J2EE Developer's Guide.
