Skip Headers
Oracle® Application Server Release Notes
10g (9.0.4) for Solaris Operating System (SPARC)
Part No. B10629-15
  Go To Documentation Library
Home
Go To Table Of Contents
Contents

Previous
Previous
Next
Next
 

9 Oracle Application Server Containers for J2EE Issues

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

9.1 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:

9.1.1 OPMN Does Not Properly Assign CORBA SSL Client Ports for Default

In the Oracle Application Server environment, you must explicitly specify the port ranges for iiops1 and iiops2 in the opmn.xml file.

9.1.2 Sharing and Using Libraries

This section describes issues with sharing and using libraries. It includes the following topics:

9.1.2.1 Sharing Libraries

In Oracle Application Server 10g (9.0.4), we recommend creating specific <library> elements in the global application.xml file to load any libraries required by your application. We recommend this as a way to ensure efficient loading and desired loading order. (Libraries are loaded in the order in which the <library> elements are encountered.)

Note that in previous releases, you could put libraries into the j2ee/home/lib directory, which by default had a <library> element in application.xml. This directory is now reserved for OC4J system libraries, and the <library> element that points to it is no longer present in application.xml by default. If you want to use a general library location, use j2ee/home/applib. By default, there is now a <library> element pointing to that location in application.xml.

For general information about sharing libraries, refer to the Oracle Application Server Containers for J2EE User's Guide.

9.1.2.2 Invalid or Unneeded Library Elements Degrade Performance

If the OC4J process memory is growing consistently during program execution, then you may have references to invalid symbolic links in your global application.xml file. This problem is usually characterized by a growth in the C heap and not a growth in Java object memory, as one would see with a more traditional Java object memory leak. OC4J loads all resources using the links in the application.xml file. If these links are invalid, then the C heap continues to grow, causing OC4J to run out of memory. Ensure that all symbolic links are valid, and restart OC4J.

In addition, keep to a minimum the number of JAR files OC4J is configured to load. Eliminate all unused JAR files from the configuration and from the directories OC4J is configured to search. OC4J searches all JAR files for classes and resources, thereby causing the file cache to use extra memory and processor time.

You can control the loading more precisely if your <library> elements in the application.xml file point to the individual JAR and ZIP files that are needed, instead of to the directories where they reside.

9.1.2.3 Custom User Managers Deployed Within EJB JAR Files

Custom user manager classes deployed within Enterprise Java Beans (EJB) JAR files cannot be loaded by OC4J unless an explicit <library> element exists in the orion-application.xml file for the application. The <library> element must point to the JAR file containing the custom user manager classes. To allow the custom user manager to be resolved and instantiated, create the necessary <library> element, such as in the following example:

<orion-application ....>
   ... 
   <library path="applications\XmlnewsEar\XmlnewsEjb.jar"/>
   ... 
</orion-application>

9.1.3 Considerations for Startup and Shutdown Classes

  • You must use the JNDI context that is passed in as an argument to your startup and shutdown methods. You cannot create your own.

  • You should separate your shutdown class from any archive files (WAR and EAR) that will be undeployed before shutdown.

  • OC4J creates an instance of your startup class and an instance of your shutdown class. These are separate instances. If you implement the startup and shutdown interfaces in the same class, OC4J creates two instances of that class. In this case, you cannot share non static fields between your startup class and your shutdown class.

9.1.4 Using JDK with OC4J

This section describes issues with using JDK with OC4J. It includes the following topics:

9.1.4.1 Supported JDK Versions

You must have only one Java Developer's Kit (JDK) installed on your system. Make sure that it is a version that OC4J supports:

  • JDK 1.3.1

  • JDK 1.4.2

OC4J Standalone does not include a JDK. If you are using OC4J Standalone, then you must provide your own JDK installation.

Some suppliers bundle a JDK with their products. If necessary, remove any old version(s), replace them with a supported version, and update the appropriate environment variables. Make sure that your PATH, CLASSPATH, and LD_LIBRARY_PATH (or LIB on Windows) variables are all set to the officially supported version of JDK.


Note:

Sun Microsystems supplies an old JDK under /usr/bin.

9.1.4.2 Migrating Source Code from JDK 1.4 to JDK 1.3

Java does not support compiling Java code under JDK 1.4 and running it under JDK 1.3 (bug 2811379). If you try anyway, Java may throw one of the following error messages at runtime:

  • Unsupported major.minor version 48.0.

  • The major.minor version '48.0' is too recent for this tool to understand.

However, if you must generate class files using JDK 1.4 and run them using JDK 1.3, then you can use the following command to force a JDK 1.4 compiler to generate a class file that is compatible with JDK 1.3:

 % javac -target 1.3 hello.java 

9.1.4.3 Migrating Source Code from JDK 1.3 to JDK 1.4

When you upgrade from JDK 1.3 to JDK 1.4, put all classes into packages.

The JDK 1.4 specification explicitly prohibits a class within a package from invoking a class not within a package. For this reason, some Java source code that compiles in JDK 1.3 will not compile in JDK 1.4. This error is identified by the following compiler message:

 '.' expected import myClass

This message means that the Java compiler expects to find a package and class name and cannot parse a line that contains only a class name.

For details, see the Sun Microsystems compatibility document supplied with the JDK.

9.1.5 OC4J Demo Downloads

Oracle Application Server 10g (9.0.4) includes one demo per component. Additional demos are available for download from OTN at the following URL:

http://otn.oracle.com/tech/java/oc4j/demos/

Drill down from this index page to the component areas that contain the additional demos that you need.

9.1.6 Warning Messages Displayed After Edit of OC4J Configuration Files

You may receive a warning message about an automatic restart in the Advanced Server Properties page after you edit the following OC4J configuration files:

  • server.xml

  • global-web-application.xml

  • jms.xml

  • rmi.xml

  • default-web-site.xml

OC4J is only restarted when the server.xml file is modified. The other OC4J configuration files do not trigger a restart.

Oracle recommends manually restarting the OC4J server every time the following OC4J configuration files are modified:

  • global-web-application.xml

  • jms.xml

  • rmi.xml

  • default-web-site.xml

9.1.7 OC4J Object Names Can Contain Only Single-byte Alphanumeric Characters

The following object names can contain only single-byte alphanumeric characters:

  • OC4J instance name

  • OC4J application name

  • OC4J island name

  • Farm name

  • OracleAS Cluster Name

9.1.8 Need to Restart OC4J After Resetting Application Server Passwords

If you use the Oracle Enterprise Manager to reset any user passwords, the new passwords will not be immediately picked up by OC4J. You should restart the server before attempting to log in as one of those users.

9.1.9 Oracle Application Server 10g Requires JDK 1.3.1.05 or Higher

Oracle Application Server 10g requires JDK 1.3.1.05 or higher. If an earlier version of JDK is used, OPMN constantly restarts OC4J after almost every application deployment.

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

This section describes issues for JavaServer Pages (JSP), tag libraries, and related demos. It includes the following topics:

9.2.1 Cannot Invoke Classes That Are Not in Packages

Among the considerations in migrating to a Sun Microsystems JDK 1.4 environment, shipped with Oracle Application Server 10g (9.0.4), one is particularly important to servlet and JSP developers.

Sun Microsystems states, "The compiler now rejects import statements that import a type from the unnamed namespace." This change addresses security concerns and ambiguities with previous JDK versions. This means that you cannot invoke a class (a method of a class) that is not within a package. Any attempt to do so results in a fatal error at compilation time.

This issue especially affects JSP developers who invoke JavaBeans from their JSP pages, because such beans are often outside any package (although the JSP 2.0 specification now requires beans to be within packages, to satisfy the new compiler requirements). When JavaBeans outside of packages are invoked, JSP applications that were built and executed in an OC4J 9.0.3 / JDK 1.3.1 environment no longer work in an OC4J 9.0.4 / JDK 1.4 environment.

Until you update your application so that all JavaBeans and other invoked classes are within packages, you can revert to a JDK 1.3.1 environment to avoid this issue.


Notes:

  • The javac -source compiler option allows JDK 1.3.1 code to be processed seamlessly by the JDK 1.4 compiler, but classes must still be in packages in order to be invoked.

  • Only the JDK 1.3.1 and JDK 1.4 compilers are supported and certified by OC4J. It is possible to specify an alternative compiler by adding a <java-compiler> element to the server.xml file. This might provide a workaround for the "classes not in packages" issue, but other compilers are not certified or supported by Oracle for use with OC4J. Furthermore, do not update the server.xml file directly in an Oracle Application Server environment. Use the Oracle Enterprise Manager.


This issue is also discussed in the following release note: Section 9.1.4.3, "Migrating Source Code from JDK 1.3 to JDK 1.4". For more information about the "classes not in packages" issue and other JDK 1.4 compatibility issues, refer to the following Web site:

http://java.sun.com/j2se/1.4/compatibility.html

Click the link "Incompatibilities Between Java 2 Platform, Standard Edition, v1.4.0 and v1.3".

9.2.2 Set the SAX Driver When Starting OC4J

For the filter functionality of JavaServer Pages Standard Tag Library (JSTL) XML tags to work in OC4J, you must set the SAX driver when starting OC4J.

When starting OC4J standalone, use the following option in the command line:

-Dorg.xml.sax.driver=oracle.xml.parser.v2.SAXParser 

When starting the Oracle Application Server, you can specify this setting through the system properties. See the Oracle Application Server documentation for details on where and how to make this specification.

If you do not set the property, then the JSTL demo Filter.jsp gives the following exception:

javax.servlet.jsp.JspException: System property org.xml.sax.driver not specified

9.2.3 JSP ojspc Issues

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

9.2.3.1 Debug Option Has No Effect on ojspc Output

The ojspc -debug option has no effect on ojspc output in Oracle Application Server 10g (9.0.4). If you specify -debug, the option is accepted but ignored.

9.2.3.2 The /WEB-INF/lib or /WEB-INF/classes Directories Should Not Contain .java Files

When using ojspc, do not put any.java files in or under the /WEB-INF/lib directory or the /WEB-INF/classes directory.

If the /WEB-INF/lib or /WEB-INF/classes directories contain any.java files, then ojspc occasionally creates one or more duplicate.class files at the top level of the archive during batch pretranslation.

9.2.4 JESI Tag Release Notes

This section describes changes and enhancements in the behavior of Java Edge Side Includes (JESI) tags in Oracle Application Server 10g (9.0.4). It includes the following topics:

9.2.4.1 JESI Tags No Longer Require Conditional Treatment

In prior versions of the JESI tag library, JESI tags always generated the same output regardless of whether the request was coming directly from a client, such as a browser, or from Oracle Web Cache. Therefore, in prior versions of the tag library, JESI tags required special conditional treatment if there was a possibility that the Oracle Web Cache might be down or unavailable at any time, because then the included pages and fragments would not have been inserted into the response.

In the OC4J 9.0.4 implementation, JESI tags correctly generate a full response, even without the presence of Oracle Web Cache, by falling back to the standard JSP "include" functionality for inclusion of fragments. For more information, see the Oracle Application Server Containers for J2EE JSP Tag Libraries and Utilities Reference.

9.2.4.2 JESI personalize Tag Now Adds Single Quotes

In the OC4J 9.0.4 implementation, the JESI personalize tag now puts single quotes around the string value of the default attribute (or, for backward compatibility, the value attribute). This behavior is more compliant with the ESI syntax. In versions prior to Oracle Application Server 10g (9.0.4), the user had to add single quotes as part of the attribute string value. You must edit pages containing personalize tags that used to work prior to the 9.0.4 implementation to remove extra single quotes.

9.2.4.3 A fragment Tag Can Be Inside an Included Page

You can now place a fragment tag inside a page included through a jsp:include standard action, if it is properly enclosed in a template tag (which can be in the including page).

9.2.4.4 Multiple control or template Tags Can Be Used

When OC4J encounters multiple control tags, instead of throwing an exception, it ignores additional control or template tags. OC4J executes only the first tag that it encounters. This feature allows placing control tags into JSP-included pages. If a page is included in another page with control or template tags of its own, then the second tag is ignored. At the same time, the included page can be executed independently.

The four permutations and their behavior are as follows:

  • A control tag followed by a control tag is acceptable. The second Control tag is ignored.

  • A control tag followed by a template tag is acceptable. The attributes of the template tag are ignored.

  • A template tag followed by a control tag is acceptable. The control tag is ignored.

  • A template tag followed by a template tag produces an error.

9.2.4.5 No Response Output Outside the Tags of a template Tag

In the OC4J 9.0.4 and the OC4J 9.0.3 implementations, there must be no response output outside the start and end tags of a template tag. Additionally, you can now place template tags in an included page, if there is no content output into the response outside the start and end tags.

9.2.4.6 Do Not Use Explicit ESI Markup With JESI Tags

The JESI tag library is not guaranteed to work correctly when explicit ESI markup is used together with JESI tags to generate an HTTP response.

9.2.5 Tag Library Descriptors Must Be Under WEB-INF

This release note warns developers to carefully observe the JSP specification with respect to tag library descriptors, despite leniency in previous OC4J implementations.

The existing specification allows tag library descriptors only under application_root/WEB-INF/ for a given application.

In practice, in the OC4J 9.0.4 implementation (and previous implementations), tag library descriptors have been accepted anywhere under application_root, despite the requirements of the specification.

In implementations under development, the specification is strictly enforced. Tag library descriptors are allowed only under WEB-INF.

This warning is provided so that you can make sure that code that you develop for this OC4J implementation does not have to be changed when you upgrade in the future.

9.2.6 Adding Tag Library JAR Files to /WEB-INF/lib While OC4J Is Running

If you are adding tag library JAR files to the /WEB-INF/lib directory while OC4J is running, then set tags_reuse_default to "none" or "compiletime" to avoid a ClassCastException.

9.2.7 Search Local Classes First

If you are using tag library JAR files at the application level that are intended to supersede JAR files in the well-known tag library location (global level), then you must set the application loader to search local classes first. You can do this through the following setting in your application's orion-web.xml file:

<web-app-class-loader search-local-classes-first="true" />

9.2.8 java.lang.ClassFormatError: (Truncated Class File)

A JSP error message such as the example shown below indicates a truncated class file.

Some conditions in which this can occur include the following:

  • You are using JSP in a portal environment.

  • The system is heavily loaded.

Use one of the following techniques to repair the error:

  • Touch the JSP file, causing the JSP to be recompiled.

  • Remove the corrupted class file, as indicated by the "/modules/location/bizdir/jsp/bizdir.jsp" listing in the error message example.

Truncated Class File Error Message Example

500 Internal Server Error
    OracleJSP:
    JSP Error:
--------------------------------------------------------------------------------
    Request URI:/modules/location/bizdir/jsp/bizdir.jsp
    Exception:
    java.lang.ClassFormatError: _location/_bizdir/_jsp/_bizdir (Truncated class file)
    at java.lang.ClassLoader.defineClass0(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:493)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
    at oracle.jsp.app.JspClassLoader.loadClass(JspClassLoader.java:682)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
   ...

9.2.9 Tag Library Descriptor Cache and Non-Root Relative Taglib Directive URI Attributes

The fallback mechanism with non-root relative taglib directive uri attributes are not supported correctly with the tldcache turned on (bug 3315924). For example:

<@taglib uri="../WEB-INF/foo.tld" ... %>

is a non-root relative uri attribute.

From the JSP 1.2 spec: JSP.7.3.2 TLD resource path

The fallback interpretation is targeted to a casual use of the mechanism, as in the development cycle of the Web Application; in that case the URI is interpreted as a direct path to the TLD (see Section JSP.7.3.6.2).

Workarounds:

  1. To get around this, you can turn off tldcaching by including in either global-web-application.xml or orion-web.xml the attribute jsp-cache-tlds="false" as below:

    <orion-web-app 
    jsp-cache-directory="./persistence" 
    jsp-cache-tlds="false" 
    ... 
    >
    
    
  2. Alternately, to leave the tldcache turned on for improved performance, you can create a map in your web.xml, for example:

    <taglib> 
      <taglib-uri>../WEB-INF/foo.tld</taglib-uri> 
      <taglib-location>/WEB-INF/foo.tld</taglib-location> 
    </taglib> 
    
    

Note that if you take the above approach, you will have to create a map for every subdirectory containing a jsp with non-root relative uri attribute, but you do not have to change your .jsps.

Another solution is to change your .jsps to use the root relative path in your jsp.

In general non-root-relative paths are not recommended for a production environment due to the problems associated with moving .jsps.

<@taglib uri="/WEB-INF/foo.tld" ... %> 

9.3 Release Notes for Servlets

This section describes release notes for servlets. It includes the following topics:

9.3.1 Cannot Invoke Classes Not in Packages

With JDK 1.4, you are not allowed to invoke a class if it is not in a package if you are calling it from a class that is not in a package. The JSP release notes, Section 9.2.1, "Cannot Invoke Classes That Are Not in Packages" describes this issue in detail.

9.3.2 Servlet Invocation by Class Name Is Available During Development

In OC4J, servlet invocation by class name is available as a convenience feature during development.

This feature is controlled through the http.webdir.enable system property or the servlet-webdir attribute of the <orion-web-app> element in either the global-web-application.xml file or the orion-web.xml file.

This feature is documented in the Oracle Application Server Containers for J2EE Servlet Developer's Guide.

In the OC4J 9.0.4 implementation, invocation by class name is enabled by default, through the default settings http.webdir.enable=true and servlet-webdir="/servlet/".

In a production environment, you must disable this feature by setting either http.webdir.enable=false or servlet-webdir="" (empty quotes).

9.3.3 Do Not Use Certain <orion-web-app> Attributes

In the OC4J 9.0.4 implementation, the <orion-web-app> attributes internationalize-resources and default-mime-type appear in the orion-web.dtd file. However, these attributes are not documented and are not recommended for use.

9.4 Release Notes for EJB

This section describes release notes for EJBs. It includes the following topics:

9.4.1 Client Requests Must Include a Port Number

When you are providing your URL on the client to access an EJB in the following form, you must always provide the port number.

 opmn:ormi://host:port:oc4j_inst/application 

If you do not provide the port number, then the oc4J_inst always defaults to the home instance. (bug 3234351)

9.4.2 MDB Transaction Timeout

The message-driven bean (MDB) transaction timeout, as defined in the transaction-timeout attribute in the orion-ejb-jar.xml file, is an optional parameter. This attribute controls the transaction timeout interval (in seconds) for any container-managed transactional MDB that uses Oracle Java Message Service (JMS). The default is one day (86,400 seconds). The MDB transaction-timeout attribute applies only to CMT MDBs that use Oracle JMS as the JMS provider. This attribute setting has no effect on BMT MDBs or any MDBs that use OC4J JMS. (bug 3079322)

  • JMS behavior with Oracle Application Server — If the transaction has not completed in this time frame, then the transaction is rolled back and the message is redelivered to the Destination object. After Oracle JMS attempts to redeliver the message (the default is five attempts), the message is moved to the exception queue. For more information, refer to the Oracle9i Application Developer's Guide—Advanced Queuing for Release 2 (9.2).

  • JMS behavior with OC4J — The transaction-timeout setting does not work for CMT MDBs that use OC4J JMS. The timeout is always one day and cannot be modified. When the timeout occurs, OC4J JMS redelivers the message indefinitely, until the delivery is successful. You cannot set a retry limit.

In addition, the global transaction-timeout attribute defined in the server.xml file does not have any effect on MDBs.

9.4.3 Create and Release JMS Connections for JMS in the MDB onMessage() Method

You must create and release the JMS connections for Oracle JMS in the MDB onMessage() method, and not in the ejbCreate() method. (bug 2967949)

9.4.4 Considerations When Modifying Your orion-ejb-jar.xml File

If, after deploying your application to OC4J, you modify the application's orion-ejb-jar.xml file using the Oracle Enterprise Manager GUI, then you must restart OC4J for these changes to be applied to your application.

If you deploy your application to a standalone OC4J, and you decide that you want to modify some elements in your application's orion-ejb-jar.xml file through a text editor, then you must repackage the application and redeploy it to the standalone OC4J without restarting. (bug 3001543)

9.4.5 Static Block in an EJB

During EJB deployment in OC4J, the Container loads the bean class to find out its methods and generate the EJB wrappers. Because the code in the static block is executed while the class is being loaded, the JNDI environment context is not yet set up. Even during runtime, the bean is in the "does not exist" stage. In this stage of the life cycle, the JNDI environment context is undefined, and the bean provider cannot rely on it to be available.

To make the context available, you should set up and cache the context either during the construction of the bean, in the ejbCreate() method, or in the setSessionContext() method.

9.4.6 OC4J Instances Terminating due to ping Timeout

Under some conditions, the OPMN process monitoring software in Oracle Application Server may lose contact with an OC4J process. This can occur because of unexpected delays in the heartbeat protocol used by OPMN and OC4J to verify the proper functioning of the OC4J instance.

If this problem occurs sporadically, you can try increasing the ping timeout parameters as described in the following instructions.

However, if this occurs regularly, due to a consistent resource shortage, then you must increase the available hardware resources to solve the problem.

The following conditions can cause this problem:

  • An overloaded host processor.

  • One or more computation-intensive applications running in the OC4J instance.

  • Deployment of applications with large numbers (hundreds) of EJBs. Full garbage collections of large heaps can cause the OC4J process to become less responsive during the garbage collection phase. Although this should not occur during normal usage, deployment of large applications with many EJBs in a memory-constrained environment can trigger this behavior.

You can configure the behavior of the "ping protocol" between OPMN and OC4J in the opmn.xml configuration file.

When OC4J exceeds the timeout intervals specified for the ping protocol, the process monitoring software decides that the OC4J process has stopped responding and, therefore, terminates the OC4J process.

If you suspect this behavior in an Oracle Application Server installation, then use the following steps to troubleshoot and work around:

  1. When OC4J instances are "mysteriously" terminating, first increase diagnostic logging to determine if ping failures are triggering the termination:

    1. Increase the OPMN logging level to 5 so that you can see the pings.

      In opmn/conf/opmn.xml, edit the following line:

            log-file path="$ORACLE_HOME/opmn/logs/ipm.log" level="5" ...
    
    
  2. Reload the daemon.

    opmn/bin/opmnctl reload
    
    
  3. Look in opmn/logs/ipm.log for the following line:

        Process Ping Failed:  OC4J~<instance name>~default_island~1 (opmnid)
    
    
    
  4. The line above indicates that the memory and CPU resources of the current host are probably not sufficient to perform the operation within the currently specified ping timeout interval (used by OPMN to determine OC4J "responsiveness").

    Change the settings as follows:

    1. Increase the timeout and interval.

      Example:

        <ping timeout="60" interval="60"/>"
        <data id="reverseping-failed-ping-limit" value="5" />
    
    
  5. Reload the daemon.

    opmn/bin/opmnctl reload
    
    
  6. Restart the appropriate OC4J instance.

  7. Repeat the top-level operation that caused the timeout failure.

9.4.7 Miscellaneous EJB Release Notes

The following are miscellaneous EJB release notes:

  • You cannot mark a Container-Managed Persistence (CMP) entity bean as read-only if it has a Container-Managed Relationships (CMR) relationship to another entity bean that is not read-only.

  • If you invoke any EJB from an application client outside the EJB container, then Java Authentication and Authorization Service (JAAS) is not supported for the EJB. However, if you call the EJB from a servlet within the OC4J instance, then JAAS is supported.

  • The container may call the EJBActivate() method multiple times when the bean is associated with several wrappers. (bug 3107168)

  • The JTA two-phase commit (2pc) function does not work with Oracle9i Release 2 (9.2). Instead, use Oracle Database version 9.2.0.4 or higher to enable the 2pc functionality. (bug 2668460)

  • Currently, inline SQL queries are not supported within the finder query string defined in the orion-ejb-jar.xml file. When modifying these queries, avoid inline SQL queries, such as:

    SELECT * FROM
      (SELECT * FROM TEST1) A,
        (SELECT * FROM TEST2) B WHERE A.ID =B.ID

9.5 Release Notes for OC4J Services

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

9.5.1 Release Notes for JNDI

This section describes release notes for the Java Naming and Directory Interface (JNDI). It includes the following topics:

9.5.1.1 JNDI Clustering: Values Bound From the Client Not Supported

JNDI clustering does not support clustering values bound from the client (for example, new InitialContext) unless both of the following conditions are met:

  • The client binds the value to JNDI using a lookup URL.

  • All of the servers are up.

9.5.1.2 Do Not Mix JDK Versions for IIOP Interactions

This section describes release notes for the Internet Inter-ORB Protocol (IIOP).

Do not mix JDK versions for IIOP interactions. If OC4J is communicating with other J2EE servers using the Internet Inter-ORB Protocol (IIOP), then all of the servers must use the same version of the JDK.

9.5.2 Release Notes for Java Object Cache (JOC)

This section describes release notes for the Java Object Cache (JOC). It features the following topic:

9.5.2.1 Use javacache.xml for JOC Configuration

The OC4J 9.0.4 implementation uses the file javacache.xml for JOC configuration. In previous versions of JOC, configuration was done through the file javacache.properties.


Note:

If you install both a 9.0.4 release and a pre-9.0.4 release on the same host, you must ensure that the javacache.xml discovery-port attribute and the javacache.properties discoveryAddress attribute are not configured to the same port. If they are, you must manually change the value of one or the other to a different port number, in the range of 7000 - 7099.

9.5.3 Release Notes for OC4J DataSources

This section describes release notes for OC4J DataSources. It includes the following topics:

9.5.3.1 Non-Emulated Data Source Requires a Java-Enabled Database

You must use a java-enabled database to run a non-emulated data source.

When using a non-emulated data-source and a non-java-enabled database, deploying any MDB application (AQJMS) generates an exception (thrown to OC4J stdout). If you switch to an emulated data-source, or a java-enabled database, deployment proceeds correctly.

9.5.3.2 OC4J Data Sources Create Twice the Number of Database Connections

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

For example, if you start OC4J with a data source that is configured with a value of 10 for <min-connnections>, when you look at the number of active connections in the database you would expect to see 10 open connections. Instead, however, you would see 20 open connections.

This behavior is corrected in release 9.0.4.2 plus the patch for bug 4226465.

9.6 Release Notes for OracleAS JAAS Provider

Be aware of the following notes when using the OracleAS JAAS Provider in release 9.0.4:

9.6.1 Using the 9.0.4 Oracle Internet Directory Server with OracleAS JAAS Provider

In the 9.0.4 Oracle Internet Directory implementation, Access Control List (ACL) is not set up properly for JAZNAdminGroup. To use the 9.0.4 Oracle Internet Directory implementation with the 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 -a -p oidport -h oidhost -D adminuser_dn -w password \
               -f filename.ldif
    

9.7 Documentation Errata

This section describes known errors in the OC4J documentation in Oracle Application Server 10g (9.0.4). It includes the following topics:

9.7.1 Oracle Application Server Containers for J2EE Servlet Developer's Guide Errata

The following note, which appears on page 6-6 of the 9.0.4 version of the Oracle Application Server Containers for J2EE Servlet Developer's Guide, is incorrect:

"Note: The OC4J JSP container does not currently support the persistence-path flag. It is for servlets only."

This flag actually is supported by the JSP container in the Oracle Application Server 10g (9.0.4) release.

9.7.2 Oracle Application Server Containers for J2EE Support for JavaServer Pages Developer's Guide Errata

The following item, which appears in the "Oracle HTTP Server and mod_oc4j" section in Chapter 2 of the Oracle Application Server Containers for J2EE Support for JavaServer Pages Developer's Guide, is incorrect:

"A mod_oc4j module can restart an OC4J instance automatically, if necessary."

In fact, OPMN, not mod_oc4j, restarts OC4J processes automatically when it detects that they are unavailable (for several reasons).

9.7.3 Oracle Application Server Containers for J2EE User's Guide Errata

The following information is missing in the Oracle Application Server Containers for J2EE User's Guide, Appendix A, "Additional Information". The section "Elements Contained Within <application-server> of the server.xml file" should include the following text describing the <metric-collector> element.

<metric-collector>

The <metric-collector> element specifies that OC4J sends a metric between 0 and 100, inclusive, to mod_oc4j so that mod_oc4j can make routing decisions to load-balance incoming requests to a list of available OC4J instances. The metric sent has a relative value only, where 0 means that the OC4J instance is very busy and 100 means that the OC4J instance is available (not busy). When configured for metric load balancing, mod_oc4j routes first to the OC4J instance with the greater value.

The metric sent from OC4J to mod_oc4j is used only when metric-based load balancing is specified for mod_oc4j and when OC4J runs in an Oracle Application Server environment.

If you specify metric-based load balancing in mod_oc4j and do not specify the <metric-collector> element in server.xml, then mod_oc4j expects OC4J to send metrics, but OC4J does not send metrics. In this case, mod_oc4j reports the following warning message:

No run time metrics for oc4j(opmnid=%s) in notification Oc4jSelectMethod is 
configured to use run time metrics, please make sure OC4J side is configured 
accordingly. Default to 50.

In this case, mod_oc4j uses the value 50 for each of the OC4J processes and continues.

Likewise, if you specify the <metric-collector> element in server.xml, but do not specify metric-based load balancing in mod_oc4j, then OC4J sends metrics but mod_oc4j is not configured to receive metrics. In this case, mod_oc4j ignores the metrics and uses whatever the configured method is for load balancing. Use Oc4jSelectMethod to specify the load balancing method. If no Oc4jSelectMethod is specified, then mod_oc4j uses the default, which is roundrobin.

The <metric-collector> element takes the following attribute: classname.

The classname attribute defines an interface for gathering and calculating a server-wide metric. Use oracle.oc4j.server.DMSMetricCollector for the classname attribute when using a DMS-noun-based metric collector. A DMSMetricCollector instance takes several parameters. Details for the values for these parameters are available in the Oracle HTTP Server Administrator's Guide.

For example:

<metric-collector classname="oracle.oc4j.server.DMSMetricCollector">
   <init-param>
     <param-name>
       dms-noun
     </param-name>
     <param-value>
       /oc4j/default/WEBs/processRequest.time
     </param-value>
   </init-param>
   <init-param>
     <param-name>
       history-proportion
     </param-name>
     <param-value>
       0.2
     </param-value>
   </init-param>
   <init-param>
     <param-name>
       debug
     </param-name>
     <param-value>
       false
     </param-value>
   </init-param>
</metric-collector>

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

9.7.4 Oracle Application Server Containers for J2EE Services Guide Errata

The following statement in the JNDI chapter of the Oracle Application Server Containers for J2EE Services Guide is incorrect:

"When JNDI clustering is enabled, you can bind a serializable value into an application context (via remote client, EJB, or servlet) on one server and read it on another server. You can also create and destroy subcontexts in this way."

In OC4J 10g (9.0.4), destroying subcontexts is not yet supported.

9.7.5 Login User Name Change for ssoInfo Demo

The name of the user used for authentication in the ssoInfo demo has been changed from "admin" to "adminuser". Using "admin" as the user name results in an authentication failure error.

9.7.6 Corrected JDBC Connect String for Third-Party Databases

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

The INCORRECT part of each 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;CreateDefaultPackage=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=gatewaydb"
                   inactivity-timeout="30" 
 /> 

9.7.7 SSL Configuration Correction

In the Oracle Application Server Containers for J2EE Security Guide, 10g (9.0.4), in Chapter 3, "Configuring and Deploying the JAAS Preovider", in the "Configuring the JAAS Provider to Use SSL with Oracle Internet Directory" section, the instruction to set the ldap.protocol property to ssl is incorrect.

To determine whether to communicate with Oracle Internet Directory over SSL, Oracle JAAS looks at the SSLOnly property in the $ORACLE_HOME/config/ias.properties file. This information is set in the ias.properties file when the middle tier is associated with the infrastructure either during installation or through the Oracle Enterprise Manager.

9.7.8 Do Not Specify the location Attribute for LDAP in jazn.xml or orion-application.xml

Three configuration examples provided in the Oracle Application Server Containers for J2EE Security Guide, 10g (9.0.4), Chapter 3, "Configuring and Deploying the JAAS Provider" contain unnecessary settings that should be removed.

In particular, the location attribute for ldap should not be set in the $ORACLE_HOME/j2ee/home/config/jazn.xml file or the orion-application.xml file.

JAAS reads the location property for the LDAP-based provider from $ORACLE_HOME/config/ias.properties . This information is set in the ias.properties file when the middle tier is associated with the infrastructure either during installation or through the Oracle Enterprise Manager.

For this reason, the location property is no longer needed in the jazn tag in the jazn.xml file or the orion-application.xml file.

Correct the following configuration examples provided in the Oracle Application Server Containers for J2EE Security Guide, 10g (9.0.4), Chapter 3, "Configuring and Deploying the JAAS Provider":

9.7.8.1 Correct the Configuration Examples in "Configuring the JAAS Provider to Use SSL ... "

Change the following code in both configuration examples in the "Configuring the JAAS Provider to Use SSL with Oracle Internet Directory" section:

Replace the following code:

< jazn provider="ldap" location="ldap://pixcn-sun.us.oracle.com:5000" > 

with:

<jazn provider="ldap"/>

9.7.8.2 Correct the Configuration Example in "Configuring Caching (LDAP-Based Provider Only)"

Change the configuration example at the end of the "Configuring Caching (LDAP-Based Provider Only)" section. Replace the following code:

< jazn provider="LDAP" location="ldap://example.com:389" >

with:

<jazn provider="ldap"/>


9.7.9 JDK14 Is Installed with Oracle Application Server 10g

The following statement in the Introduction chapter of the Oracle Application Server Containers for J2EE Services Guide is incorrect:

"For optimum performance, run OC4J with the JDK that is installed with Oracle Application Server Release 2, which is JDK 1.3.x. "

The correct statement is as follows:

"For optimum performance, run OC4J with the JDK that is installed with Oracle Application Server 10g, which is JDK 1.4.x. "