Release 2 (9.0.3) for Solaris Operating System (SPARC)
Part Number B10015-01
 Core |
Platform |
 Contents |
| Oracle9i Application Server Release Notes Release 2 (9.0.3) for Solaris Operating System (SPARC) Part Number B10015-01 |
|
This chapter discusses issues with Oracle9iAS Containers for J2EE (OC4J). It includes the following topics:
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:
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
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.
In the OJMS 1.0.2.2 implementation, durable Topic Subscribers with the same name are allowed if they are subscribed to different topics.
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:
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.
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.
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.)
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 |
SAXException or SAXParseException in error conditions.
In prior releases, error handlers throw an XMLParseException in error conditions.
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:
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.
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.
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:
YM prefix. The following DataDirect JAR files are distributed with Oracle9iAS:
YMbase.jar YMinformix.jar YMsqlserver.jar YMutil.jar YMdb2.jar YMsybase.jar
oracle. When you connect, use the correct sub-protocol. For example:
jdbc:oracle:db2://server1:1433
com.oracle.ias.
[oias].
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:
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):
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.
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).
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.
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).
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.
.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 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.
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.
sendMail tag, note the following issues:
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).
sendmail.attachment=none, no attachment is sent but no error message is output (bug 2474501).
(Watch for updates to the OC4J release notes on OTN for possible further issues with sendmail attachments.)
well_known_taglib_loc is used to set a non-default "well-known" tag library location.
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:
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:
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.
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.
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).
You can now set UTF-8 as the response character set.
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.
The default setting of the debug_mode JSP configuration parameter is false, for security reasons.
Previously, the default was true.
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).
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.
This bug has been fixed.
Previously, the user would receive the following error:
java.lang.IllegalStateException: Response has already been committed.
The Chinese GBK encoding is now accepted in a page directive (charset="GBK").
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.
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.
Bug 2143605--A client cannot use data sources to get connections. The client should use DriverManager to get the connections.
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.
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.
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:
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"/>
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.
The following release notes apply to RMI (Remote Method Invocation).
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.
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".
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):
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.)
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.)
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:
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.
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:
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.
Note the following 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:
HTTPSConnection, it should refer to HTTPClient instead.
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.
|
 Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|