|
Oracle9i Application Server Release Notes
Release 2 (9.0.3) for Solaris Operating System (SPARC) Part No. B10015-09 |
|
|
|
|
Oracle9i Application Server Release Notes
Release 2 (9.0.3) for Solaris Operating System (SPARC) Part No. B10015-09 |
|
|
|
|
This chapter discusses issues with Oracle9iAS Containers for J2EE (OC4J). It includes the following topics:
Section 7.1, "Release Notes for CTS Compatibility Flag and Migration Issues"
Section 7.3, "Release Notes for DataDirect Connect JDBC Driver"
Section 7.6, "Release Notes for JSP, Tag Libraries, and Related Demos"
Section 7.12, "Release Notes for Browsing Multibyte Directories"
Section 7.14, "Release Notes for J2EE Connector Architecture"
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.
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:
Oracle JMS
Oracle JDBC
Oracle XML parser for JAXP/XDK
The compliance behavior of OC4J is determined by the flag -Doracle.jdbc.J2EE13Compliant, 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:
-Doracle.jdbc.J2EE13Compliant=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
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:
JMSExpiration—In the OJMS 9.0.3 J2EE 1.3-compliant implementation, the JMSExpiration header value in a dequeued message is the sum of the JMS timestamp when the message was enqueued, and the time-to-live. This value is expressed in milliseconds from midnight, January 1, 1970 to the current Greenwich Mean Time. If a message never expires, the value is 0.
In the OJMS 1.0.2.2 implementation, the JMSExpiration header value in a dequeued message is the duration until expiration of the message, in milliseconds. If a message never expires, the value is -1.
JMSPriority—In the OJMS 9.0.3 J2EE 1.3-compliant implementation, 9 is the highest priority, 0 is the lowest priority, and 4 is the default priority.
In the OJMS 1.0.2.2 implementation, java.lang.Integer.MIN_VALUE is the highest priority, Integer.MAX_VALUE is the lowest priority, and 1 is the default priority.
Durable subscribers—In the OJMS 9.0.3 J2EE 1.3-compliant implementation, durable Topic Subscribers with the same name are not allowed under any circumstances.
In the OJMS 1.0.2.2 implementation, durable Topic Subscribers with the same name are allowed if they are subscribed to different topics.
Strongly typed JMS selectors—In accordance with the JMS 1.02b specification and J2EE 1.3 compliance requirements, the OJMS 9.0.3 implementation uses only a certain subset of SQL92 syntax for selector expression syntax, with the following mandated restrictions:
Selector expressions are strongly typed, meaning operators and operands in arithmetic comparisons must be of the same type. Automatic type conversions for the purpose of comparison, such as converting the string "1" to the integer 1, are prohibited.
String and boolean comparisons are restricted to "=", "<", and ">". Two strings are equal only if they contain the exact same sequence of characters.
The "!=" operator is disallowed.
The OJMS 1.0.2.2 implementation is not subject to these restrictions or to the limited subset of SQL92 syntax for selector expression syntax.
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:
Java types for NUMBER columns—In 9.0.3, the getObject() method of a result set (java.sql.ResultSet instance) returns a java.lang.Double value for a NUMBER column with precision, or a java.math.BigDecimal value for a NUMBER column without precision.
In prior releases, getObject() returns a BigDecimal value for any NUMBER column.
Metadata for NUMBER columns—In 9.0.3, the getColumnTypeName() method of a result set metadata object (java.sql.ResultSetMetaData instance) returns "FLOAT" for a NUMBER column with precision, or "NUMBER" for a NUMBER column without precision. The getColumnType() method returns java.sql.Types.FLOAT for a NUMBER column with precision, or Types.NUMBER for a NUMBER column without precision.
In prior releases, getColumnTypeName() returns "NUMBER" for any NUMBER column, and getColumnType() returns Types.NUMBER for any NUMBER column.
Java types for DATE and TIMESTAMP columns—In 9.0.3, the getObject() method of a result set returns a java.sql.Date value for a DATE column, and a java.sql.Timestamp value for a TIMESTAMP column.
In prior releases, getObject() returns a java.sql.Timestamp value for a DATE column. (TIMESTAMP columns were not supported.)
Exceptions for inappropriate SQL statements—In 9.0.3, if an executeQuery() call in a statement object contains anything but a SELECT statement (such as if it instead contains an INSERT or UPDATE statement), the JDBC driver properly throws an exception. Similarly, if an executeUpdate() call contains a SELECT statement, the driver properly throws an exception. (An UPDATE, INSERT, or DELETE statement is expected.)
In prior releases, these situations did not result in exceptions.
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:
getNamespaceURI() null return values—In 9.0.3, the getNamespaceURI() method returns 'null' if the namespace is not defined for an element or attribute.
In prior releases, the getNamespaceURI() method returns '""' in these circumstances.
getLocalName() null return values—In 9.0.3, the getLocalName() method returns 'null' if the element or attribute was created using a DOM level 1 API call to createElement() or createAttribute().
In prior releases, the getLocalName() method returns '""' in these circumstances.
getPrefix() null return values—In 9.0.3, the getPrefix() method returns 'null' if the element or attribute was created using a DOM level 1 API call to createElement() or createAttribute().
In prior releases, the getPrefix() method returns '""' in these circumstances.
|
Note: The getNamespaceURI(), getLocalName(), and getPrefix() methods exist with the above changes in the XMLElement and XMLAttr classes of the oracle.xml.parser.v2 package. |
SAX exceptions—In 9.0.3, registered error handlers throw a SAXException or SAXParseException in error conditions.
In prior releases, error handlers throw an XMLParseException in error conditions.
I/O exceptions—In 9.0.3, an IOException is thrown as is in I/O error conditions.
In prior releases, an IOException is wrapped in an XMLParseException.
This section describes issues for Java Message Service (JMS).
To use Oracle JMS, you must do one of the following:
If you have an RDBMS 9.0.1 release for your server, use RDBMS 9.0.1.4.
You must apply a server-side patch for Oracle JMS, which ships with Oracle9iAS Release 2 (9.0.3) and the OTN release of OC4J, to work with an RDBMS 9.2.0.1 database. This patch is documented as bug 2513629; see the Metalink Web site or contact Oracle support for more information. However, it is strongly recommended that users move to RDBMS 9.2.0.2 when it is available. Users do not need to apply any server-side database patches when running with RDBMS 9.2.0.2.
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.
This section contains release notes for 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:
The customized DataDirect driver JAR files use the YM prefix. The following DataDirect JAR files are distributed with Oracle9iAS:
YMbase.jar YMinformix.jar YMsqlserver.jar YMutil.jar YMdb2.jar YMsybase.jar
The URL sub-protocol prefix is oracle. When you connect, use the correct sub-protocol. For example:
jdbc:oracle:db2://server1:1433
The package names are com.oracle.ias.
The vendor message prefix is [oias].
The customized DataDirect driver is configured to run within the Oracle9iAS product. Attempting to use the customized DataDirect JDBC driver outside Oracle9iAS will yield the following exception:
java.sql.SQLException: [oias][... JDBC Driver]
This section includes issues with JDBC that are not reflected in the Oracle9iAS Release 2 (9.0.3) documentation.
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.
This section contains release notes for the JAXP/XDK XML Parser.
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.
The following release notes apply to OC4J JSP, JSP tag libraries, and related demo applications as of Oracle9iAS Release 2 (9.0.3).
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:
Replace < with <
Replace > with >
Replace & with &
Replace \" with "
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 =
{{"<", "<"},
{">", ">"},
{"&", "&"},
{"\"", """}};
/**
* 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
The following release notes apply to JavaServer Pages and the ojspc pre-translation utility (batch pre-translation only):
The default-charset attribute of the <orion-web-app> element in global-web-application.xml or orion-web.xml, documented in the Oracle9iAS Containers for J2EE Servlet Developer's Guide, is not yet supported by the OC4J JSP container in Oracle9iAS Release 2 (9.0.3). The default character set is ISO-8859-1. (The default-charset attribute is supported by the OC4J servlet container in 9.0.3, as documented.)
|
Note: In 9.0.2, functionality comparable to that of default-charset was possible for JSP pages through /WEB-INF/ojsp-global-include.xml, as documented in the OC4J 9.0.2 release note addendum. However, such support for a default character set is currently inoperative in 9.0.3 (bug 2585327). |
Beginning with Oracle9iAS Release 2 (9.0.3), the OC4J JSP container by default imports the following packages into any JSP page, in accordance with the JSP specification. No page directive import settings are required:
javax.servlet.* javax.servlet.http.* javax.servlet.jsp.*
In previous releases, the following packages were also imported by default:
java.io.* java.util.* java.lang.reflect.* java.beans.*
For backward compatibility, you can use the JSP extra_imports configuration parameter as a workaround. Alternatively, you can add desired imports through page directives or global includes. See the Oracle9iAS Containers for J2EE JavaServer Pages Developer’s Guide for information about these topics.
ojspc -output option: Note the following issues with the -output option.
If you use the -output option and specify a file that already exists, that file will be overwritten regardless of its file permissions, even if it is read-only (bug 2555684).
No error message is generated if you try to use the -output option without specifying an output file (bug 2555686).
ojspc -batchMask option: No error message is generated if you try to use the -batchMask option without specifying the additional file name extensions to pre-translate (bug 2555686).
When pre-translating files in a WAR file (or EAR) file, ojspc cannot find the WEB-INF directory if the WAR file is created such that WEB-INF is nested (bug 2542886). For example, consider an application whose root directory is /tmp/foo/package. If you create a WAR file while your current directory is the package directory, you would have WAR file entries such as the following, and there would be no problem:
a.jsp b.jsp c.jsp WEB-INF/
If, however, you create the WAR file while your current directory is foo, for example, you would have WAR file entries such as the following:
package/a.jsp package/b.jsp package/c.jsp package/WEB-INF/
In this case, there is a problem—ojspc would be unable to find WEB-INF after it extracts the WAR file. The only workaround is to recreate the WAR file so that WEB-INF is at the top level.
The ojspc utility cannot handle a JAR (or WAR or EAR) file that has JSP pages with different encodings. All pages in any given JAR file must currently use the same encoding (bug 2505205).
When given a JAR (or WAR or EAR) file as input, ojspc will produce an output JAR file even if there are no JSP pages to translate in the original JAR file, although the translator and compiler are never invoked (bug 2579898). As always, the original JAR file is overwritten, unless you use the -output option. The output JAR file will be identical to the original, aside from the timestamp.
When translating files in a WAR or EAR file, if there are already one or more .class files in the WEB-INF/classes directory (prior to any ojspc processing), ojspc has been known to occasionally create a duplicate of one (and only one) of these .class files (bug 2580021). The duplicate is placed at the top level of the output WAR or EAR file, but will not be found or executed. You can ignore or delete any such duplicate entry in the output WAR or EAR file. This duplication bug does not occur with any .class files that are created during ojspc processing.
The following release notes apply to JSP tag libraries and related demo applications:
The OC4J EJB tag library now supports local interfaces. This is not documented in the Oracle9iAS Containers for J2EE Tag Libraries and Utilities Reference, Release 2 (9.0.3).
The useHome and useBean tags have an optional attribute called local, which takes a value of either "true" or "false" (default). Use a "true" setting for local EJBs, and set up the local interface as you normally would. You can set the local attribute using a runtime expression, but remember that the attribute expects a string value, not an actual boolean value.
There is one restriction—if local="true" for a useBean tag, you cannot use scope="session" if the application is distributable.
The OC4J Web services tag library now supports document-style as well as RPC-style bindings. The Oracle9iAS Containers for J2EE Tag Libraries and Utilities Reference, Release 2 (9.0.3), still states that only RPC-style bindings are supported.
This mostly affects the part tag, which has a name attribute (required) and a value attribute. The value attribute, formerly required, is now optional—you would use it only for an RPC-style Web service. For a document-style Web service, you would use a tag body instead, to input an XML document, XML element, or whatever is expected for input of an XML node.
For a document-style Web service, the output response object will be of type XMLElement.
When using mail attachments with the OC4J sendMail tag, note the following issues:
If you set sendmail.attachment=server in the sendmail.properties file and try to send both a server-side attachment and a client-side attachment, no error message is output. (The sendMail tag, as documented, supports server-side attachments or client-side attachments, but not both for any single application.) The message is sent with the server-side attachment but without the client-side attachment (bug 2496367).
If you try to send an attachment when sendmail.attachment=none, no attachment is sent but no error message is output (bug 2474501).
You cannot attach a symbolic link file; this results in an empty file being sent (bug 2452451).
(Watch for updates to the OC4J release notes on OTN for possible further issues with sendmail attachments.)
Tag library event listeners do not currently work properly if the JSP configuration parameter well_known_taglib_loc is used to set a non-default "well-known" tag library location.
Personalization demos that are included in the OC4J JSP demo application ojspdemos do not work as deployed. They will output an error such as the following:
Error: Only java.io.Serializable, javax.ejb.EJBObject and javax.ejb.EJBHome instances can be bound to a session in a distributable web-application, not: oracle.dmt.op.re.reapi.rt.REProxyRT@1fe451 (class oracle.dmt.op.re.reapi.rt.REProxyRT)
The reason for this is that ojspdemos is declared to be distributable through a <distributable/> element in the application web.xml file, but the Oracle Personalization REAPI for Java, and therefore the Oracle9iAS Personalization tag library, cannot be used in a distributable application in Oracle9iAS Release 2 (9.0.3).
The suggested workaround is to make the ojspdemo instance not distributable by removing the <distributable/> element from the application web.xml file after deployment. Use the following steps, for example:
Make a copy of ojspdemos.jar with another name, such as nondistrib-demos.jar.
Extract WEB-INF/web.xml.
Edit web.xml to remove the <distributable/> element.
Repackage the JAR file.
Deploy a new application—nondistrib-demos, for example—using the new JAR file.
When using the JESI template tag, do not place any visible output content—such as text, HTML markup, new lines, or white space—before the template start-tag or after the end-tag; otherwise, the Web page will be assembled incorrectly by the Oracle Web Cache.
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.
JSP bug fixes for Oracle9iAS Release 2 (9.0.3) include the following:
Bug 2053895—MERGE FOR PORT SPECIFIC CHANGES TO HTTPDSCTL, JSERV.PROPERTIES.PROT (JServ)
Code was added to appropriately set SHLIB_PATH on HPUX and LIBPATH on AIX. (These are equivalent to LD_LIBRARY_PATH on Solaris.) Files httpdsctl and jserv.properties.prot now set the SHLIB_PATH and LIBPATH environment variables appropriately for the product line platforms.
Bug 2138334—DEFAULT CONTENT-TYPE IS TEXT/HTML, DOES NOT INCLUDE CHARSET
The default content type is as follows, which complies with the JSP specification:
text/html;charset=ISO-8859-1
Previously, the default was just text/html, without specification of a character set.
Bug 2186625—OJSPC DOES NOT KNOW TO TAKE A LINK PARAMETER
This bug has been fixed.
Previously, ojspc (particularly ojspc standalone) sometimes had problems accessing JSP files through symbolic links (such as when the link pointed to a file that was located in a non-writable directory).
Bug 2197462—NLS: CANNOT SET UTF-8 AS A RESPONSE CHARSET FOR UIX (CABO) APPLICATION
You can now set UTF-8 as the response character set.
Bug 2227940—FAILURE TO GC LARGE JSPS CAUSES OUTOFMEMORY (JServ)
The JSP configuration parameter external_resource_timeout has been added for the JServ environment. (This is similar to jsp-timeout in OC4J.) Enabling this parameter resolves a garbage collection issue with large numbers of big JSP pages, which caused the JVM running JServ to run out of memory.
Bug 2248478—DEBUG_MODE SHOULD BE SET TO FALSE BY DEFAULT
The default setting of the debug_mode JSP configuration parameter is false, for security reasons.
Previously, the default was true.
Bug 2310924—IMPLEMENT JSP-TIMEOUT FEATURE
The jsp-timeout feature has been implemented in OC4J, allowing you to specify an integer value, in seconds, after which any JSP page will be removed from memory if it has not been requested.
The jsp-timeout parameter is an attribute of the <orion-web-app> element in global-web-application.xml or orion-web.xml (as opposed to being one of the JSP configuration parameters, which are set through <init-param> settings in the <servlet> element for the front-end servlet of the JSP container).
Bug 2387109—ESI/JESI TAG PROCESSING BREAKS WITH REAL-WORLD JSP
This bug has been fixed in the JESI tag library by ensuring that an ESI Surrogate-Control header is sent for each page fragment.
Previously, JSP files with large amounts of template data would cause the buffer to be filled and auto-flushed before all Surrogate-Control headers were sent.
Bug 2405180—JSP:FORWARD INSIDE A TABLE RESULTS IN AN EXCEPTION
This bug has been fixed.
Previously, the user would receive the following error:
java.lang.IllegalStateException: Response has already been committed.
Bug 2453675—NLS: GBK IS NOT WORKING AS PAGE DIRECTIVE
The Chinese GBK encoding is now accepted in a page directive (charset="GBK").
Bug 2513959—NEGATIVE REFERENCE COUNT EXCEPTION IN OJSP'S CACHE TAGS
This bug in the Web Object Cache tag library has been fixed by changing usage patterns in the tag library code to work around the fact that a critical module was not thread-safe.
Previously, in high-stress situations, the user would likely see the following exception:
oracle.ias.cache.CacheException: An exception occurred in the method CacheAccess.getAttributes negative reference count
The following release notes apply to OC4J data sources.
The following release notes apply to Enterprise JavaBeans.
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.
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.
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.
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.
In Oracle9iAS Release 2 (9.0.3), OC4J creates an association table for one-to-many unidirectional relationships regardless of the setting of -DassociateUsingThirdTable.
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.
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.
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.
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.
The following assumes that the J2EE_HOME and ORACLE_HOME environment variables have been set.
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"/>
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.
You can use CosNaming only to retrieve EJB references. You cannot look up other resources
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.
You may encounter the following runtime error when running RMI-IIOP:
ERROR: unexpected exception: java.rmi.MarshalException: CORBA MARSHAL 1398079699 Maybe; nested exception is: org.omg.CORBA.MARSHAL: Unable to read value from underlying bridge : Referenced type of indirect type not marshaled! minor code: 1398079699 completed: Maybe
The likely cause is that the version of the Java 2, Standard Edition (J2SE) SDK used to run the client program is probably not the same version of the J2SE SDK that the J2EE server is using. Make sure that the same version of the J2SE SDK is being used for both.
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:
Pick a port number that is not being used by the OC4J process.
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"/>
Restart the OC4J process to initialize the new port numbers.
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
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.
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.
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.
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.
You must add the host and port attributes to the <rmi-server> element in the rmi.xml file. Choose the Advanced Properties section off the OC4J Instance page to modify the rmi.xml file.
You must add the following element and attributes in the default-web-site.xml file. Choose the Advanced Properties section off the OC4J Instance page to drill down to the default-web-site.xml file.
Add host and port to the <web-site> element.
Add load-on-startup="true" to the <web-app> element.
<web-app application=... name=... root=... load-on-startup="true" />
Provide the host and port that the client uses in its request in the <frontend> element. This informs the back-end servers about the load balancer. In the main body of the Web site element, add the following:
< frontend host="balancer-host" port="balancer-port" />
Replace balancer-host with the host name, and balancer-port with the port. This host and port make up the public host name for the site that the client accesses, so port 80 is a good suggestion.
The following release notes apply to the OC4J servlet container.
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".
If you have difficulty browsing multibyte directory names under OC4J using Internet Explorer, set the encoding option (select Encoding from the View menu) to the correct language and ensure there is no check mark next to the Auto-Select option.
The following release notes apply to JAZN, the Oracle JAAS implementation.
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.
Be aware of these issues regarding the JAZN product in Oracle9iAS Release 2 (9.0.3):
Entries in the file principals.xml should not have spaces in any user name or password. (However, as the 9.0.3 documentation notes, principals.xml is deprecated in 9.0.3 in favor of the JAZNUserManager class.)
The default jazn.xml file is the following:
ORACLE_HOME/j2ee/home/config/jazn.xml
(ORACLE_HOME/j2ee/home/jazn/config/jazn.xml is a private copy used by the Oracle Universal Installer.)
When there are multiple realms in the system, users should specify the default-realm setting in both the jazn.xml file and the application.xml file (in j2ee/home/config). This applies to both JAZN-XML and JAZN-LDAP.
For example, if you are using JAZN-XML and your default realm is jazn.com, your jazn.xml and application.xml files should each have an entry such as the following:
<jazn provider="XML" default-realm="jazn.com" location="./jazn-data.xml" />
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.
The following release notes apply to J2EE Connector Architecture.
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.
Release Notes for Oracle9iAS TopLink are available in the following locations:
The Oracle9iAS TopLink CD-ROM in the Oracle9iAS CD Pack
The Oracle9iAS 9.0.3 documentation on OTN at
http://otn.oracle.com/docs/products/ias/content.html
This section supplements Chapter 8 of the Oracle9iAS Containers for J2EE User's Guide.
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. |
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 7-1 LoginModule XML Tags in jazn-data.xml
| Tag | Defines |
|---|---|
| <control-flag> | Correlation to the Flag value in javax.security.auth.login.Configuration. The possible values are:
|
| <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. |
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>
This section describes known errors in the Oracle9iAS Release 2 (9.0.3) documentation.
This section describes errata in the Oracle9iAS Containers for J2EE Services Guide.
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>
Chapter 15 includes the following note describing the support that HTTPClient provides for the java.net.URL class:
If the java.net.URL framework is used, then set the java.protocol.handler.pkgs system property to select the HTTPSConnection package as a replacement for the JDK client, as follows:
java.protocol.handler=HTTPClient
There are two errors in this passage:
Where the passage refers to HTTPSConnection, it should refer to HTTPClient instead.
The property name is incorrect in the example. The example should be:
java.protocol.handler.pkgs=HTTPClient
This section describes errata in the Oracle9iAS Containers for J2EE JavaServer Pages Developer’s Guide.
Chapter 7, "JSP Translation and Deployment", in the section "JSP Translator Output File Locations", contains the following passages:
The JSP translator places generated output files under a base temp/_pages directory, as in the following example:
ORACLE_HOME/j2ee/home/app-deployment/app-name/web-app-name/temp/_pages/... ...
The path under the _pages directory depends on the path of the .jsp file under the application root directory.
As an example, consider the page welcome.jsp in the examples/jsp subdirectory under the OC4J standalone default Web application directory. The path would be as follows:
ORACLE_HOME/j2ee/home/default-web-app/examples/jsp/welcome.jsp
Assuming the default application deployment directory, the JSP translator would place the output files ( _welcome.java, _welcome.class, and _welcome$__jsp_StaticText.class for the page implementation class inner class) in the following directory:
ORACLE_HOME/j2ee/home/application-deployments/default/defaultWebApp/temp/_pages/_examples/_jsp
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
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.
This section describes errata in the Oracle9iAS Containers for J2EE Enterprise JavaBeans Developer’s Guide:
To activate two thread pools, you must configure all the attributes for the first thread pool, which include min, max, queue, and keepAlive. If any of these attributes is not configured, you cannot configure the second pool. Instead, you will receive the following error message:
Error initializing server: Invalid Thread Pool parameter: null
