Skip Headers
Oracle® Application Server Release Notes
10g Release 2 (10.1.2) for Linux x86
B19312-12
  Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents

Previous
Previous
 
Next
Next
 

6 Oracle Application Server Containers for J2EE

This chapter describes issues with Oracle Application Server Containers for J2EE (OC4J). It includes the following topics:

6.1 OC4J Bugs Fixed in 10.1.2.0.2

The following OC4J-related bugs have been resolved in 10.1.2.0.2:

6.2 Configuration Issues and Workarounds

This section describes configuration issues and their workarounds for Oracle Application Server Containers for J2EE (OC4J). It includes the following topics:

6.2.1 Remove the Tomcat Examples

OC4J ships the Tomcat examples by default. Many of the Tomcat examples do not conform to the Oracle Secure Coding Standards. Oracle recommends that you remove the Tomcat examples except when used in demonstration and testing environments.

6.2.2 Oracle JDBC-OCI Driver Upgrade in the Oracle Application Server

It is not possible to upgrade to an arbitrary Oracle JDBC-OCI driver version due to client library compatibility constraints. Upgrading to OCI driver versions with matching Oracle Client libraries that are installed within the Oracle Application Server 10g (10.1.2) is supported. For example, Oracle JDBC 10.1.x drivers are supported, but the Oracle JDBC 9.2.x drivers are not.

Where the use of JDBC-OCI within the Oracle Application Server is supported, it is also necessary for the opmn.xml entry for each OC4J instance to propagate appropriate ORACLE_HOME and library path values to its startup environment.

The environment variable ORACLE_HOME is common to all platforms, but the name of the environment variable that specifies the library path is different depending on the operating systems:

  • LD_LIBRARY_PATH for Solaris and Linux

  • LIBPATH for AIX

  • SHLIB_PATH for HP-UX, HP Itanium and HP Tru64 UNIX

  • PATH for Windows

The generic syntax for specifying the library paths in opmn.xml looks like this:

<variable_id="LIB_PATH_VARIABLE" value="LIB_PATH_VARIABLE_VALUE"/>

where LIB_PATH_VARIABLE should be replaced with the appropriate platform-specific variable name that specifies the library path, and

LIB_PATH_VARIABLE_VALUE

should be replaced with that variable's value.

Here is an example, assuming the Solaris Operating system:

    <process-type id="OC4J_SECURITY" module-id="OC4J">
      <environment>
        <variable id="ORACLE_HOME"
  value="/u01/app/oracle/product/inf10120"/>
        <variable
          id="LD_LIBRARY_PATH"
          value="/u01/app/oracle/product/inf10120/lib"
        />
      </environment>
      ...
   

6.2.3 OC4J Out of Memory Errors

If the OC4J default JVM heap size is too small for applications that you deploy, then you may see Out Of Memory errors from your OC4J processes. If you review the log files for the OC4J Instance in the directory$ORACLE_HOME/opmn/logs, you may find errors similar to the following:

java.lang.OutOfMemoryError

To work around this problem, increase the specified heap memory by changing the Java command line options for the OC4J Instance.

Using Application Server Control Console, go to the OC4J instance homepage and perform the following steps:

  1. Stop the OC4J Instance.

  2. Drill down to the Server Properties page.

  3. In the Command Line Options area of the Server Properties page, under the heading Multiple VM Configuration, set the Java Options.

    For example, enter the following to set the JVM heap sizes to 512 Megabytes:

    -Xmx512m 
     
    
  4. Use the Apply button to apply the changes.

  5. Start the OC4J instance.

For more information, see the Oracle Application Server Performance Guide.

6.2.4 JDK 1.3 With OC4J 10.1.2.0.2

In order to use JDK 1.3, which is not shipped with OC4J 10.1.2, modify JDK 1.3 as follows:

  1. Download and install JAAS1.0_01 from http://java.sun.com/javase/technologies/security/

  2. Drop jaas.jar from the JAAS1.0_01 distribution into jre/lib/ext

  3. Add the following lines into jre/lib/security/java.security.

    #These two lines are Oracle-specific definitions 
    # 
    auth.policy.provider=oracle.security.jazn.spi.PolicyProvider 
    @ login.configuration.provider=oracle.security.jazn.spi.LoginConfigProvider 
    

6.2.5 Configuring Maximum Connections with Oracle HTTP Server

In standalone OC4J, you can configure the maximum number of connections by using the <max-http-connections> subelement of <application-server> in the server.xml file. (This is documented in the Oracle Application Server Containers for J2EE User's Guide.)

Now there is also a <max-ajp-connections> subelement of <application-server> to configure a maximum number of connections for use with Oracle HTTP Server. For example:

<application-server>
   ...
   <max-ajp-connections value="10000" max-connections-queue-timeout="10" 
                        close-idle-connection="allow">
        http://optional.redirect.url/page.jsp
   </max-ajp-connections>
   ...
<application-server>

The (optional) value of the element indicates a redirect-URL, the usage of which is described as follows.

Attributes of <max-ajp-connections>:

  • value: The maximum number of connections allowed. The default value is -1, for no limit. (0 is a reserved value.)

  • max-connections-queue-timeout: How many seconds to wait for the number of connections to drop below the maximum number. If a connection is attempted when the maximum number of connections has been reached, and there are still no available connections after the timeout expires, then appropriate action is taken depending on other settings. The default is 0 seconds.

  • close-idle-connection: A setting of allow (the default) makes a new connection possible by allowing the least-recently used (LRU) idle connection to be closed if the maximum number of connections has been reached and the queue timeout has expired. Use deny to disallow the LRU idle connection to be closed.

  • socket-backlog: The number of connections to queue up before denying connections at the socket level. The default is 30. This is inherited from <max-http-connections> functionality, but has no particular use in addition to other <max-ajp-connections> attribute settings; there should be no reason to use a value other than the default.

There are three possible responses when a connection is being attempted after the maximum number of connections has been reached and the timeout has expired:

  • If close-idle-connection="allow", the connection listener will close the oldest open idle connection by closing the client socket (but the working thread is allowed to finish its work). This allows the attempted connection to be accepted.

  • If close-idle-connection="deny" and a redirect-URL is specified in the <max-ajp-connections> element value (as shown in the preceding example), then the connection listener will reject the attempted connection with a 302 Moved Temporarily HTTP response. (The client system is expected to immediately retry the alternate URL.) The client socket of the attempted connection is then closed.

  • If close-idle-connection="deny" and no redirect-URL is specified, then the connection listener will reject the attempted connection and send a 503 Service Unavailable HTTP response. The client socket of the attempted connection is then closed.

6.2.6 Use of '/' for Context Root

Specification of "/" for the context root when deploying an application to OC4J is supported now. This includes support by Application Server Control and admin_client.jar.

Background: The 10.1.3.1 release of the Oracle Containers for J2EE Configuration and Administration Guide states that "Specifying a root setting of "/" will override the OC4J default Web application. This setting or a null setting is not allowed by the admin_client.jar utility when binding a Web application to the Web site."

Now, however, a root setting of "/" is allowed. You can use this as the context root when deploying an application. The following example uses admin_client.jar to deploy a WAR file and bind to "/".

% java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 \
  -deploy -file d:how-to-rolling-upgrade-web-v1.war -deploymentName h2ru_2 \
  -bindAllWebApps -contextRoot "/" 

Be aware that if an EAR file includes an application.xml file that has the context root set to "/", such as in the following example, then "/" will be the default context root when the application is deployed using either Application Server Control or admin_client.jar.

<application>
  <display-name>How-To Rolling Upgrade</display-name>
  <module>
    <web>
      <web-uri>how-to-rolling-upgrade-web.war</web-uri>
      <context-root>/</context-root>
    </web>
  </module>
</application>

Attributes of <max-ajp-connections>:


Note:

Because the default ping URL for Oracle HTTP Server is also "/", using "/" as the context root when you deploy an application may result in the following issues:
  • Pings intended for Oracle HTTP Server go directly to OC4J instead.

  • Extraneous HEAD requests appear in the *-web-access.log file.

You can avoid these issues by placing the following directive:

Oc4jMountCopy off

Into the following file:

ORACLE_HOME/Apache/Apache/conf/dms.conf

6.2.7 Use of the http.file.allowAlias Property

By default, OC4J now ships with the http.file.allowAlias property set to false. This setting prevents the use of symbolic links. Oracle strongly recommends that this setting not be changed to true, which might allow JSP source code to be visible to end users in some circumstances.

Instead of changing the property setting, you can use one of the following workarounds:

  • Temporarily switch from using the OC4J lightweight HTTP listener to front ending the OC4J application through Oracle HTTP Server, so that browsers access the pages indirectly through MOD_OC4J and Apache JServ Protocol (AJP), rather than directly through HTTP

  • Replace all symbolic links in an application with the names of the real files they represent.

    You can use a shell script to automate the replacement of symbolic links. For example:

    #!/bin/ksh
    
    PROGNAME="${0##*/}"
    LN_EXTN="ln"
    
    function displaySyntax
    {
    echo "${PROGNAME}! SYNTAX: ${PROGNAME} <some_dir_path>"
    exit 1
    }
    
    if [[ $# < 0 ]]
    then
    displaySyntax
    fi
    
    DIR="$1"
    
    if [[ ! -d ${DIR} ]]
    then
    displaySyntax
    fi
    
    find ${DIR} -type l|while read filepath
    do
    echo "FIXING: ${filepath} (=> ${filepath}.${LN_EXTN})"
    mv ${filepath} ${filepath}.${LN_EXTN}
    cp -L ${filepath}.${LN_EXTN} ${filepath}
    done
    

This example KSH script would be invoked on LINUX as follows:

$ fixLinks <web_module_root>

The script will recurse through any directory and, for any file it finds that is a symbolic link, will rename each link with an additional .ln extension and then place a copy of the link target in the original location where the link was found.

6.3 Enterprise Java Beans

This section describes issues with Enterprise Java Beans (EJB). It includes the following topics:

6.3.1 Deprecated orion-ejb-jar.xml Attributes

The following orion-ejb-jar.xml attributes are deprecated in releases 9.0.4.1 and 10.1.2 and will be removed in release 10.1.3:

  • max-instances-per-pk

  • min-instances-per-pk

  • disable-wrapper-cache

  • disable-wrapper-cache

In addition, the following locking-mode attribute setting is deprecated:

  • locking-mode="old_pessimistic"

6.3.2 Big EAR File Deployment Runs Out of Memory

OutOfMemory exceptions occur when deploying EAR files with a large number of EJBs.

As part of the deployment process, wrapper code classes are generated for each EJB. The size of these classes is proportional to the number of business methods on the bean. As a performance optimization, OC4J compiles all wrapper code classes in one compiler invocation. An error can occur if the amount of generated wrapper code is too much for available memory.

A workaround is to direct the deployment process to compile each EJB module's wrapper code individually. You can do this by starting OC4J with the ejbdeploy.batch system property and setting it to false, as in the following example:

-Dejbdeploy.batch=false

Note:

This workaround should only be used when this specific exception occurs.

This workaround may result in an increased deployment time for the application.


6.3.3 EJB Wrapper Code Compilation Fails When Running in zh_CN.GB18030 Locale

EJB wrapper code compilation fails when running in zh_CN.GB18030 locale. When running in zh_CN.GB18030 locale, parts of the EJB wrapper source code may be generated with missing characters. This causes compilation errors. The missing characters in the generated source code are due to a Sun bug documented at:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4954023

The workaround is to use a different locale. See the Sun bug for details.

6.3.4 Disregard Previous Release Note: Package Name for RMIInitialContextFactory Has Changed

Disregard the following release note from the initial 10.1.2 release notes. The information does not apply to the 10.1.2 release.

"The package name for RMIInitialContextFactory has changed from oracle.j2ee.rmi.server to oracle.j2ee.rmi. "

6.3.5 How To Disable EJB Instance Pooling

To disable instance pooling, use the new <max-instances> setting with any negative number in the orion-ejb-jar.xml file. This creates a new instance at the start of the EJB call and releases it at the end of the call.

6.3.6 How To Compile in Non-Batch Mode

To compile in non-batch mode (for example, if OC4J throws java.lang.OutOfMemory exceptions while compiling in batch mode), use the -Dejbdeploy.batch=false option. Although non-batch mode requires less memory allocation, this mode results in a longer deployment time.

6.4 OC4J Services

This section describes release notes for OC4J services. OC4J Services include: Java Naming and Directory Interface (JNDI), Java Message Service (JMS), Data Sources, Oracle Remote Method Invocation (ORMI), J2EE Interoperability (IIOP), Java Transaction API (JTA), J2EE Connector Architecture (J2CA), and Java Object Cache.

The section contains the following release note(s):

6.4.1 Data Sources

This section describes issues with Data Sources. It includes the following topics:

6.4.1.1 Data Sources Creates the Correct Number of Connection Pools in 10.1.2

In the 9.0.4 release, Data Sources incorrectly created multiple connection pools for the same data source: One pool for transactional connections and one pool for non-transactional connections.

This behavior is corrected for release 10.1.2.

6.4.1.2 Fatal Error Code Enhancement

For each data source defined in data-sources.xml, you can define fatal error codes that indicate that the back-end database with which the data source communicates is no longer accessible. When OC4J detects one of these error codes (stated when a SQLException is thrown by the JDBC driver), OC4J will clean its connection pool. That is, it closes all connections in the connection pool. For Oracle, the predefined fatal error codes are: 3113, 3114, 1033, 1034, 1089, and 1090.

Use the following procedure to add additional fatal error codes for Oracle.

Use the <fatal-error-codes> element, which is a subtag of the <data-source> element. The <fatal-error-codes> element uses the child element <error-code> to define one fatal error code. You can define 0 - n <error-code> elements for each <fatal-error-codes> element. For example, for fatal error codes 10, 20, and 30, the data source definition would look like this:

<data-source 
class="com.evermind.sql.DriverManagerDataSource" 
name="ds" 
location="jdbc/ds" 
xa-location="jdbc/xa/ds" 
ejb-location="jdbc/ejb/ds" 
@ connection-driver="oracle.jdbc.driver.OracleDriver" 
username="scott" 
@ password="tiger" 

@ url="jdbc:oracle:thin:@//localhost:1521/oracle.regress.rdbms.dev.us.oracle.com">
 
         <fatal-error-codes> 
            <error-code code='10'/> 
            <error-code code='20'/> 
            <error-code code='30'/> 
         </fatal-error-codes> 

</data-source> 

6.4.1.3 Fixed Connection Pool Problems

The following connection pool problems are fixed in 10.1.2.0.2.

In pre-10.1.2.0.2 versions of OC4J, the data sources subsystem would create multiple connection pools for the same data source for the following cases:

  • When a connection was used inside a global transaction and outside a global transaction during the same thread of execution (during the execution of a servlet for example.) In this case one connection pool was created for connections used inside global transactions and one connection pool was created for connections used outside of the global transaction.

  • When a connection was retrieved from the data source using the non-default user or password. For example, the use of getConnection() caused one connection pool to be created and getConnection("user", "password") caused another connection pool to be created. This is especially bad because each user or password combination created another, separate connection pool.

  • Indicating via configuration that a data source's connections are to be shared caused an additional data source to be created under the covers which would then duplicate all of the connection pool issues described previously.

This resolves code bug 4226465 and documentation bug 4373802.

6.4.1.4 Upgrading the Oracle THIN JDBC Driver

The JDBC THIN driver cannot be upgraded or changed at the Oracle Application Server-instance level due to component dependencies. JDBC THIN driver upgrades must be completed for each OC4J instance.

To update the Oracle THIN JDBC driver for an OC4J instance:

  1. Copy the new JDBC libraries to a directory on the OC4J host computer.

  2. On the Oracle Application Server-instance host, open the iAS_ORACLE_HOME/opmn/conf/opmn.xml file.

  3. From the opmn.xml file, find the <ias-component> entry for the OC4J instance that is being upgraded with a new JDBC THIN driver.

  4. Add (or modify) the -Djava.ext.dirs Java option to include the location to the directory that contains the new JDBC libraries. For example:

    <module-data>
       <category id="start-parameters">
          <data id="java-options" 
                value="-Djava.ext.dirs=path/to/the/new/JDBC_dir"/>
       </category>
    
  5. Save and close the opmn.xml file.

  6. From the command line, propagate the configuration changes to the DCM repository:

    dcmctl updateconfig -ct opmn
    
  7. Stop and then start the OC4J instance:

    opmnctl stopproc process-type=<oc4j_instance_name>
    
    opmnctl startproc process-type=<oc4j_instance_name>
    

6.4.2 ORMI

This section describes issues with ORMI. It includes the following topics:

6.4.2.1 ORMI - OC4J Only Creates IPv4 Sockets

OC4J only creates IPv4 sockets. Even on dual network stack machines (with both IPv4 and IPv6 stacks available) OC4J creates only IPv4 sockets. This may cause a problem if client-issued requests are from a IPv6 system. This is indicated by connection-refused messages from the server to the IPv6 client. To avoid this problem, start the client process with the system property java.net.preferIPv4Stack=true. This forces the client to only issue IPv4 requests, allowing it to communicate with the server.

6.4.2.2 ORMI Protocol Is Not Secure

It should be noted that the ORMI protocol is not secure. Any and all communication over ORMI is not encrypted including security credentials. Customers that want to encrypt ORMI traffic are advised to use ORMI over HTTPS, which will encrypt all communication between the client and the server.

6.4.3 JNDI

This section describes issues with JNDI. It includes the following topic(s):

6.4.3.1 Local Host Not Supported

The java.naming.provider.url JNDI property does not support the value localhost when a remote client connects to an application server instance that is managed by OPMN. The value must be the complete hostname or IP Address. This does not affect clients that connect to standalone application server instances.

6.5 Oracle Application Server Java Authentication and Authorization Service (JAAS) Provider

Be aware of the following notes when using the Oracle Application Server Java Authentication and Authorization Service (JAAS) Provider (OracleAS JAAS Provider) in release 10.1.2.0.2:

6.5.1 Using the 9.0.4 Oracle Internet Directory Server with 10.1.2.0.2 OracleAS JAAS Provider

Prior to the 10.1.2 Oracle Internet Directory implementation, Access Control List (ACL) features are not set up properly for JAZNAdminGroup. To use the 9.0.4 Oracle Internet Directory implementation with the 10.1.2 OracleAS JAAS Provider implementation, place the following contents into a file, replacing %s_MgmtRealmDN% with the appropriate ID management realm (for example, dc=us,dc=oracle,dc=com), then execute the steps that follow.

dn: cn=JAZNContext,cn=Products,cn=OracleContext,%s_MgmtRealmDN%
changetype: modify
replace: orclaci
orclaci: access to entry
   by group= 
"cn=JAZNAdminGroup,cn=Groups,cn=JAZNContext,cn=Products,cn=OracleContext" 
(browse, add, delete)
   by group= "cn=IASAdmins,cn=Groups,cn=OracleContext,%s_MgmtRealmDN%
added_object_constraint=(objectclass=orclApplicationEntity) (add, delete, browse)
   by * (none)
orclaci: access to attr=(*)
   by group= 
"cn=JAZNAdminGroup,cn=Groups,cn=JAZNContext,cn=Products,cn=OracleContext"
(search, read, write, compare)
   by group= "cn=IASAdmins,cn=Groups,cn=OracleContext,%s_MgmtRealmDN%" 
(read, search, write, compare)
   by * (none)
  1. Name the file with the .ldif extension, such as jaznacl.ldif.

  2. Run the ldapmodify utility with the newly created file as input, specifying oidport, oidhost, adminuser_dn, password, and filename as appropriate:

    ldapmodify -c -a -p oidport -h oidhost -D adminuser_dn -w password \
               -f filename.ldif
    

6.5.2 Support for auth-method="DIGEST" in <jazn-web-app>

The 10.1.2.0.2 OracleAS JAAS Provider implementation now supports the setting auth-method="DIGEST" in the <jazn-web-app> element, in either the orion-web.xml file or orion-application.xml file. This is in addition to the already supported setting auth-method="SSO". Support for DIGEST is already noted in the 10.1.2.0.2 Oracle Application Server Containers for J2EE Servlet Developer's Guide (which includes reference documentation for orion-web.xml), but is not indicated in the 10.1.2.0.2 Oracle Application Server Containers for J2EE User's Guide (which includes reference documentation for orion-application.xml). "SSO" is to use Oracle Application Server Single Sign-On for HTTP client authentication. DIGEST is to use the digest authentication mechanism. See the 10.1.2.0.2 Oracle Application Server Containers for J2EE Security Guide for complete information.

6.5.3 AJP13 Protocol Vulnerable to Bypass User Authentication

When OC4J is running a site using the AJP13 protocol, a security vulnerability exists if a remote attacker can directly access the AJP port on the machine running OC4J. The AJP13 protocol defines an AJP parameter remote_user, which is used by OHS to implement mod_osso. An attacker can use this parameter to bypass authentication on OC4J. If a user constructs an AJP packet that inserts a valid remote_user value as an AJP parameter, the user will be able to access resources that the specified user (remote user) has permission to access.

You must ensure that the system running OC4J does not expose the AJP port to the outside world.

You can protect against the vulnerability in either of the following ways:

  • Enable SSL between OC4J and Oracle HTTP Server (preferred). For 10.1.3.x releases, this is documented in the Oracle Application Server Containers for J2EE Security Guide. For release 10.1.2 or 9.0.4, this is documented in the Oracle Application Server Containers for J2EE Servlet Developer's Guide.

  • Use the <access-mask> element (a subelement of <orion-web-app>) in global-web-application.xml or orion-web.xml to restrict access to appropriate host names, domains, or IP addresses. This element is documented in the Oracle Application Server Containers for J2EE Servlet Developer's Guide.

6.6 Documentation Errata

This section describes known errors in the OC4J documentation in Oracle Application Server 10g Release 2 (10.1.2). It covers the following books:

6.6.1 Oracle Application Server Containers for J2EE User's Guide Documentation Errata

This section describes known errors in the Oracle Application Server Containers for J2EE User's Guide. It includes the following topic(s):

6.6.1.1 An OC4J Process Is Not Contained in an OC4J Instance

The following incorrect statement appears in the Oracle Application Server Containers for J2EE User's Guide Chapter 8, OC4J Clustering:

"Each OC4J process is contained in an OC4J instance and inherits its configuration from the OC4J instance. All applications deployed to an OC4J instance are deployed to all OC4J processes in the OC4J instance."

The statement is incorrect because an OC4J process can only be contained in other processes, an OC4J instance is not a process.

The correct statement in this case is:

"Each OC4J process is associated to an OC4J instance and inherits its configuration from that OC4J instance. All applications deployed to an OC4J instance are started in all the OC4J processes associated to that OC4J instance."

6.6.1.2 Correct Cross Reference for Metric-Based Load Balancing Information

In the description of the <metric-collector> element of the server.xml file in Appendix B - Additional Information of the Oracle Application Server Containers for J2EE User's Guide, the following incorrect cross reference is given:

"For details on using the <metric-collector> element and using metric-based load balancing with mod_oc4j, see the Oracle Application Server 10g Performance Guide."

Replace the incorrect cross reference with the following correct cross reference:

For details on using metric-based load balancing with mod_oc4j, see the Oracle HTTP Server Administrator's Guide.

6.6.1.3 JDK 1.4.2 Supported and Installed with OC4J

Chapter 1: "OC4J Overview" of the Oracle Application Server Containers for J2EE User's Guide contains incorrect references to the Java Development Kit (JDK) used with Oracle Application Server Containers for J2EE 10g Release 2 (10.1.2).

The "Using JDK With OC4J" section lists JDK 1.3.1 and 1.4.1 as the supported versions. This list should also include JDK 1.4.2.

The "Requirements" section incorrectly states that JDK 1.3.x is installed with OC4J. The correct version is JDK 1.4.2.

6.6.1.4 Primers Content Removed from OC4J User's Guide

Chapter 1: "OC4J Overview" of the Oracle Application Server Containers for J2EE User's Guide contains a reference to primers, which are no longer included in the User's Guide.

6.6.1.5 Additional OC4J Deployment Notes

The following notes on undeployment and redeployment are intended to supplement the deployment discussion in the Oracle Application Server Containers for J2EE User's Guide.

General undeployment/redeployment notes:

  • Once an application is undeployed from OC4J, it is no longer accessible to clients. In an Oracle Application Server environment, Oracle HTTP Server will be restarted to remove the OC4J mount point. This will result in the loss of existing HTTP sessions.

  • During a redeployment, OC4J removes the existing application (EAR/WAR) before redeploying the new EAR. This means, for example, that attempts to access an HTML file that was included in the previous application, but not the new one, will result in "File Not Found" errors.

  • Also note that a redeployed WAR file overlays the previously expanded WAR, meaning that some older files may persist in the new deployment and will need to be deleted. For example, static HTML files from the previous deployment that are not included in the new WAR may continue to reside in the expanded WAR directory structure, and would have to be manually deleted.

Hot redeployment notes:


Note:

A hot deployment is deploying an application without restarting OC4J.

  • When an EAR is redeployed or hot redeployed on a running OC4J instance, the status of the classes loaded in the JVM from the previous application may vary. In some cases a classloader may recognize that a class or JAR file in the file system has changed, and reload the class or library. In other cases, whether a new class definition is loaded, may depend on whether the JVM tuning allows the garbage collector to flush the existing class definition.

  • Issues may also exist with respect to serialized objects containing session data. If the class related to a session object changes, it may not be possible to cast the generic session object back to the class, since the class has changed and its variables may occupy a different memory footprint. This may result in lost session data.

  • In an Oracle Application Server environment, a hot deployment adds Oc4jMount directives to mod_oc4j.conf, which in turn forces a restart of Oracle HTTP Server. This will result in the loss of existing HTTP sessions.

6.6.1.6 Corrected Default Log File Name

Table 3-3 of the Oracle Application Server Containers for J2EE User's Guide 10g Release 2 (10.1.2) states incorrectly that the default log file name for the OC4J is web-access.log. The correct default log file name is default-web-access.log.

The corrected table with the corrected default log file name for OC4J is as follows:

Table 6-1 List of Log Files Generated for OC4J

Default Log File Name Description Scope Configuration File
application.log

All events, errors, and exceptions for a deployed application

One log file for each application deployed

orion-application. xml
global-application. log

All common events, errors, and exceptions related to applications

All applications, including the default application

application.xml
jms.log

All JMS events and errors.

JMS sub-system

jms.xml
rmi.log

All RMI events and errors

RMI sub-system

rmi.xml
server.log

All events not associated with a particular sub-system or an application. This logs history of server startup, shutdown internal server errors.

Server-wide

server.xml
default-web-access. log

All accesses to the Web site

Each Web site

default-web-site.xml

6.6.1.7 Manual Build and Deploy Methods Apply To Standalone Environment Only

The "Building and Deploying Within a Directory" section of Chapter 3, "Advanced Configuration andDevelopment" of the Oracle Application Server Containers for J2EE User's Guide 10g Release 2 (10.1.2) should include the following note:


Note:

The manual build and deploy methods described in this section can be used in the standalone OC4J environment only, not in the enterprise environment.

In the enterprise environment, use the Oracle Enterprise Manager 10g to build and deploy applications.


6.6.1.8 High Availability Guide Has No Information on "Hot Deploying" an Application in a Clustered Environment

According to the Oracle Application Server Containers for J2EE User's Guide 10g Release 2 (10.1.2), deploying a new Web module to an active OC4J instance causes loss of the HTTP sessions for every Web application running within the server instance.

In a non-clustered environment, this issue can be avoided by using the persistence-path attribute in the root <orion-web-app> element within each orion-web.xml file. This workaround does not apply to a clustered environment.

The User's Guide indicates incorrectly that the Oracle Application Server High Availability Guide provides "guidelines on addressing this issue in a clustered environment". In fact, the Oracle Application Server High Availability Guide provides no information about this topic.

6.6.1.9 For State Replication, Confirm That the <cluster-config/> Tag Is in the orion-web.xml File

The "Configuring Web Application State Replication" section in Chapter 4, "OC4J Cluster Configuration of the Oracle Application Server Containers for J2EE User's Guide 10g Release 2 (10.1.2), provides a six-step procedure for configuring state replication for Web applications.

In addition to the six steps, confirm that the <cluster-config/> tag has been added to the global-web-application.xml file. If this tag has not been added to the global-web-application.xml file, then add the tag to the orion-web.xml file. The orion-web.xml file is in the following location:

ORACLE_HOME/j2ee/<instance_name>/applications/<app_name>/<app_name>/WEB-INF/orion-web.xml

The <cluster-config/> tag is a subelement of the <orion-web-app> tag. For more information about the orion-web.xml file and the <cluster-config/> tag, see Chapter 6, "Configuration File Descriptions", of the Oracle Application Server Containers for J2EE Servlet Developer's Guide.

6.6.1.10 Correction to Sharing Libraries Documentation

This release note adds information to clarify the Sharing Libraries section of Chapter 3, Advanced Configuration and Development, of the 10.1.2 Oracle Application Server Containers for J2EE User's Guide.

The examples given are potentially misleading in that, by default, there is already a <library> element for the \j2ee\home\applib\ directory. Also note that there is an applib directory for each OC4J instance, not just the home instance.

6.6.1.11 Add the Description of the -userThreads Option

In "Appendix B - Additional Information" of the Oracle Application Server Containers for J2EE User's Guide, add the following description of the -userThreads option to Table B-2 OC4J Command-Line Options.

-userThreads Enables context lookup support from user-created threads.

6.6.2 Oracle Application Server Containers for J2EE Standalone User's Guide Documentation Errata

This section describes known errors in the Oracle Application Server Containers for J2EE Standalone User's Guide. It includes the following topic(s):

6.6.2.1 Correction: http-web-site

The following error appears in the "Deploy Using the Admin.JAR Tool in All Environments" section of Chapter 1, "Configuration and Deployment" of the Oracle Application Server Containers for J2EE Stand Alone User's Guide :

In the -bindWebApp example, the Web site name http_web_site is incorrect.

The correct Web site name in this case is: http-web-site.

The corrected example is as follows:

java -jar admin.jar
ormi://oc4j_host:oc4j_ormi_port
admin welcome -bindWebApp
FAQApp FAQAppWeb http-web-site /FAQApp

6.6.3 Oracle XML API Reference Documentation Errata

This section describes known errors in the Oracle XML API Reference. It includes the following topic:

6.6.3.1 Add Information for formDocument() Method

In the Oracle XML API Reference, Chapter 15, "Package Dom APIs for C++", add the following entries:

  • On page 15-22, in Table 15-7 "Summary of DOMImplRef Methods; Dom Package", add an entry for formDocument() method, description: "Forms a document reference given a pointer to the document."

  • On page 15-24, add the following method description:

    formDocument()

    Description

    Forms a document reference given a pointer to the document.

    Syntax

    DocumentRef< Node>* formDocument( Node* node); 
    

    ----------------------------------------------------

    Parameter Description

    ----------------------------------------------------

    node Pointer to the document node.

    ----------------------------------------------------

    Returns

    DocumentRef< Node>* pointer to the document reference.

6.6.4 Oracle Application Server Containers for J2EE Services Guide Documentation Errata

This section describes known errors in the OC4J Services Guide. It includes the following topics:

6.6.4.1 Corrected SQLServer Data Source Example

On page 4-24 in "Example DataDirect Data Source Entries", the Oracle Application Server Containers for J2EE Services Guide shows the following example as a data source entry for SQLServer. However, the example is incorrect, a colon is missing.

@ url="jdbc:sqlserver//hostname:port;User=test;Password=secret" 
 

The correct example is as follows:

@ url="jdbc:sqlserver://hostname:port;User=test;Password=secret"

6.6.4.2 Corrected JDBC Connect String for Third-Party Databases

In the "Example DataDirect Data Source Entries" section of the "Data Sources" chapter of the Oracle Application Server Containers for J2EE Services Guide for 9.0.4 and 10.1.2.x, the URLs in the examples are incorrect.

The INCORRECT part of the URL is as follows:

 url="jdbc:databasevendor://... 

The CORRECT URL fragment is as follows:

 url="jdbc:oracle:databasevendor://... 

The corrected example DataDirect Data Source Entries are as follows:

SQLServer

Here is a data source configuration sample for a SQLServer database.

<data-source 
                 class="com.evermind.sql.DriverManagerDataSource" 
                 name="OracleDS" 
                 location="jdbc/OracleCoreDS" 
                 xa-location="jdbc/xa/OracleXADS" 
                 ejb-location="jdbc/OracleDS" 
                 schema="database-schemas/ms-sql.xml" 
                 
 connection-driver="com.oracle.ias.jdbc.sqlserver.SQLServerDriver" 
                 username="mssql" 
                 password="mssql" 
                 
 url="jdbc:oracle:sqlserver://PZWU-PC\WUPZIAS;User=mssql;Password=mssql" 
                 inactivity-timeout="30" 
 /> 

DB2

Here is a data source configuration sample for a DB2 database:

  <data-source 
                   class="com.evermind.sql.DriverManagerDataSource" 
                   connection-driver="com.oracle.ias.jdbc.db2.DB2Driver" 
                   name="OracleDS" 
                   location="jdbc/OracleCoreDS" 
                   xa-location="jdbc/xa/OracleXADS" 
                   ejb-location="jdbc/OracleDS" 
                   schema="database-schemas/db2.xml" 
                   username="db2admin" 
                   password="db2admin" 
                   
 url="jdbc:oracle:db2://ying.us.oracle.com:50000;DatabaseName=sample;CreateDefa ultPackage=TRUE" 
                   inactivity-timeout="30" 
/> 

Sybase

Here is a data source configuration sample for a Sybase database:

  <data-source 
                 class="com.evermind.sql.DriverManagerDataSource" 
                 name="OracleDS" 
                 location="jdbc/OracleCoreDS" 
                 xa-location="jdbc/xa/OracleXADS" 
                 ejb-location="jdbc/OracleDS" 
                 schema="database-schemas/sybase.xml" 
                 connection-driver="com.oracle.ias.jdbc.sybase.SybaseDriver" 
                 username="JDBC_TEST" 
                 password="JDBC_TEST" 
                 url="jdbc:oracle:sybase://dlsun150:4101" 
                 inactivity-timeout="30" 
 /> 

Informix

Here is a data source configuration sample for an Informix database:

 <data-source 
                 class="com.evermind.sql.DriverManagerDataSource" 
                 name="OracleDS" 
                 location="jdbc/OracleCoreDS" 
                 xa-location="jdbc/xa/OracleXADS" 
                 ejb-location="jdbc/OracleDS" 
                 schema="database-schemas/informix.xml" 
                 
 connection-driver="com.oracle.ias.jdbc.informix.InformixDriver" 
                 username="tg4odbc" 
                 password="tg4odbc" 
                 
 url="jdbc:oracle:informix://dlsun150:3900;informixServer=gtw93;DatabaseName=ga tewaydb" 
                 inactivity-timeout="30" 
 /> 

6.6.4.3 Corrected Java Object Cache Code Example for Implementing a CacheEventListener

In the "*Implementing a Cache Event Listener" section of the "Java Object Cache" chapter of the Oracle Application Server Containers for J2EE Services Guide for 10.1.2.0.2, Example 9-14 has mismatched braces and misleading indentation.

The corrected example for Implementing a CacheEventListener is as follows:

import oracle.ias.cache.*; 
 
    // A CacheEventListener for a cache object 
    class MyEventListener implements CacheEventListener 
    { 
 
        public void handleEvent(CacheEvent ev) throws CacheException 
        { 
           MyObject obj = (MyObject)ev.getSource(); 
           obj.cleanup(); 
        } 
     } 
 
 class MyObject 
 { 
   public void cleanup() 
   { 
     // do something 
   } 
 } 
 
 import oracle.ias.cache.*; 
 
    // A CacheEventListener for a group object 
     class MyGroupEventListener implements CacheEventListener 
     { 
        public void handleEvent(CacheEvent ev) throws CacheException 
        { 
           String groupName = (String)ev.getSource(); 
           notify("group " + groupName + " has been invalidated"); 
 
        } 
        void notify(String str) 
        { 
          // do something 
        } 
     } 

6.6.4.4 Also Add the ojdl.jar File to the Classpath to Access EJBs

In the 10.1.2 Oracle Application Server Containers for J2EE Services Guide, add the following item to the "Client-Side Requirements" section of Chapter 5, "Oracle Remote Method Invocation" and again to the "Client-Side Requirements" section in Chapter 6, "J2EE Interoperability":

"Also add the ojdl.jar file to the classpath. The ojdl.jar file is located within the Application Server installation and is not part of the OC4J client package. The ojdl.jar can be downloaded from the following URL:

http://www.oracle.com/technology/obe/obe_as_1012/j2ee/lookup/files/ojdl.jar

A tutorial related to this topic is available at the following URL:

http://www.oracle.com/technology/obe/obe_as_1012/j2ee/lookup/lookup.htm#install

6.6.5 Oracle Application Server Containers for J2EE Security Guide

This section describes issues with the Oracle Application Server Containers for J2EE Security Guide. It includes the following topics:

6.6.5.1 Incorrect Example in Deployment Roles and Users

On page 3-8 of the Oracle Application Server Containers for J2EE Security Guide, under "Deployment Roles and Users", there is an example that does not properly close the <type> and <name> subelements of a <member> element. Here is the corrected example:

<role>
 <name>developer</name>
  <members>
   <member>
    <type>user</type>
    <name>john</name>
   </member>
  </members>
</role> 

6.6.5.2 Incorrect internal-settings.xml Information

The Oracle Application Server Containers for J2EE Security Guide incorrectly states that the internal-settings.xml file supports password indirection for keystore-password and truststore-password (page 14-2). This is incorrect; the internal-settings.xml file does not support password indirection.

6.6.5.3 Incorrect RMIPermission and AdministrationPermission Class Information

In several places in the Oracle Application Server Containers for J2EE Security Guide for release 10.1.0.2, the package for RMIPermission and for AdministrationPermission is incorrectly identified as oracle.j2ee.server.

The correct package for RMIPermission in 10.1.0.2 is com.evermind.server.rmi.

The correct package for AdministrationPermission in 10.1.0.2 is com.evermind.server.

6.6.6 OC4J Release Notes for 10.1.2.0.2

This section describes issues with the OC4J Release Notes for 10.1.2.0.2. It includes the following topic:

6.6.6.1 Disregard Previous Release Note: Package Name for RMIInitialContextFactory Has Changed

Disregard the following release note from the initial 10.1.2 OC4J Release Notes. The information does not apply to the 10.1.2 release.

"The package name for RMIInitialContextFactory has changed from oracle.j2ee.rmi.server to oracle.j2ee.rmi. "