3 General Management and Security Issues

3.1.1 Limited Management Support for Multiple-JVM OC4J Instances

With Oracle Application Server 10g Release 3 (10.1.3.2), you can configure any OC4J instance to use multiple Java Virtual Machines (JVMs). You can perform this configuration change by using the Application Server Control Console or by setting the numprocs argument in the opmn.xml file to a number greater than one (1).

The opmn.xml file is located in the following directory in your Oracle Application Server Oracle home:

ORACLE_HOME\opmn\conf\

To set the number JVMs in the Application Server Control Console, see "Creating Additional JVMs for an OC4J Instance" in the Application Server Control online help.

To set the number of JVMs by editing the numprocs argument in the opmn.xml file, refer to the following example, which shows the numprocs entry you must modify:

<ias-component id="OC4J">
  <process-type id="home" module-id="OC4J" status="enabled">
        .
        .
        .
      <process-set id="default_group" numprocs="2"/>
   </process-type>
</ias-component>

Note, however, that this feature is not supported by Application Server Control. Specifically, Application Server Control (represented by the ascontrol application) cannot run on an OC4J instance that is running multiple JVMs. As a result, be sure that you do not configure multiple JVMs for the administration OC4J instance (the OC4J instance that is hosting the active ascontrol).If you choose to configure the number of JVMs for the administration OC4J to more than one (1), then you must use command line tools to manage your Oracle Application Server environment. For example, you must use:

• admin_client.jar for deployment, re-deployment, undeployment, start and stop applications, and shared library management

• Apache Ant for deployment, redeployment, and undeployment of your applications

• opmnctl commands for starting, stopping, and other life cycle operations on the Oracle Application Server

Further, if you are using multiple JVMs on the administration OC4J and, as a result, the Application Server Control Console is not available, then you must make any Oracle Application Server instance configuration changes manually. Manual configuration changes often require you to shut down the Oracle Application Server instance, manually configure the relevant XML files, and then restart Oracle Application Server.

3.1.2 OC4J Restart Required When Changing the Name or URL of a JDBC Data Source or Connection Pool

If you modify the name or the connection URL of a JDBC data source or JDBC connection pool, then you must restart the OC4J instance; otherwise the changes you make will not take effect.

For example, if you use the JDBC Resources page in the Application Server Control Console to change the connection URL of a JDBC connection pool, you will not be prompted to restart the OC4J instance, but the restart is required. If you do not restart the OC4J instance, any deployed applications that require the data source will attempt to use the original connection URL.

3.1.3 Problem Removing a Property from a Native Data Source

If you use the Application Server Control Console to remove a property from a native data source, Enterprise Manager does not remove the property from the underlying connection factory. As a result, the property (and its current value) is not changed.

This is expected behavior. To set a value on the underlying connection factory, use the setProperty operation of the JDBCDataSource MBean for the native Data Source to do this. You can use the MBean Browser, which is available in the Application Server Control Console, to invoke an MBean operation.

3.1.4 Important Restriction When Setting Thread Pool Size on the Thread Pool Configuration Page

By default, the Thread Pool Configuration page in the Application Server Control Console shows a Minimum Pool Size of one (1) for an unconfigured thread pool. This value is expected, but do not click OK on this screen with a minimum thread pool size set to one (1) for any thread pool.

If you are configuring OC4J thread pools using the Thread Pool Configuration Administration task, be sure to replace the default value for the minimum thread pool size to a number that is greater than 10; otherwise, you will not be able to login to the Application Server Control Console the next time you restart the OC4J instance.

In the event that you set the minimum thread pool size to 1 and then click OK on the Thread Pool Configuration page, and as a result, you cannot access the Application Server Control Console, do the following:

1. Stop the OC4J instance using the command line.

   For example, on a Microsoft Windows system, in a managed Oracle Application Server environment, enter the following command:

   ORACLE_HOME\opmn\bin\opmnctl stopall
   

   See Also:

   "Starting and Stopping" in the Oracle Application Server Administrator's Guide

   "Starting and Stopping OC4J" in the Oracle Containers for J2EE Configuration and Administration Guide

2. Edit the server.xml file so that all thread pools are configured with a minimum pool size that is greater than 10.

   The server.xml for the OC4J instance is located in the following directory:

   ORACLE_HOME/OC4J_instance_name/config/
   
   

   For example:

   ORACLE_HOME/home/config/
   
   

Alternatively, to reset thread pool configuration to the default to factory settings, remove the <global-thread-pool> element and the <work-manager-thread-pool> element from the server.xml file.

3.1.5 Use the Command-Line to Restart Standalone OC4J Instances

Some OC4J configuration pages in the Application Server Control Console (including the JTA Administration and Oracle Internet Directory Association pages) require a restart of the OC4J instance for changes to take affect. Users are notified of this with on screen warnings during configuration operations on these components.

If are using the Application Server Control Console in a standalone OC4J environment, and you use the Restart link, which is displayed after applying changes to one of these pages, the operation may take a few minutes because it performs an internal restart of the OC4J instance. As a result, instead of using the Restart link, Oracle recommends that OC4J standalone users use the command line to restart the OC4J instance.

3.1.6 TopLink Sessions Not Available in Application Server Control Console

If the TopLink Sessions for a TopLink-enabled application are not available in Application Server Control Console, check to be sure the TopLink session is configured to create the MBeans at login time. This is done by ensuring that the application has a serverPlatform class defined, and that the ServerPlatform class has its is RuntimeServicesEnabled flag enabled.

For Oracle Application Server 10g Release 3 (10.1.3.2), you should be using the following platform class, which can be set in the sessions.xml or through the session API:

oracle.toplink.platform.server.oc4j.Oc4j_10_1_3_Platform

When developing a TopLink-enabled application using Oracle JDeveloper, make sure to use version 11 or higher.

3.1.7 Unable to Receive MBean Notification Using OPMN to Start or Stop OC4J

You will not be able to receive notification from the ias:j2eeType=J2EEServer,name... MBean entity if you start or stop Oracle Containers for J2EE (OC4J) using OPMN. This happens using either the Application Server Control or the opmnctl stop or opmnct start command from the command line.

There is presently no workaround for this issue.

3.1.8 Using the Java Server Pages Standard Tag Libraries

The Java Server Pages Standard Tag Library (JSTL) makes use of Jaxp 1.2 classes that are packaged with Java Developer Kit 1.4.

Oracle Application Server 10g Release 3 (10.1.3.2) makes use of JDK 1.5 which uses Jaxp 1.3 classes. However, the JSTL still requires the Jaxp1.2 classes. If you run the JSTL with XML related tags in JDK 1.5 you may receive an error message similar to:

: missing class org.apache.xpath.encounter failure.

To avoid JSTL failure, include the xalan.jar file in the required .war file. Add the xalan.jar file into your /WEB-INF/lib directory with the .war file and then re-package.

For more information refer to the JSTL release notes at:

http://java.sun.com/webservices/docs/1.6/jstl/ReleaseNotes.html.

3.1.9 RMD Conditional Does Not Fully Evaluate

As documented in the Oracle Process Manager and Notification Server Administrator's Guide and functional specifications for Dynamic Resource Management (DRM), a Resource Management Directive (RMD) conditional can have a fully qualified path. However, the conditional may not evaluate at all. It may fail to trigger any action or exception even though the opmn.xml file is valid.

RMD definitions can be either:

• Hierarchical: if defined at the ias-instance level or lower. Hierarchical RMDs assume an association within the OPMN configuration components in which they are defined.

• Global: if defined at the process-manager level. Global RMDs require explicit OPMN component specifications.

If you are referencing a hierarchical RMD, instead of a fully qualified path use a hierarchical relative reference.

For example, if the average request time is greater than 500 milliseconds for at least 60 seconds and there are less then 4 processes running for the process-set at which the hierarchical RMD was configured for OC4J, you would use the following in the opmn.xml file:

([process].avgReqTime > 500 {duration(60)})&([process-set].numProcs < 4)

If you are referencing a global RMD use a global absolute reference.

For example, if the heap size of a Java Virtual Machine (JVM) has exceeded 500 MBs, you would use the following in the opmn.xml file:

[process-set=home][process].heapSize > 500000

Note that the opmn.xml file is located in the following directory in your Oracle Application Server Oracle home:

ORACLE_HOME\opmn\conf\

3.1.10 Cannot Browse System MBeans If Application Server and OC4J Instance Share the Same Name

When you install Oracle Application Server 10g Release 3 (10.1.3.2) and specify a name for the default OC4J instance, do not use a name that matches the name of the Oracle Application Server instance or the first few characters of the Oracle Application Server instance name; otherwise, you will be unable to browse the system or applications MBeans using the Application Server Control MBean Browser.

For example, you will not be able to browse the MBeans for the instance if the name of your OC4J instance and the name of your Oracle Application Server instance are as follows:

Oracle Application Server instance name: instance1_as10132.node1.acme.com OC4J instance name: instance1

Similarly, keep this restriction in mind when you are creating additional OC4J instances. Do not use a name that matches the name of the Oracle Application Server that is hosting the OC4J instance.

3.1.11 Application Server Control Does Not Check for Multibyte Characters in Routing ID Text Fields

From the Application Server Control Console, you can modify the routing IDs assigned to the various components of your Oracle Application Server cluster topology.

However, when you enter a unique identifier for a Routing ID, be sure to use only alphanumeric characters and underscores. If you attempt to create a routing ID using multibyte characters, you will be unable to stop or start Oracle Process Manager and Notification Server (OPMN).

If you inadvertently use multibyte characters in a routing ID field, you can remedy the problem by editing the opmn.xml file and replacing the multibyte characters with regular ASCII characters.

The opmn.xml file is located in the following directory in your Oracle Application Server Oracle home:

ORACLE_HOME\opmn\conf\

The routing ID for each component is defined within a data element similar to the following:

<category id="start-parameters">
    <data id="routing-id" value="g_rt_id"/>
</category>

3.1.12 Application Server Control Does Not Check for All Invalid Characters in the Context Root Field When Deploying an Application

When you deploy an application from Application Server Control, you are prompted to specify the context root for the application. Application Server Control verifies the text you enter in the Context Root field to prevent you from entering invalid characters.

However, Application Server Control does not check for all invalid characters, such as some Western European characters. As a result, if you enter a context root that contains these types of characters, Application Server Control allows you to proceed with the deployment of the application, but after deployment, you will not be able to access the application using the Web server URL that contains the context root.

Only alphanumeric characters and the underscore (_), plus sign (+), and dash (-) characters are allowed when specifying a context root.

If you inadvertently enter an invalid character, such as a Western European character, in the Context Root field, you can remedy the problem by redeploying the application using a context root that contains only ASCII alphanumeric characters and underscores.

3.2.1 Using Oracle Universal Installer Provided Sample Cluster Discovery Address May Inadvertently Cluster Servers

Oracle Universal Installer provides an example cluster discovery address as part of the advanced installation option. The provide example discovery address is 225.0.0.1:6789. This is not a recommended address; rather it is an example intended to provide the type of cluster discovery address users may ask for from their network administrator.

Because the cluster configuration of Oracle Application Server is fully dynamic it is possible for installations using the example cluster discovery address (225.0.0.1:6789) to be inadvertently clustered with other servers installed with the same example cluster discovery address.

The cluster discovery address of a specific Oracle Application Server instance can be set from the command line using the following opmnctl command:

> $ORACLE_HOME/opmn/bin/opmnctl config topology update discover=<cluster config address> 

For example, to update a cluster discovery address in a specific Oracle Application Server instance to be 225.0.0.1:9876, the command would be:

> $ORACLE_HOME/opmn/bin/opmnctl config topology update discover="*225.0.0.1:9876" 

Details on configuring topologies and the cluster discovery address can be found in Chapter 8, "Configuring and Managing Clusters" of the Oracle Containers for J2EE Configuration and Administration Guide.

3.3.1 Valid Range of Multicast Addresses is Incorrect in the Application Server Control Online Help

The following topics in the Application Server Control online help incorrectly state the valid range of addresses you can use for a multicast address when configuring an Oracle Application Server 10g Release 3 (10.1.3.2) cluster topology:

• "Tips When Configuring the Cluster Topology"

• "Summary of the Supported Cluster Topologies"

The multicast address must be within the following range: 224.0.1.0 to 239.255.255.255.

3.3.2 Additional Information About Cloning

If ORACLE_HOME/portal/conf/javacache.xml is present in the source environment, you must manually modify this file in the cloned environment.

In this file, change the following:

• In the <location> element, replace the value of the source ORACLE_HOME with the value of the cloned ORACLE_HOME.

• In the <coordinator discovery-port> element, change the value to the new port number.