| 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 |
The Oracle Enterprise Manager 10g Application Server Control Console 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. 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.
You can perform these deployment operations through the Application Server Control Console:
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
Create, modify, or remove shared libraries
Start, restart, or stop applications
Restart or stop an OC4J instance or group of instances
Manage data sources and connection pools
Manage JMS resources
Create or edit a reusable deployment plan
Set application-specific security and application-clustering configurations
See the online help provided with Application Server Control Console 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:
The Application Server Control Console is installed and configured automatically when you install OC4J. This section covers the following topics:
Accessing Application Server Control Console in Standalone OC4J
Accessing Application Server Control Console in Oracle Application Server
See the online Help provided with Application Server Control Console for detailed instructions on using this interface.
The Application Server Control Console is installed and configured automatically when you install the OC4J software. It is started by default when OC4J is started.
The console is accessed through the default Web site, which is configured to listen for HTTP requests on port 8888. To access the console, simply type the following URL in a Web browser:
http://hostname:8888/em
The Application Server Control Console is installed and configured automatically when you install OC4J using the Oracle Universal Installer.
The console is started with all other installed Oracle Application Server components using the OPMN command-line tool, opmnctl, which 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 Console, are accessed through Oracle HTTP Server (OHS). Use the following URL to access the console:
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
In OC4J (10.1.3.1.0), you can set the log levels for loggers through the Application Server Control Console, as follows:
On the OC4J Home page, click Administration.
From the administration tasks, select Logger Configuration to display the Logger Configuration page.
Click Expand All to view the entire list of loggers currently loaded for the OC4J instance.
Select a log level for any of the loggers shown on the page.
Application Server Control Console enables you to deploy an application to a specific OC4J instance or to a group of instances within a cluster topology, as follows:
Click Cluster Topology on the Application Server Control Console 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
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.
After the target instance or instances have been accessed, deploy the application, as the following topics explain:
The Application Server Control Console has 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. |
Click the Applications tab for an OC4J instance and then the Deploy button to access the deployment wizard.
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.
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 Console.
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.
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.
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.
The third panel in the Application Server Control Console 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:
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.
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.
You can configure a number of properties for the EJBs 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 this EJB will be bound to. |
Select the data sources to associate with EJB modules containing entity beans.
By default, all entity beans deployed into OC4J will use the Oracle TopLink persistence manager. Data sources can be created through the Administration tab -> Services ->JDBC Resources page in Application Server Control Console.
Configure the following 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 this EJB will be bound to. |
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 EJBs, see Chapter 3, "Deploying Enterprise JavaBeans". For information about updating EJBs in a deployed application, see Chapter 3, "Incremental Redeployment of Updated EJB Modules".
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.
The OC4J clustering framework supports replication of objects and values contained in an HTTP session or a stateful session Enterprise JavaBean instance 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.
Any resources included in the EAR file being deployed will be displayed in the Application Server Control Console. 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; it only designates an already configured data source or a data source that you will be configuring later. Designate the JNDI location name of the data source that the application will be using.
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.
Undeploying an application or module removes the code from the OC4J runtime and deletes all existing Web site bindings.
Click the Applications tab ->Undeploy button.
Select the application, then click the Undeploy button.
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 the Application Server Control Console.
To manage the shared libraries available in the OC4J instance
Navigate to the OC4J Home page for the OC4J instance.
Click Administration to display the OC4J Administration page, which contains a table listing the various administration tasks you can perform for this OC4J instance.
If necessary, expand the Properties section of the table by clicking the expand icon or by clicking Expand All.
Click the task icon in the Shared Libraries row off the table.
The Application Server Control Console 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.
Click Help for information about the options on the page.
For more information about creating and managing shared libraries through the Application Server Control Console, see the online help topics.
To start, restart, or stop an application that has been deployed to the OC4J instance:
Navigate to the OC4J Home page for the OC4J instance.
Click Applications.
Select the application.
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:
If you stop a parent application (such as the default application), then Application Server Control automatically stops any child applications that depend upon the parent application.
If you start a child application, Enterprise Manager automatically starts the required parent application.
Application Server Control restricts you from performing certain management tasks on the ascontrol application because this application represents the Application Server Control Console, which is used to manage your application server environment:
If you are managing one, standalone OC4J instance, then you cannot stop, start, or restart the ascontrol application. If you stopped this application, you would be unable to display or use the Application Server Control Console.
If you are in clustered environment, where you are managing multiple OC4J instances, then you can use the Cluster Topology page to start, stop, or restart the ascontrol application, as well as the OC4J instances on which it is deployed. However, the Application Server Control Console displays a warning that describes the implications of stopping the active ascontrol application.
If you are using the Cluster Topology page to manage multiple OC4J instances, you will notice that each OC4J instance includes an ascontrol application. In most cases, only the active ascontrol application is up and running.
If you attempt to view the log files for a remote OC4J instance using the Log Viewer, Application Server Control checks to see if an ascontrol application is running in any OC4J instance within the remote Oracle Application Server instance. If no ascontrol application is running in that application server instance, Application Server Control displays a message stating that the remote ascontrol must be started.
You can then choose to start the remote ascontrol application or cancel the operation. If you choose to start ascontrol from the Log Viewer, note that the remote ascontrol will not be configured to receive HTTP requests from Oracle HTTP Server. However, from the Cluster Topology page, you will see that the remote ascontrol is running. Later, when you are finished viewing and managing the remote log files with the Log Viewer, you can stop the remote ascontrol from the Cluster Topology page.
To restart or stop an OC4J instance through the Application Server Control Console:
Navigate to the OC4J Home page.
To restart an OC4J instance that is in a stopped state, click the Restart button.
To stop an OC4J instance, click the Stop button.
You can also restart or stop an OC4J instances 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 through the Application Server Control Console:
In the Groups section of the Cluster Topology page, select the group.
To restart a group of OC4J instances that are in a stopped state, click the Start button.
To stop a group of OC4J instances, click the Stop button.
To view, create, and delete data sources and connection pools (JDBC resources) for an OC4J instance through the Application Server Control Console:
Navigate to the OC4J Home page for the OC4J instance.
Click Administration to display the OC4J Administration page, which contains a table listing the various administration tasks you can perform for the OC4J instance.
If necessary, expand the Services section of the table by clicking the expand icon or by clicking Expand All.
Click the task icon in the JDBC Resources row of the table.
The Application Server Control Console displays the JDBC Resources page, which lists the data sources and connection pools currently available in the OC4J instance.
Use the drop-down menu to view the data sources and connection pools specific to a particular deployed application.
Click Help for more information about viewing, creating, and deleting data sources and connection pools.
To view, create, and delete data sources and connection pools (JDBC resources) for a group of OC4J instances:
Navigate to the Cluster Topology page.
Scroll to the Groups section of the page and click the name of the group you want configure.
Click Administration to display the Group Administration page, which contains a table listing the various administration tasks you can perform for the group.
If necessary, expand the Services section of the table by clicking the expand icon or by clicking Expand All.
Click the task icon in the JDBC Resources row of the table.
The Application Server Control Console 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.
Click Help for more information about viewing, creating, and deleting data sources and connection pools.
To manage JMS destinations through the Application Server Control Console:
Navigate to the OC4J Home page for the OC4J instance.
Click Administration to display the OC4J Administration page, which contains a table listing the various administration tasks you can perform for this OC4J instance.
If necessary, expand the Services section of the table by clicking the expand icon or by clicking Expand All.
Click the task icon in the JMS Destinations row of the table.
The Application Server Control Console 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 through the Application Server Control Console, see the online help topics.
