Skip Headers
Oracle® Containers for J2EE Deployment Guide
10g (10.1.3.5.0)

Part Number E13980-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

9 Using Application Server Control for Deployment

Oracle Enterprise Manager 10g Application Server Control provides a Web-based interface for completing a range of deployment-related tasks on a specific OC4J instance or simultaneously on all OC4J instances in a group. 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.

You can perform these deployment operations with Application Server Control:

See the online help provided with Application Server Control for detailed instructions on using the various features provided.

You can perform similar deployment tasks with Ant tasks or the admin_client.jar command-line utility. Chapter 10, "Using OC4J Ant Tasks for Deployment" describes the OC4J Ant tasks for deployment and how to use them. Chapter 11, "Using the admin_client.jar Utility for Deployment" explains how to use admin_client.jar for deployment tasks.

This chapter includes the following sections:

Accessing Application Server Control

Application Server Control is installed and configured automatically when you install OC4J. This section covers the following topics:

For more information about using this interface, see the online help provided with Application Server Control.

Accessing Application Server Control in Standalone OC4J

Application Server Control is installed and configured automatically when you install the OC4J software. It is started by default when OC4J is started.

You can access Application Server Control through the default Web site, which is configured to listen for HTTP requests on port 8888. To access Application Server Control, type the following URL in a Web browser:

http://hostname:8888/em

Accessing Application Server Control in Oracle Application Server

Application Server Control is installed and configured automatically when you install OC4J using the Oracle Universal Installer.

You can use the OPMN command-line tool to start Application Server Control with all other installed Oracle Application Server components. The OPMN command-line tool, opmnctl, is installed in the ORACLE_HOME/opmn/bin directory on each server node. Start all installed components by issuing the following command:

cd ORACLE_HOME/opmn/bin
opmnctl startall

Note:

In a cluster topology that includes multiple OC4J instances, use the -sequential flag after startall to prevent resource contention that might occur if you started all instances in parallel. You can specify the -sequential option in the OPMN configuration file for the cluster topology, opmn.xml, as follows:
<ias-component id="default_group">
  <process-type id="home" module-id="OC4J" status="enabled">
    <module-data>
      <category id="start-parameters">
        <data id="oc4j-options" value="-sequential"
      </category>
      ...
    </module-data>
  </process-type>
</ias-component>

In a typical Oracle Application Server installation, all Web applications, including Application Server Control, are accessed through Oracle HTTP Server (OHS). Use the following URL to access Application Server Control:

http://ohs_host_address:port/em
  • ohs_host_address is the address of the OHS host machine; for example, server07.company.com

  • port is an HTTP listener port assigned to OHS by OPMN. Run the following opmnctl command on the OHS host machine to get the list of assigned listener ports from OPMN:

    opmnctl status -l
    

    Supply the port designated as http1 in the OPMN status output as the value for port:

    HTTP_Server | HTTP_Server | 6412 | Alive | 1970872013 | 1
    6396 | 0:48:01 | https1:4443,http2:722,http1:7779
    

Setting Log Levels

In OC4J 10g (10.1.3.5.0), you can set the log levels for loggers through Application Server Control, as follows:

  1. On the OC4J Home page, click Administration.

  2. From the administration tasks, select Logger Configuration to display the Logger Configuration page.

  3. Click Expand All to view the entire list of loggers currently loaded for the OC4J instance.

  4. Select a log level for any of the loggers shown on the page.

Deploying an Application to an OC4J Instance or Group of Instances

Application Server Control enables you to deploy an application to a specific OC4J instance or to a group of OC4J instances, as follows:

  1. Click Cluster Topology on the Application Server Control home page. The resulting page displays the following items:

    • All Oracle Application Server instances that are currently part of the cluster topology

    • The active OC4J instances within each Oracle Application Server instance

    • The applications deployed into each OC4J instance

  2. Select the deployment target:

    • To deploy to a specific OC4J instance, click the link for the target instance to which you want to deploy the application.

    • To deploy to a group of OC4J instances, click the name of the group under Groups at the bottom of the page.

  3. After the target instance or instances have been accessed, deploy the application, as the following topics explain:

Deploying or Redeploying an Application

Application Server Control includes a three-page deployment wizard that provides a streamlined, user-friendly deployment process.

Note:

If the HTTP session times out due to browser inactivity while you are using the deployment wizard, you will have to restart the deployment process from the beginning.
  1. Click the Applications tab for an OC4J instance and then the Deploy button to access the deployment wizard.

  2. Select the archive to upload to the OC4J server in the first page of the wizard.

    You also have the option to navigate to the location of an existing deployment plan, which can be applied to the archive or used as a template for a new deployment plan. If no deployment plan is specified, a new deployment plan will be created by default. See Chapter 8, "Working with Deployment Plans" for more information.

  3. Set application attributes and bind the Web application to a Web site in the second page of the deployment wizard.

    Specify the application or module name, which will be used to identify the application within OC4J. This name will also be displayed in Application Server Control.

    Next, select the parent application of the application or module being deployed. If no parent application is specified, the default application is used.

    Finally, if deploying a Web application, bind the application to the Web site that will be used to access it. This binding is accomplished by selecting the name of the XML configuration file that defines the Web site from the list.

    The list contains all Web sites currently defined for the OC4J server instance. In most cases, applications will be bound to the default Web site, which is defined by the default-web-site.xml configuration file.

  4. Complete the deployment tasks, edit the deployment plan directly, or do both before deploying the archive in the third page of the deployment wizard.

    In this final screen, you have the option of completing a number of configuration tasks before deploying the application. These tasks provide an alternative to editing the deployment plan, which contains configuration data that will be set in the OC4J deployment descriptors generated during deployment. See "Completing Configuration Tasks Before Deployment" for details on each optional task.

    You also have the option of editing the deployment plan directly before deploying the archive. The edited deployment plan can then be saved for reuse. See Chapter 8, "Working with Deployment Plans" for more details on creating and editing deployment plans.

  5. Deploy the application.

    The archive is not actually deployed until you click the Deploy button. The deployment plan, which up until this point exists only on the client side, will also be sent to the OC4J server with the archive. Once started, the deployment process will continue, even if the Web browser is closed.

Redeploying an Application with Scheduled Jobs

If you redeploy an application that has scheduled jobs, the jobs will not run as scheduled unless you remove all the jobs before the redeployment and resubmit them after it.

To redeploy an application with scheduled jobs:

  1. Remove all scheduled jobs.

  2. Redeploy the application.

  3. Resubmit all the jobs.

Completing Configuration Tasks Before Deployment

The third page of the Application Server Control deployment wizard gives you the option to complete a number of configuration tasks before deploying an application. You can complete similar tasks through the deployment plan editor, as "Creating or Editing Deployment Plans with Oracle JDeveloper" describes.

Just as with the deployment plan editor, values set through the various deployment tasks pages are written to the appropriate OC4J-specific deployment descriptor at deployment time. The following topics describe the configuration tasks for deployment:

Selecting the Security Provider

OC4J supports two different provider types: XML for application development mode, and LDAP for production environments. Each provider type implements a repository for secure, centralized storage, retrieval, and administration of provider data.

  • Select File-Based Security Provider to use the XML-based provider.

    The XML-based provider is a lightweight implementation suitable for application prototyping in a development environment. User, realm, and policy information is stored in an XML file, normally system-jazn-data.xml.

  • Select Oracle Identity Management Security Provider to use the LDAP-based Oracle Internet Directory provider.

    This security provider is useful for applications being deployed into a production environment. User, realm, and policy information is persisted to the LDAP-based Oracle Internet Directory (OID).

    Note that the OC4J instance must be configured to use Oracle Internet Directory before an application can be configured to use it.

  • Select Oracle Security Provider for 3rd Party LDAP Server to use a non-Oracle LDAP provider.

    Select this option to configure the application to use Active Directory, Sun Directory Server or another LDAP server. Use the tools provided by the LDAP server vendor for realm and principals management.

Mapping Security Roles to Users and User Groups

Map any security roles defined in your application to existing users and user groups. If you have defined a security role within your application, you can map this role to a security group or role. You do not define security groups and users in this screen.

Configuring Enterprise JavaBeans Modules Included in the Application

You can configure a number of properties for the Enterprise JavaBeans (EJB) modules packaged with the application being deployed:

  • Configure the following properties for each entity bean packaged with the application. The values displayed are the default values.

    Table 9-1 Entity Bean Properties

    Property Values

    Persistence Type

    Indicates whether the bean will use bean-managed or container-managed persistence.

    Min Instances

    Sets the number of minimum bean implementation instances to be kept instantiated or pooled.

    Max Instances

    Defines the maximum number of bean instances, either instantiated or pooled, allowed in memory.

    Max Transaction Retries

    Specifies the number of times to retry a transaction that was rolled back due to system-level failures.

    Pool Cache Timeout

    Sets the amount of time, in seconds, that stateless sessions are to remain cached in the pool. At the specified interval, all unassigned beans in the pool are removed.

    JNDI Name

    Defines the JNDI name to which this EJB module will be bound.


  • Select the data sources to associate with EJB modules containing entity beans.

    By default, all entity beans deployed to OC4J will use the Oracle TopLink persistence manager. You can create data sources can be created through the JDBC Resources page of Application Server Control. To get to this page, select JDBC Resources under Services on the Administration tab of the OC4J Home page.

  • Configure the following properties for each session bean packaged with the application. The values displayed are the default values.

    Table 9-2 Session Bean Properties

    Property Values

    Min Instances

    Sets the number of minimum bean implementation instances to be kept instantiated or pooled.

    Max Instances

    Defines the maximum number of bean instances, either instantiated or pooled, allowed in memory.

    Max Transaction Retries

    Specifies the number of times to retry a transaction that was rolled back due to system-level failures.

    Call Timeout

    Specifies the maximum time, in milliseconds, to wait for any resource to make a business/life-cycle method invocation.

    Pool Cache Timeout

    Sets the amount of time, in seconds, that stateless sessions are to remain cached in the pool. At the specified interval, all unassigned beans in the pool are removed.

    JNDI Name

    Defines the JNDI name to which the EJB module will be bound.


  • Configure the following for each message-driven bean packaged with the application. The values displayed are the default values.

    Table 9-3 Message-Driven Bean Properties

    Property Values

    Dequeue Retry Count

    Specifies how often the listener thread tries to re-acquire the JMS session once database failover has occurred. Valid for container-managed transactions only.

    Dequeue Retry Interval

    Specifies the interval between attempts to re-acquire the JMS session.

    Transaction Timeout

    Sets the transaction timeout interval, in seconds, for any container-managed transactional MDB.

    Number of Listener Threads

    Sets the number of listener threads spawned to listen for incoming JMS messages on the topic or queue. Topics can only have one thread; queues can have more than one thread.


For information about deploying EJB modules, see Chapter 3, "Deploying Enterprise JavaBeans Modules." For information about updating EJB modules in a deployed application, see "Incremental Redeployment of Updated EJB Modules".

Managing Class Loading to Import Shared Libraries

You can manage the libraries imported by the application. By default, an application inherits the same set of shared libraries present in its parent application, including any shared libraries inherited from the default application.

The default page displays all of the shared libraries currently installed on the OC4J server instance. Shared libraries must have already been installed on the OC4J server instance to be imported.

  • Select the Import box next to each shared library to import. To use the latest installed version of the library, do not specify a version number.

  • Specify a minimum or maximum version of a shared library to import.

    Use this feature to import a different version of a shared library than that inherited from the application's parent. For example, you could import an earlier version of the Oracle JDBC driver than that inherited from the OC4J default application by specifying the maximum version to import.

  • Deselect the Import box for any shared library that should not be inherited from the parent application.

    To remove all inherited shared libraries, deselect the Inherit parent application's imported shared libraries checkbox. This action adds the following <remove-inherited> element to the orion-application.xml file that will be generated for the application at deployment time:

    <imported-shared-libraries>
      <remove-inherited name="*" />
    </imported-shared-libraries>
    
  • Optionally specify additional code sources to add as library paths to the OC4J instance.

    To add a code source, specify either a relative or absolute path or URL to the archive. Specified directories are scanned for archives to load at OC4J server startup.

  • Manage the class loader created for each Web module.

    OC4J creates a class-loader instance for each Web module deployed as a WAR into the server instance.

    Check the Search Local Classes First checkbox to force the class loader to also load JARs containing classes and resources packaged within the WAR before loading JARs external to the WAR.

    For example, suppose you want to ensure that your Web module uses the version of log4j packaged within your WAR, and not use the version of log4j bundled with a resource adapter deployed into the OC4J instance. Selecting this option forces the class loader to load the local log4j JAR file contained within the WAR.

    If the WAR contains a MANIFEST.MF, you can force JARs declared as named extensions to be loaded by checking the Include WAR Manifest Class Path box. You can also specify the relative or absolute paths to one or more additional code sources containing classes or resources to be loaded in the Classpath field. Using either of these features causes classes to be loaded by the Web module's class loader, just as if they were packaged within the WAR.

Configuring Application Clustering

The OC4J clustering framework supports replication of objects and values contained in an HTTP session or an instance of a stateful session EJB module across OC4J instances.

By default, applications inherit the clustering configuration set at the parent application level. However, clustering can also be configured at the application level at deployment time. A configuration property set at the application level overrides the corresponding value inherited from the parent application.

  • Select Enable Clustering to enable clustering support for the application. The value selected overrides the setting inherited from the application's parent.

    If clustering has been enabled at the parent application level, the parent's configuration will be applied by default.

  • Select Peer-to-Peer Replication to enable the peer-to-peer replication mechanism. The mechanism used is dependent on the type of OC4J installation:

    • OC4J instances within Oracle Application Server

      In a cluster topology, dynamic peer-to-peer discovery is used to enable OC4J instances to dynamically discover and communicate with one another.

      Dynamic peer-to-peer discovery is used by default if clustering is enabled; no additional configuration is needed.

      You can specify the IP address for a Network Interface Card (NIC) to bind to. This is useful if you have OC4J host machines with multiple network cards, each with a specific IP address.

    • Standalone OC4J installation

      In a standalone configuration, each JVM in the OC4j instance can be statically configured to recognize at least one other peer JVM. As a JVM becomes aware of each of its peers, it also becomes aware of each peer's peer or peers, with the end result that all of the JVMs in the OC4J instance become aware of one another.

  • Select Multicast Replication to configure OC4J to send and receive HTTP session and stateful session bean state changes via multicast packages.

    This is the default replication protocol used in a standalone OC4J installation. The multicast address and port must be the same for all instances in the cluster. The OC4J default address is 230.230.0.1; the default port is 45566.

    Note that you can optionally specify the IP address for a Network Interface Card (NIC) to bind to. This is useful if you have OC4J host machines with multiple network cards, each with a specific IP address

  • Select Database Replication to replicate application state to a database.

    Select the JNDI name of the data source providing the connection to the database from the Database JNDI Location pull-down menu. See the Oracle Containers for J2EE Services Guide for details on defining and using data sources.

Providing Resource Mappings

Any resources included in the EAR file being deployed will be displayed in Application Server Control. Map any environment references in your application to physical entities currently present in the operational environment, including JMS topics and queues, data sources, and resource adapters.

Map any references to resources in your application, such as data sources or mail queues, to physical entities currently present in the OC4J container. Note that if you need a specific resource, you must have already added this to the OC4J container before you deploy your application in order for you to match them in this step.

For most applications, the resource reference you must designate is the data source JNDI name. You cannot configure the data source information through deployment tasks in Application Server Control, which enable you to designate an already configured data source or a data source that you can configure later. Designate the JNDI location name of the data source that the application will use.

If you have any MDBs in your EAR file, you may be required to add information about the subscriptions or topics. If you are defining DataSource objects for CMP entity beans, you are given the option to add a JNDI location for those DataSource objects.

Deploying a New Application Version with Side-by-Side Application Upgrade

Side-by-side application upgrade enables hot deployment of a new version of an application while one or more active instances of an earlier version of the application complete gracefully. This feature includes version management capabilities, such as changing the default version of an application, deploying and undeploying different versions, and retiring a version.

With side-by-side application upgrade, you can have one version of a J2EE application running and then deploy a second version of the application without having your end users experience any down time. You can test the new version of the application when it gets deployed to the production environment, before exposing the new version to end users. This testing ensures that the application is configured correctly for the production environment.

The minimum architecture for a side-by-side application upgrade to work is two independent OC4J instances managed by OPMN and an OHS instance within an Oracle Application Server instance. Each OC4J instance must have an internal HTTP Web site through which requests can go directly to OC4J as well as an AJP Web site through which OHS can route requests to OC4J. Both OC4J instances must be running the application. Figure 9-1 shows the initial state of the two OC4J instances before deployment of a new application version with side-by-side application upgrade.

Figure 9-1 Two OC4J Instances Set Up for Side-by-Side Application Upgrade

Description of Figure 9-1 follows
Description of "Figure 9-1 Two OC4J Instances Set Up for Side-by-Side Application Upgrade"

The OC4J instances do not have to be members of the same group. If they are, you can do the initial deployment and configuration of the application with group operations. The deployment tasks for a side-by-side application upgrade, however, must be done to one OC4J instance at a time, whether or not it is a member of a group.

In the side-by-side application upgrade procedure, the second OC4J instance continues running version 1 of the application and preserves session state while you stop the application on the first instance, which forces all new traffic on the production Web site (AJP) to the second instance. Then you can deploy version 2 of the application to the first instance and bind version 2 to the HTTP Web site for testing. When the testing succeeds, you can bind version 2 to the AJP Web site to make it publicly accessible. After the production system stabilizes, you can stop version 1 on the second OC4J instance and deploy and test version 2 there.

For this procedure to work, you need to make sure that the requests being served by both application versions are compatible so that version 1 and version 2 can coexist with requests being routed to them. If you use state replication to maintain state across version 1 and version 2, you need to make sure that the state being maintained is compatible between the application versions.

This section shows how to use side-by-side application upgrade to deploy an application mainly with Application Server Control. You can also perform the deployment tasks with Ant tasks, described in Chapter 10, Using OC4J Ant Tasks for Deployment," or with admin_client.jar commands, described in Chapter 11, "Using the admin_client.jar Utility for Deployment."

How to Create an Additional HTTP Listener in an OC4J Instance

An OC4J instance has an AJP listener by default. You can create an additional HTTP listener in an OC4J instance so that it has an internal Web site that uses the http protocol as well as the default, public Web site that uses the ajp protocol. Then you can bind an application the HTTP Web site for testing before you make the application available to end users on the AJP Web site.

To create an additional HTTP listener in an OC4J instance:

  1. Edit the ORACLE_HOME/j2ee/instance/config/server.xml file to add a <web-site> element like this one:

    <web-site default="false" path="./internal-web-site.xml" />
    
  2. Create a new *-web-site.xml file and specify a different port number from the port for the AJP Web site.

    Example 9-1 shows the contents of a file named c:\OracleAS\j2ee\blue1\config\internal-web-site.xml.

    Example 9-1 *-web-site.xml file to Add an HTTP Listener

    <?xml version="1.0"?>
    <web-site xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema /web-site-10_0.xsd" 
    port="9999" protocol="http" display-name="Internal HTTP Site" 
    schema-major-version="10" schema-minor-version="0" >
    <default-web-app application="default" name="defaultWebApp" root="/j2ee" /> 
    <access-log path="../log/internal-web-access.log" split="day" /> 
    </web-site> 
    
  3. Edit the opmn.xml file to add the new port entry for the OC4J instance:

    <start timeout="600" retry="2"/>
    <stop timeout="120"/>
    <restart timeout="720" retry="2"/>
    <port id="default-web-site" range="7700" protocol="ajp"/>
    <port id="internal-web-site" range="9999" protocol="http"/>
    <port id="rmi" range="12401-12500"/>
                   <port id="rmis" range="12701-12800"/>
                   <port id="jms" range="12601-12700"/>
                   <process-set id="default_group" numprocs="1"/>
    
  4. Reload the opmn.xml file.

  5. Restart the OC4J instance.

    You now have your external listener coming through OHS (AJP), and you have an internal listener going directly to the OC4J instance. You can see the HTTP port in the output from the opmnctl status -l command:

    Processes in Instance: ohs_j2ee_changed
    ---------------------------------+--------------------+---------+----------+------------+----------+-----------+------
    ias-component                    | process-type       |     pid | status   |    uid |  memused |    uptime | ports
    ---------------------------------+--------------------+---------+----------+------------+----------+-----------+------
    OC4JGroup:default_group          | OC4J:foo           |    4856 | Alive    |  768545086 |   194428 |   0:05:56 | jms:12601,ajp:12501,http:9999,rmis:12701,aussie-tripper:3762,rmi:12401
    
  6. Go to the new HTTP listener and verify that it is valid and accepting requests.

You can also use Application Server Control to control the port and protocol of the Web site, on the Runtime Ports page, as Figure 9-2 shows.

Figure 9-2 Ports and Protocols for OC4J Web Sites

Description of Figure 9-2 follows
Description of "Figure 9-2 Ports and Protocols for OC4J Web Sites"

For more information about creating and configuring Web sites, see "Managing Web Sites in OC4J" in Oracle Containers for J2EE Configuration and Administration Guide.

How to Deploy an Application with Side-by-Side Application Upgrade

With side-by-side application upgrade, you can deploy a new version of an application while still servicing the old version, on two OC4J instances within a single Oracle Application Server 10g Release 3 (10.1.3.5.0) instance. The Oracle Application Server instance also includes Oracle HTTP Server (OHS), based on Apache. This setup enables you to perform an in-place upgrade of an application.

To deploy an application with side-by-side application upgrade:

  1. Set up two OC4J instances front-ended by OHS to have both AJP and HTTP listeners, as in Figure 9-1.

    The AJP listener will handle normal user traffic, routed from OHS. You can use the HTTP listener for internal testing. Application instances will be bound to the AJP listener when running in their normal state.

    For information about adding HTTP listeners, see "How to Create an Additional HTTP Listener in an OC4J Instance".

  2. With the same version of the application running in both OC4J instances, ensure that requests are being served correctly.

  3. Stop the application on the first OC4J instance:

    1. From the Cluster Topology page of Application Server Control, click the name of the first OC4J instance.

    2. On the OC4J page, click Applications.

    3. Click the application name.

    4. On the Application page, click Stop.

    Stopping an application begins to quiesce in-process requests as they complete and prevents any new traffic from being sent to the application instance, as Figure 9-3 shows.

    Figure 9-3 Application Quiesced on First OC4J Instance

    Description of Figure 9-3 follows
    Description of "Figure 9-3 Application Quiesced on First OC4J Instance"

  4. Wait two minutes for all in-process requests to be quiesced off of the application on the first OC4J instance.

    After a short time, all the in-process requests will be gone, normally well within two minutes. You can make this wait more or less for your application.

  5. Undeploy the application from the first OC4J instance:

    1. From the Cluster Topology page of Application Server Control, click the name of the first OC4J instance.

    2. On the OC4J page, click Applications.

    3. Click the application name.

    4. On the Application page, click Undeploy.

    5. Click Return.

    The application is now undeployed from the first OC4J instance, as Figure 9-4 shows.

    Figure 9-4 Application Undeployed from First OC4J Instance

    Description of Figure 9-4 follows
    Description of "Figure 9-4 Application Undeployed from First OC4J Instance"

    Note:

    Redeploy is also a valid option for a side-by-side application upgrade, instead of Undeploy and Deploy, provided the HTTP Web site is selected for the redeployment. Redeploying the application enables you to maintain its existing settings. Undeploying the application and then deploying the new version removes the application, including its configuration, and then deploys it anew.
  6. Deploy the new version of the application to the first OC4J instance, binding the application to the HTTP Web site to prevent OHS from routing any traffic to the new version:

    1. On the Applications tab of the OC4J page for the first OC4J instance, click Deploy.

    2. Specify your EAR file location and click Next.

    3. Specify your application name.

    4. Select the HTTP Web site from the drop-down menu.

    5. Click Next.

    6. Click Deploy.

    7. Click Return.

    The new version of the application is now deployed to the first OC4J instance and exposed to the internal Web site. Figure 9-5 shows the state of the OC4J instances running two different versions of the application.

    Figure 9-5 New Application Version Deployed to Internal Web Site on First OC4J Instance

    Description of Figure 9-5 follows
    Description of "Figure 9-5 New Application Version Deployed to Internal Web Site on First OC4J Instance"

  7. Test the new version of the application on the first OC4J instance, through the HTTP listener, which enables you to get to the application internally.

    Make sure the application is behaving as you would expect it to:

    • The new version of the application is available from the internal Web site:

      http://host_name:port_number/application_name
      
    • The old version of the application is available from the external Web site:

      https://host_name:port_number/application_name
      
  8. Bind the new version of the application to the AJP listener to enable the OHS server to route requests to it:

    1. Change your current directory to the home directory for the first OC4J instance; for example:

      CD c:\OracleAS\j2ee\blue1
      
    2. Issue an admin_client.jar -bindWebApp command like the following one:

      java -jar admin_client.jar deployer:oc4j:opmn://hostname/blue1 oc4jadmin 
      password -bindWebApp -appName testApp -webModuleName testAppWeb 
      -webSiteName default-web-site 
      

    Figure 9-6 shows the new and old versions of the application running side by side, each on the production Web site in its OC4J instance.

    Figure 9-6 New and Old Application Versions Running Side by Side on Production Web Sites

    Description of Figure 9-6 follows
    Description of "Figure 9-6 New and Old Application Versions Running Side by Side on Production Web Sites"

  9. Repeat steps 3 through 8 to deploy and test the new version of the application on the second OC4J instance.

    Figure 9-7 shows the old version of the application quiesced on the second OC4J instance.

    Figure 9-7 Application Quiesced on Second OC4J Instance

    Description of Figure 9-7 follows
    Description of "Figure 9-7 Application Quiesced on Second OC4J Instance"

    Figure 9-8 shows that the new version keeps running on the production Web site on the first OC4J instance while the old version of the application is undeployed from the second OC4J instance.

    Figure 9-8 Old Application Version Undeployed from Second OC4J Instance

    Description of Figure 9-8 follows
    Description of "Figure 9-8 Old Application Version Undeployed from Second OC4J Instance"

    Figure 9-9 shows the new version of the application deployed to the HTTP Web site of the second OC4J instance for testing.

    Figure 9-9 New Application Bound to Internal Web Site on Second OC4J Instance for Testing

    Description of Figure 9-9 follows
    Description of "Figure 9-9 New Application Bound to Internal Web Site on Second OC4J Instance for Testing"

  10. After you bind the new version of the application to the AJP listener on the second OC4J instance, verify that the new version is running on the production Web site on both OC4J instances.

    Figure 9-10 shows the state of the OC4J instances after deployment of an application with side-by-side application upgrade.

    Figure 9-10 OC4J Instances Running New Application Version After Side-by-Side Application Upgrade

    Description of Figure 9-10 follows
    Description of "Figure 9-10 OC4J Instances Running New Application Version After Side-by-Side Application Upgrade"

Undeploying an Application

Undeploying an application or module removes the code from the OC4J runtime and deletes all existing Web site bindings.

  1. Click the Applications tab ->Undeploy button.

  2. Select the application, then click the Undeploy button.

Creating and Managing Shared Libraries

You can create new shared libraries, add or remove archives from a shared library, and import other shared libraries into an existing shared library through Application Server Control.

To manage the shared libraries available in the OC4J instance:

  1. Navigate to the OC4J Home page for the OC4J instance.

  2. Click Administration to display the OC4J Administration page, which contains a table listing the various administration tasks you can perform for this OC4J instance.

  3. If necessary, expand the Properties section of the table by clicking the expand icon or by clicking Expand All.

  4. Click the task icon in the Shared Libraries row of the table.

    Application Server Control displays the Shared Libraries page, which lists the shared libraries currently available in the OC4J instance. You can also add and remove shared libraries from the OC4J instance.

  5. Click Help for information about the options on the page.

For more information about creating and managing shared libraries through Application Server Control, see the online help topics.

Starting, Restarting, and Stopping Applications

To start, restart, or stop an application that has been deployed to the OC4J instance:

  1. Navigate to the OC4J Home page for the OC4J instance.

  2. Click Applications.

  3. Select the application.

  4. Click the Start, Restart, or Stop button.

Note:

You can also start, stop, or restart an application from the Application Home page.

The following restrictions apply to starting, stopping, or restarting deployed applications:

Restarting and Stopping OC4J Instances

With Application Server Control, you can restart or stop an OC4J instance or group of OC4J instances in an Oracle Application Server environment.

To restart or stop an OC4J instance with Application Server Control:

  1. Navigate to the OC4J Home page.

  2. To restart an OC4J instance that is in a stopped state, click the Restart button.

  3. To stop an OC4J instance, click the Stop button.

You can also restart or stop an OC4J instance from the Cluster Topology page by selecting the instance in the Members section and clicking the Restart or Stop button.

To restart or stop a group of OC4J instances with Application Server Control:

  1. In the Groups section of the Cluster Topology page, select the group.

  2. To restart a group of OC4J instances that are in a stopped state, click the Start button.

  3. To stop a group of OC4J instances, click the Stop button.

Managing Data Sources and Connection Pools for OC4J Instances

With Application Server Control, you can view, create, and delete data sources and connection pools (JDBC resources) for an OC4J instance or group of OC4J instances in an Oracle Application Server environment.

To manage data sources and connection pools for an OC4J instance with Application Server Control:

  1. Navigate to the OC4J Home page for the OC4J instance.

  2. Click Administration to display the OC4J Administration page, which contains a table listing the various administration tasks you can perform for the OC4J instance.

  3. If necessary, expand the Services section of the table by clicking the expand icon or by clicking Expand All.

  4. Click the task icon in the JDBC Resources row of the table.

    Application Server Control displays the JDBC Resources page, which lists the data sources and connection pools currently available in the OC4J instance.

  5. Use the drop-down menu to view the data sources and connection pools specific to a particular deployed application.

  6. Click Help for more information about viewing, creating, and deleting data sources and connection pools.

To manage data sources and connection pools for a group of OC4J instances with Application Server Control:

  1. Navigate to the Cluster Topology page.

  2. Scroll to the Groups section of the page and click the name of the group you want configure.

  3. Click Administration to display the Group Administration page, which contains a table listing the various administration tasks you can perform for the group.

  4. If necessary, expand the Services section of the table by clicking the expand icon or by clicking Expand All.

  5. Click the task icon in the JDBC Resources row of the table.

    Application Server Control displays the JDBC Resources page, which lists the data sources and connection pools currently available for the OC4J instances in the group. Use the drop-down menu to view the data sources and connection pools specific to a particular deployed application.

  6. Click Help for more information about viewing, creating, and deleting data sources and connection pools.

Managing JMS Resources

To manage JMS destinations through Application Server Control:

  1. Navigate to the OC4J Home page for the OC4J instance.

  2. Click Administration to display the OC4J Administration page, which contains a table listing the various administration tasks you can perform for this OC4J instance.

  3. If necessary, expand the Services section of the table by clicking the expand icon or by clicking Expand All.

  4. Click the task icon in the JMS Destinations row of the table.

    Application Server Control displays the JMS Destinations page, which lists the JMS Destinations available for the OC4J instance. You can then create additional JMS destinations or delete existing JMS destinations.

For more information about managing JMS resources with Application Server Control, see the online help topics.