Skip Headers

Oracle9i Application Server Release Notes
Release 2 (9.0.3) for Solaris Operating System (SPARC)

Part Number B10015-01
Go To Core Documentation
Core
Go To Platform Documentation
Platform
Go To Table Of Contents
Contents

Go to previous page Go to next page

6
Oracle9iAS Containers for J2EE (OC4J)

This chapter discusses issues with Oracle9iAS Containers for J2EE (OC4J). It includes the following topics:

6.1 Release Notes for CTS Compatibility Flag and Migration Issues

This section discusses the OC4J CTS compatibility flag relating to J2EE 1.3 compatibility, and covers J2EE 1.3 migration considerations for some OC4J subcomponents.

6.1.1 Master CTS Compatibility Flag

In Oracle9iAS Release 2 (9.0.3), OC4J by default complies with the J2EE 1.3 specification. In some cases, this results in behavior that differs from that seen with previous OC4J implementations. To allow for backward compatibility, OC4J supports a CTS compliance flag that you can set to false to revert to previous OC4J behavior in the following components:

The compliance behavior of OC4J is determined by the flag oracle.cts.useCtsFlags, with a default value of true. If any of the migration issues are critical in a particular application, you can disable CTS compliance and revert to old behavior for an OC4J instance by setting the flag value to false in an OC4J properties file, then providing the location of the properties file to OC4J.

For example, you might create a file OC4J.properties in the OC4J config directory, with the following content:

oracle.cts.useCtsFlags=false

In Oracle9iAS, supply the name and location of a properties file to OC4J through an <oc4j-option> element in the opmn.xml file, as in the following example:

<oc4j>
...
   <oc4j-option value="-p ORACLE_HOME/j2ee/home/config/OC4J.properties" />
...
</oc4j>

This is equivalent to starting OC4J as follows in standalone mode (where % is a system prompt):

% java -jar OC4J -p ORACLE_HOME/j2ee/home/config/OC4J.properties

6.1.2 CTS Compatibility: Migration Considerations for OJMS

In the Oracle9iAS Release 2 (9.0.3) implementation of Oracle JMS (OJMS), which complies with J2EE 1.3, some behavior differs from OJMS behavior in Oracle9iAS release 1.0.2.2. (There are no such migration considerations between Oracle9iAS releases 9.0.2 and 9.0.3.) The differences are as follows:

6.1.3 CTS Compatibility: Migration Considerations for JDBC

In the Oracle9iAS Release 2 (9.0.3) implementation of Oracle JDBC, which complies with J2EE 1.3, some behavior differs from JDBC behavior in Oracle9iAS Release 2 (9.0.2) and prior. The differences are as follows:

6.1.4 CTS Compatibility: Migration Considerations for JAXP/XDK XML Parser

In the Oracle9iAS Release 2 (9.0.3) implementation of the XML parser for JAXP/XDK, which complies with J2EE 1.3, some behavior differs from XML parser behavior in Oracle9iAS Release 2 (9.0.2) and prior. The differences are as follows:

6.2 Release Notes for JMS

This section describes issues for Java Message Service (JMS).

See also:

Section 6.1, "Release Notes for CTS Compatibility Flag and Migration Issues".

6.2.1 Using Oracle JMS

To use Oracle JMS, you must do one of the following:

6.2.2 OC4J/JMS Should Not Be Used in Oracle9iAS Releases 1.0.2.2, 9.0.2, and 9.0.3

In Oracle9iAS Release 1.0.2.2, Release 2 (9.0.2), and Release 2 (9.0.3), OC4J contains a default Java Message Service (JMS) provider called OC4J/JMS (sometimes referred to as OrionJMS). Because OC4J/JMS is not fully JMS 1.02-compliant and was not used to achieve J2EE 1.3 compatibility, we recommend using the Oracle JMS (OJMS) implementation, which is provided. This JMS provider leverages Advanced Queueing (AQ) from the Oracle9i Database and is integrated into Oracle9iAS by means of a resource provider interface. In Oracle9iAS Release 2 (9.0.3), OJMS is JMS 1.0 compliant and was used to achieve J2EE 1.3 compatibility.

6.2.3 Timeout Error with MDB

You may receive an ORA-04021 message "timeout occurred while waiting to lock object SYS.DBMS_AQ" when creating queues if an MDB is executing within OC4J at the same time. If you receive this message, try to create the queues again.

6.3 Release Notes for DataDirect Connect JDBC Driver

This section contains release notes for the DataDirect Connect JDBC Driver.

6.3.1 Use of the DataDirect Connect JDBC Driver

A customized version of the DataDirect Connect JDBC driver is shipped with Oracle9iAS to provide connectivity to non-Oracle databases. Do not use the DataDirect Connect JDBC driver outside of Oracle9iAS; the driver is available only within Oracle9iAS. You should refer to standard DataDirect documentation and release notes for technical information on the DataDirect JDBC driver. However, it is important to note the differences between the standard DataDirect JDBC driver and this customized version:

6.4 Release Notes for JDBC

This section includes issues with JDBC that are not reflected in the Oracle9iAS Release 2 (9.0.3) documentation.

See also:

Section 6.1, "Release Notes for CTS Compatibility Flag and Migration Issues".

6.4.1 Incorrect BatchUpdateException ORA-01013

The version of JDBC shipped with Oracle9iAS Release 2 (9.0.3) is a patched version of Oracle9i JDBC 9.0.1.4. This patch fixes the problem (noted in bug 2232903) of the issuance of an incorrect BatchUpdateException ORA-01013. You may see the exception when performing a statement execution right after a statement cancellation.

6.5 Release Notes for JAXP/XDK XML Parser

This section contains release notes for the JAXP/XDK XML Parser.

See also:

Section 6.1, "Release Notes for CTS Compatibility Flag and Migration Issues".

6.5.1 Preservation of White Space

As of Oracle9iAS Release 2 (9.0.3), the default setting for preservation of white space is dependent on the presence of the DTD--if the DTD is present, the default value is false; if it is not present, the default value is true.

In Oracle9iAS Release 2 (9.0.2) and prior, the default was always false.

You can explicitly set the value through the setPreserveWhitespace() method of the oracle.xml.parser.v2.XMLParser class.

6.6 Release Notes for JSP, Tag Libraries, and Related Demos

The following release notes apply to OC4J JSP, JSP tag libraries, and related demo applications as of Oracle9iAS Release 2 (9.0.3).

6.6.1 JSP Application Security: Protection Against Cross-Site Script (XSS) Attacks

OJSP demo applications in Oracle9iAS Release 2 (9.0.3) have been updated according to the Secure Coding Standards (addressing bug 2485625). The standards include a directive to filter user input that is subsequently sent to a Web browser. This avoids cross-site script (XSS) vulnerability and provides an example to users of how to produce a secure application.

Any JSP page with output that includes a string containing user input must first filter the string, replacing special HTML characters with their mnemonic equivalents to prevent them from being interpreted as actual tags.

Before echoing or printing data from request parameters--either directly, or indirectly through a Java variable value--create a string in which special characters are replaced as follows:

For example, change the following JSP code:

<% out.print(mystr); %> 

to something like the following:

<% out.print(util.HTMLReplace(mystr)); %>

where util.HTMLReplace() is defined as follows:

<%!

// The demoUtil class will be declared as an inner class in any JSP which
// includes this file.
class demoUtil
{
  // List of mappings.  The first element is the original HTML special
  // character, and the second the replacement string.
  public String[][] mappings =
  {{"<", "&lt"}, 
   {">", "&gt"},
   {"&", "&amp"},
   {"\"", "&quot"}};

  /**
   * HTMLReplace()
   * Returns the input string with any HTML special characters replaced by
   * their mnemonic equivalents.
   *
   * @param input  Input string
   * @return       Input with characters replaced
   */
  public String HTMLReplace(String input)
  {
    StringBuffer output = new StringBuffer();

    // Loop over the input string
    for (int i = 0; i < input.length(); i++)
    {
      boolean replaced = false;
      String current = input.substring(i, i + 1);

      // For each character in the input, loop through the mappings
      for (int j = 0; j < mappings.length; j++)
      {
        // and replace if necessary
        if (current.equalsIgnoreCase(mappings[j][0]))
        {
          replaced = true;
          output = output.append(mappings[j][1]);
          break;
        }
      }
      if (!replaced)
        output.append(current);
    }

    return new String(output);
  }
}

// Declare an instance of the demoUtil class, which can then be referenced
// with "util".
demoUtil util = new demoUtil();

%>

As a test, the following in a text entry field would expose a cookie if you do not take the above precautions:

<script>alert(document.cookie)</script>

For background information on XSS attack vulnerability, refer to the following Web site:

http://www.cert.org/advisories/CA-2000-02.html

6.6.2 Miscellaneous JSP and ojspc Release Notes

The following release notes apply to JavaServer Pages and the ojspc pre-translation utility (batch pre-translation only):

6.6.3 Miscellaneous JSP, Tag Library, and Demo Release Notes

The following release notes apply to JSP tag libraries and related demo applications:

6.6.4 JSP Tag Library URIs

As of Oracle9iAS Release 2 (9.0.3), the tag libraries bundled with OC4J JSP are packaged with their tag library descriptor (TLD) files inside ojsputil.jar.

Each .tld file contains an appropriate <uri> setting for accessing the tag library. For convenience, you can define a shortcut for any tag library URI in your web.xml file. The URIs for the OC4J JSP TLD files are defined in the TLD files themselves, as follows:

In the ejbtaglib.tld file:

<uri>http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/ejbtaglib.tld</uri>

In the email.tld file:

<uri>http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/email.tld</uri>

In the fileaccess.tld file:

<uri>http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/fileaccess.tld</uri>

In the jesitaglib.tld file:

<uri>http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/jesitaglib.tld</uri>

In the jml.tld file:

<uri>http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/jml.tld</uri>

In the jwcache.tld file:

<uri>http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/jwcache.tld</uri>

In the personalization.tld file:

<uri>http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/personalization.tld</uri>

In the sqltaglib.tld file:

<uri>http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/sqltaglib.tld</uri>

In the utiltaglib.tld file:

<uri>http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/utiltaglib.tld</uri>

In the wstaglib.tld file:

<uri>http://xmlns.oracle.com/j2ee/jsp/tld/ws/wstaglib.tld</uri>

In the xml.tld file:

<uri>http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/xml.tld</uri>

In your web.xml file, you can specify a shortcut for any of these URI settings by using a <taglib> element and its subelements, as in the following example:

<taglib>
   <taglib-uri>/oraejbtags</taglib-uri>
   <taglib-location>http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/ejbtaglib.tld
   </taglib-location>
</taglib>

Given this example, a JSP page can use the following taglib directive to access the EJB tag library:

<%@ taglib prefix="ejb" uri="/oraejbtags" %>

See the Oracle9iAS Containers for J2EE JavaServer Pages Developer's Guide for more information about use of tag library URIs.

6.6.5 JSP Bug Fixes of Note

JSP bug fixes for Oracle9iAS Release 2 (9.0.3) include the following:

6.7 Release Notes for Data Sources

The following release notes apply to OC4J data sources.

6.7.1 Connection Pooling

If you set the minimum number of connections in your application, these connections are pooled for you after the first getConnection() method invocation. However, when you undeploy this application, these connections are not scavenged for you.

6.7.2 Client-Side Data Source Lookup Not Supported

Bug 2143605--A client cannot use data sources to get connections. The client should use DriverManager to get the connections.

6.8 Release Notes for EJB

The following release notes apply to Enterprise JavaBeans.

6.8.1 General EJB Backward Compatibility Issues

The dedicated.connection system property for load balancing is deprecated. Instead, use the dedicated.rmicontext system property. See the "Performance" section of the Oracle9iAS Containers for J2EE Enterprise JavaBeans Developer's Guide for more information on the dedicated.rmicontext system property.

The old_pessimistic locking mode is also deprecated. The other locking modes are described in the "Advanced" chapter of the Oracle9iAS Containers for J2EE Enterprise JavaBeans Developer's Guide.

6.8.2 Container-Managed Persistence

EJB applications that used the proprietary container-managed fields and relationships features from earlier versions are not EJB 2.0-compliant. These applications must be migrated to use the standard EJB 2.0 features.

Oracle9iAS Release 2 (9.0.2) required specifying the object relationships in the orion-ejb-jar.xml file. Oracle9iAS Release 2 (9.0.3) requires using the standard EJB 2.0 CMR definitions in ejb-jar.xml. Programs that used the old 9.0.2-style CMR definitions must be migrated to the EJB 2.0 standard.

6.8.2.1 Dependent Objects

Bugs 2465874 and 2454567--Oracle9iAS Release 2 (9.0.2) supported mappings of dependent objects. This feature does not work in Oracle9iAS Release 2 (9.0.3) and will be deprecated in Oracle10iAS. You can serialize the dependent object as a BLOB or use container-managed relationships as workarounds.

6.8.2.2 Self-Referencing

Bug 2504337--If you set up a many-to-many or one-to-many self-referencing relationship, the association table does not generate properly.

Workaround--Do not use the association table for self-referencing. This can be achieved by specifying associateUsingThirdTable=false at startup, or, in the input orion-ejb-jar.xml file, by specifying the "collection" table to be the same as the "many" table.

6.8.2.3 Association Table for One-to-Many Unidirectional Relationships

In Oracle9iAS Release 2 (9.0.3), OC4J creates an association table for one-to-many unidirectional relationships regardless of the setting of -DassociateUsingThirdTable.

6.8.2.4 Association Table for One-to-One Unidirectional Relationships

In one-to-one unidirectional cases, the rules of relationship assignment specified in the Oracle9iAS Containers for J2EE Enterprise JavaBeans Developer's Guide are valid only if the getter and setter methods are executed in one transaction.

6.8.3 Message-Driven Beans

Message Driven Beans (MDBs) work only with Oracle JMS. They do not work with OC4J/JMS, MQSeries, or SonicMQ.

The min-instances, max-instances, and cache-timeout elements are not recommended for use with 9.0.3. Use listener-threads instead for concurrent support for both topics and queues. If listener-threads is set to greater than 1, the container spawns as many threads as specified to concurrently process messages.

The current behavior of min-instances, max-instances, and cache-timeout (with default of cache-timeout as 120 seconds and no default for min-instances and max-instances) for MDBs is that the container pre-creates the minimum number of instances during deployment, after which other bean instances are created as needed when client requests come in. However, after the cache-timeout period expires, the pool size does not deflate to min-instances.

6.8.3.1 Backward Compatibility for MDBs

An MDB must now implement the javax.jms.MessageListener interface in addition to the javax.ejb.MessageDrivenBean interface. This was introduced in the final version of the EJB 2.0 specification.

The tag used to specify an MDB destination in the ejb-jar.xml file was changed in the final version of the EJB 2.0 specification. The earlier tag <jms-destination-type> must be changed to <destination-type>.

The 9.0.2 MDB implementation was not EJB 2.0-compliant. Thus, to bring your MDBs up to EJB 2.0 compliance, you must modify the ejb-jar.xml file of the MDB to specify the <resource-ref> and <resource-env-ref> mappings for the Destination and Factory objects. Otherwise, your 9.0.2 MDB will not work in 9.0.3.

6.8.3.2 Core Dump During Shutdown of OC4J Server

If you configured MDBs using OJMS with the JDBC OCI Driver, you may encounter a core dump during shutdown of the OC4J server. The workaround is to use the JDBC Thin driver.

6.8.3.3 Modification for MDB Demos

When using the MDB demos shipped with 9.0.3, modify the file ORACLE_HOME/j2ee/home/demo/mdb/common.xml to run ant to compile the demos. Replace the following:

<pathelement location="J2EE_HOME/lib/classes12.jar"/>

with:

<pathelement location="ORACLE_HOME/jdbc/lib/classes12dms.jar"/>

6.8.4 Interoperability

When running RMI/IIOP with JDK 1.4, you must start the OC4J instance with the following -D system property:

-Djavax.rmi.CORBA.UtilClass=com.sum.corba.ee.internal.POA.ShutdownUtilDelegate

If you do not provide this system property, you will receive a ClassCastException.

6.8.4.1 CosNaming

You can use CosNaming only to retrieve EJB references. You cannot look up other resources.

6.8.4.2 Potential IIOP Port Conflicts

By default, IIOP is not enabled. To enable IIOP, uncomment the <sep-config> element in the server.xml file that points to the internal-settings.xml file. If you do enable IIOP, you may encounter IIOP port conflicts. The IIOP ports currently are not managed by OPMN. Instead, fixed IIOP ports of 5555, 5556, and 5557 are provided. IIOP without SSL is port 5555. SSL with server authentication is port 5556. SSL with client authentication is port 5557. If you are using IIOP and encounter port conflicts, you must manually change the default port number for each OC4J process in the internal-settings.xml file.

6.8.5 EJB Client Using an RMI Port

OC4J is configured to assign an RMI or JMS port dynamically within set ranges. However, if you have a standalone EJB client, you must know an exact port number to direct your request. Perform the following steps:

  1. Pick a port number that is not being used by the OC4J process.

  2. Modify the opmn.xml file, using the Enterprise Manager Advanced Properties screen, within the OPMN configuration. Change the RMI or JMS range to the specified port number. The following demonstrates setting the RMI port to 3202 in the opmn.xml file:

    <port ajp="..." jms="..." rmi="3202"/>
    
    
  3. Restart the OC4J process to initialize the new port numbers.

  4. Configure the same port number within the JNDI properties of the standalone client. The following demonstrates setting the same RMI port number in the JNDI properties for the EJB client:

    java.naming.provider.url=ormi://myhost:3202/myapp
    

6.8.6 EJB QL Backward Compatibility for Finder Methods

In Oracle9iAS Release 2 (9.0.3) and previous releases, OC4J had its own methodology for finder methods. These finder methods were configured in the orion-ejb-jar.xml file in a <finder-method> element. Each <finder-method> element specified a partial or full SQL statement in its query attribute, as follows:

<finder-method query="">

or:

<finder-method query="$empname = $1">

If you have a <finder-method> element with a query attribute from a previous release, it overrides any EJB QL modifications to the same method in the ejb-jar.xml file. The <finder-method> element with a query attribute configured in orion-ejb-jar.xml has higher priority.

To have the previous finder method modified with EJB QL, erase the query attribute of the <finder-method> element in the orion-ejb-jar.xml file and redeploy the application. OC4J notes that the query attribute is not present and uses the EJB QL methodology from the ejb-jar.xml file instead.

6.8.7 OC4J Does Not Passivate Stateful EJBs when Server Runs out of Memory

The OC4J server does not passivate stateful EJBs when the server runs out of memory. Stateful EJBs are passivated only when the OC4J server shuts down. However, EJB resources are released whenever a a stateful EJB times out. To avoid locking up resources unnecessarily, set an appropriate timeout on stateful session beans.

6.8.8 EJB Security

Any user that executes the create() method (which in turn invokes the ejbCreate() method) must be a member of the Administrator group or role that is created in the principals.xml or JAZN configuration files.

6.8.9 EJB Clustering

If you use the split-tier mode of clustering, then you must set the -D option of dedicated.rmicontext=true on the client tier. As mentioned in the "Advanced" chapter of the Oracle9iAS Containers for J2EE Enterprise JavaBeans Developer's Guide, this is the recommended method for scalability.

6.9 Release Notes for RMI

The following release notes apply to RMI (Remote Method Invocation).

6.9.1 RMI/IIOP Client Support

The client JAR file--oc4jclient.jar--does not support RMI/IIOP. For a client to use RMI/IIOP, the client must use the oc4j.jar file.

6.10 Release Notes for Servlets

The following release notes apply to the OC4J servlet container.

6.10.1 NullPointerException when Invoking Remote EJB from Servlet or JSP

A NullPointerException is generated when a servlet or JSP tries to look up a remote EJB in another container in any situation in which dedicated.connection and dedicated.rmicontext are disabled.

For Oracle9iAS Release 2 (9.0.3), set dedicated.rmicontext to a value of "true".

6.11 Release Notes for JAZN

The following release notes apply to JAZN, the Oracle JAAS implementation.

6.11.1 Clustering Support for JAZN admintool

Clustering support has been added to the JAZN Admintool in Oracle9iAS Release 2 (9.0.3).

To enable this functionality, invoke the tool with the following:

-clustersupport ORACLE_HOME

where ORACLE_HOME is the absolute path of the Oracle home directory.

If you invoke the JAZN Admintool with the -clustersupport flag, then JAZN will propagate the changes made through the Admintool to the other instances in the cluster. (This applies to JAZN-XML only.)

For example, to invoke the JAZN Admintool in shell mode, execute the following at the command prompt:

java -jar jazn.jar -clustersupport /private/foo/ora9ias -shell

The preceding assumes that the OC4J instance has been configured correctly for the clustering environment.

For more information about the JAZN Admintool, refer to the Oracle9iAS Containers for J2EE Services Guide.

6.11.2 Miscellaneous JAZN Issues

Be aware of these issues regarding the JAZN product in Oracle9iAS Release 2 (9.0.3):

6.11.3 Changing User Manager from JAZN LDAP to XML Has No Dynamic Effect

If the user manager for OC4J is changed from JAZN LDAP to JAZN XML, the change is not picked up dynamically. OC4J continues to use JAZN LDAP as the user manager. You must restart OC4J when the user manager is changed from JAZN LDAP to XML for the change to take effect.

6.12 Release Notes for J2EE Connector Architecture

The following release notes apply to J2EE Connector Architecture.

6.12.1 JSP Page Compilation Problem

JSP pages that reference classes defined in a resource adapter, such as the CCI implementation classes, fail to compile. They generate an error indicating that the JSP compiler fails to find such classes or packages even though the resource adapter is contained in the same application as the .jsp files, or has already been deployed into OC4J.

The workaround to this problem is to add a <library> element to the orion-application.xml file of the application pointing to the JAR files from the resource adapter. For example:

<library path="connector-name/jar-file-name" />

where connector-name is the value of the name attribute in the <connector> element for the resource adapter defined in the oc4j-connectors.xml file, and jar-file-name is the name of the JAR file inside the resource adapter that contains the classes that the JSP compiler is referencing in its error message.

Alternatively, if a <library> element exists in the orion-application.xml file and points to a particular directory, the JAR files of the resource adapter can simply be moved into that directory.

6.13 Release Notes for Oracle9iAS TopLink

Release Notes for Oracle9iAS TopLink are available in the following locations:

6.14 OC4J User's Guide Security Update

This section supplements Chapter 8 of the Oracle9iAS Containers for J2EE User's Guide.

6.14.1 Specifying Login Modules

Specify login module information by editing the Login Module section of the jazn-data.xml file.


Note:

To configure login modules, you must edit the jazn-data.xml file directly; you cannot use the JAZN AdminTool or the Enterprise Manager. In a clustered environment, you must then use dcmctl to propagate your changes; use dcmctl updateConfig, specifying JAZN as the component type.


6.14.2 Configuring Login Modules

To configure an application to use a LoginModule, you create an <application> entity for the module. Each <application> entity specifies the login modules for one application. An <application> entity contains a <name> entity for the application (the classname of the application) and a <login-modules> entity. The <login-modules> entity contains individual <login-module> entities, each specifying the LoginModule to be used by one class. A <login-module> entity specifies the following:

Table 6-1 LoginModule XML Tags in jazn-data.xml  
Tag Defines

<class>

The class that uses the LoginModule.

<control-flag>

Correlation to the Flag value in javax.security.auth.login.Configuration. The possible values are:

  • Required--The LoginModule is required to succeed. Whether it succeeds or fails, authentication continues on the next item in the LoginModule list.

  • Requisite--The LoginModule is required to succeed. If it succeeds, authentication continues on the next item in the LoginModule list. If it fails, control immediately returns to the application (authentication does not continue down the LoginModule list).

  • Sufficient--The LoginModule is not required to succeed. If it does succeed, control immediately returns to the application (authentication does not continue down the LoginModule list). If it fails, authentication continues down the LoginModule list.

  • Optional--The LoginModule is not required to succeed. Whether it succeeds or fails, authentication continues on the next item in the LoginModule list.

<options>

A list of <option> entities; these hold any arguments required by your LoginModule.

<option>

A <name> and a <value> for a single LoginModule argument.

6.14.3 Example LoginModule

A representative LoginModule entry in jazn-data.xml might look like this:

<!-- Login Module Data -->
<jazn-loginconfig>
  <application>
    <name>oracle.security.jazn.tools.JAZN.Admintool</name>
    <login-modules>
      <login-module>
        <class>oracle.security.jazn.realm.RealmLoginModule</class>
        <control-flag>required</control-flag> 
        <options>
          <option>
            <name>addRoles</name>
            <value>true</value>
          </option>
        </options>
      </login-module>
    </login-modules>
  </application>
</jazn-loginconfig>

6.15 Documentation Errata

This section describes known errors in the Oracle9iAS Release 2 (9.0.3) documentation.

6.15.1 OC4J Services Guide Errata

Note the following errata in the Oracle9iAS Containers for J2EE Services Guide:

6.15.1.1 Data Source Definition Syntax

The JTA chapter contains data source definitions (pages 12-13 and 12-14) with incorrect XML syntax. These definitions fail to close the <data-source> tag before opening the <property> tag.

The correct definitions are:

<data-source
  class="com.evermind.sql.OrionCMTDataSource"
  name="OracleCMTDS1"
  location="jdbc/OracleDS1"
  connection-driver="oracle.jdbc.driver.OracleDriver"
  username="scott"
  password="driver"
  url="jdbc:oracle:thin:@mysun:5521:jis"
  inactivity-timeout="30">
  <property name="dblink"
  value="LINK.REGRESS.RDBMS.DEV.US.ORACLE.COM"/>
</data-source>

<data-source
  class="com.evermind.sql.OrionCMTDataSource"
  name="OracleCMTDS2"
  location="jdbc/OracleDS2"
  connection-driver="oracle.jdbc.driver.OracleDriver"
  username="scott"
  password="driver"
  url="jdbc:oracle:thin:@mysun:6521:jis"
  inactivity-timeout="30">
  <property name="dblink"
  value="LINK.REGRESS.RDBMS.DEV.US.ORACLE.COM"/>
</data-source>

6.15.1.2 HTTPClient Support for java.net.URL

Chapter 15 includes the following note describing the support that HTTPClient provides for the java.net.URL class:

There are two errors in this passage:

6.15.2 OC4J Support for JavaServer Pages Developer's Guide Errata

This section describes errata in the Oracle9iAS Containers for J2EE JavaServer Pages Developer's Guide.

6.15.2.1 Location of Generated Files

Chapter 7, "JSP Translation and Deployment", in the section "JSP Translator Output File Locations", contains the following passages:

The preceding passage is in error. Actually, the JSP translator places generated output files under a _pages directory that is created under the JSP cache directory, which is specified in the jsp-cache-directory attribute of the <orion-web-app> element in either the global-web-application.xml file or the application orion-web.xml file. Here is the general base location if you assume the default "./persistence" value of jsp-cache-directory:

ORACLE_HOME/j2ee/home/app-deployment/app-name/web-app-name/persistence/_pages/...

For the example in the errant documentation passage above, the JSP translator would place the output files in the following directory:

ORACLE_HOME/j2ee/home/application-deployments/default/defaultWebApp/persistence/_pages/_examples/_jsp

6.15.2.2 Default Well-Known Tag Library Location

Chapter 8, "JSP Tag Libraries", in the section "Oracle Extension for Tag Library Sharing", states that the default value of well_known_taglib_loc is as follows:

j2ee/home/jsp/lib/taglib/

where this location is under ORACLE_HOME if defined, or otherwise under the current directory.

This documentation is incorrect when ORACLE_HOME is undefined. In this case, the default is actually as follows, under the current directory:

jsp/lib/taglib/

However, this is typically relevant only in an OC4J standalone environment, not in an Oracle9iAS environment.


Go to previous page Go to next page
Oracle
Copyright © 2002 Oracle Corporation.

All Rights Reserved.
Go To Core Documentation
Core
Go To Platform Documentation
Platform
Go To Table Of Contents
Contents