| Oracle® Application Server Release Notes 10g Release 3 (10.1.3.2) for Solaris Operating System (SPARC 64-Bit) Part Number B32421-05 |
|
|
View PDF |
| Oracle® Application Server Release Notes 10g Release 3 (10.1.3.2) for Solaris Operating System (SPARC 64-Bit) Part Number B32421-05 |
|
|
View PDF |
This chapter discusses release notes for Oracle Containers for J2EE (OC4J) for 10.1.3.2.0. It includes the following topics:
Section 9.1, "Configuration, Deployment, and Administration Issues and Workarounds"
Section 9.3, "JavaServer Pages (JSP) Issues and Workarounds"
Section 9.7, "J2EE Connector Architecture (J2CA) Issues and Workarounds"
You can access Oracle manuals mentioned in this document at the following URL:
http://www.oracle.com/technology/index.html
This section describes configuration, deployment, and administration issues for Oracle Application Server Containers for J2EE (OC4J). This section covers the following topics:
Section 9.1.3, "Deprecated System Property ejb.batch.compile"
Section 9.1.5, "System Property for File Information Cache Size"
Section 9.1.7, "Allowed Format for Version Numbers in MANIFEST.MF File"
Section 9.1.8, "Having the AJP Listener Use the Loopback Interface Only"
Section 9.1.9, "Determining JVM, OC4J Instance, or Application Server Instance"
Section 9.1.10, "Invocation by Servlet Name without Mapping Is Disabled by Default"
Section 9.1.11, "Warning Regarding Maximum Concurrent Timers"
Section 9.1.13, "Starting OC4J Using JDK 1.4.2 for a Headless Console"
Section 9.1.14, "New Wait Option for Sequential Redeployment to a Cluster"
Section 9.1.19, "Using opmn Settings for OC4J home Instance As Template for New Instance"
Section 9.1.20, "How to Specify Ports for State Replication in OPMN"
Section 9.1.21, "OC4J Instances in a Group Must Have Same Version"
Section 9.1.22, "Same Destination for Trace Output from Two OC4J Instances Not Supported"
For information on configuring OC4J, see the Oracle Containers for J2EE Configuration and Administration Guide for OC4J at:
http://www.oracle.com/technology/index.html
OC4J ships the Tomcat examples by default. Many of the Tomcat examples do not conform to the Oracle Secure Coding Standards. Oracle recommends that you remove the Tomcat examples except when used in demonstration and testing environments.
System properties KeepWrapperCode, WrapperCodeDir, and DoNotReGenerateWrapperCode are deprecated.
These options apply only to EJB 2.1 CMP entity beans; they do not apply to session beans, message-driven beans, or EJB 3.0 entities. OC4J generates only one file per EJB 2.1 CMP entity bean. OC4J does not generate any artifacts if you use only EJB 3.0 entities. Because wrappers contain very little content, debugging them is not useful.
For more information, see "Debugging Generated Wrapper Code" in the Oracle Containers for J2EE Enterprise JavaBeans Developer's Guide.
System property ejb.batch.compile is deprecated.
To enable or disable batch compilation, use the orion-application.xml file <orion-application> element batch-compile attribute.
The following orion-ejb-jar.xml file attributes are desupported:
max-instances-per-pk
min-instances-per-pk
disable-wrapper-cache
instance-cache-timeout
locking-mode="old_pessimistic"
Note:
Do not use these attributes in this release. Doing so will lead to deployment failure.When a client accesses an application using path information, OC4J looks for files as applicable and stores related file information into a cache. Previously, OC4J did not free objects from this cache, resulting in memory loss.
There is now a system property, http.maxFileInfoCacheEntries, to control the cache, as follows:
http.maxFileInfoCacheEntries < 0 to never cache
http.maxFileInfoCacheEntries == 0 to not change the previous behavior
http.maxFileInfoCacheEntries > 0 to set the maximum number of cached entries
The default value is 2000.
Specification of "/" for the context root when deploying an application to OC4J is supported now. This includes support by Application Server Control and admin_client.jar.
Background: The 10.1.3.1 release of the Oracle Containers for J2EE Configuration and Administration Guide states that "Specifying a root setting of "/" will override the OC4J default Web application. This setting or a null setting is not allowed by the admin_client.jar utility when binding a Web application to the Web site."
Now, however, a root setting of "/" is allowed. You can use this as the context root when deploying an application. The following example uses admin_client.jar to deploy a WAR file and bind to "/".
% java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 \ -deploy -file d:how-to-rolling-upgrade-web-v1.war -deploymentName h2ru_2 \ -bindAllWebApps -contextRoot "/"
Be aware that if an EAR file includes an application.xml file that has the context root set to "/", such as in the following example, then "/" will be the default context root when the application is deployed using either Application Server Control or admin_client.jar.
<application>
<display-name>How-To Rolling Upgrade</display-name>
<module>
<web>
<web-uri>how-to-rolling-upgrade-web.war</web-uri>
<context-root>/</context-root>
</web>
</module>
</application>
Note:
Because the default ping URL for Oracle HTTP Server is also "/", using "/" as the context root when you deploy an application may result in the following issues:
Pings intended for Oracle HTTP Server go directly to OC4J instead.
Extraneous HEAD requests appear in the *-web-access.log file.
You can avoid these issues by placing the following directive:
Oc4jMountCopy off
Into the following file:
ORACLE_HOME/Apache/Apache/conf/dms.conf
Previously, version numbers in the Specification-Version and Implementation-Version attributes of a MANIFEST.MF file were limited to five elements: n1.n2.n3.n4.n5. (OC4J would not start if there were more than five elements in a Specification-Version or Implementation-Version value.)
Now, version numbers of up to eight elements are allowed: n1.n2.n3.n4.n5.n6.n7.n8.
The maximum allowed value for an element is 99999999.
There may be situations where you are concerned about AJP security but do not need to run AJP over a network (such as when OC4J and Oracle HTTP Server are on the same system) and would prefer not to configure AJP over SSL.
If you specify "127.0.0.1" as host in default-web-site.xml, as in the following example, the AJP listener will listen only on the "loopback interface". This allows you to use TCP/IP facilities without actually accessing any network hardware or drivers. The connection just loops back to localhost.
<web-site host="127.0.0.1" protocol="ajp13" port="..." ... > ... </web-site>
Developers, when debugging in a cluster, frequently need to determine what JVM, what application server instance (in a multi-instance cluster), or what OC4J instance they are running on within the cluster. This is useful for debugging as well as building management utilities on top of Oracle Application Server.
In Oracle Application Server 10.1.3.x, there are several properties that developers can access programmatically through System.getProperty() calls to obtain this kind of information. Specifically:
oracle.home: a string containing the physical directory in which Oracle Application Server is installed
oracle.oc4j.instancename: a string containing the name of the OC4J instance
oracle.ons.instancename: a string containing the name of the Oracle Application Server instance
oracle.ons.indexid: a string containing a combination of the OC4J instance name, the group it belongs to, and the JVM executing it, in the following format:
oc4j_instance_name.oc4j_groupname.jvm_number
For example: java_ee1.javaee_group.2
In a Java process running on OC4J you could print this information to the system console as follows:
System.out.println("Oracle home name: " + System.getProperty("oracle.home"));
System.out.println("OC4J Instance name: " +
System.getProperty("oracle.oc4j.instancename"));
System.out.println("AS Instance name: " +
System.getProperty("oracle.ons.instancename"));
System.out.println("Instance:Group:JVM PID: " +
System.getProperty("oracle.ons.indexid"));
The 10.1.3.x Oracle Containers for J2EE Servlet Developer's Guide notes that by default, servlet invocation by class name is now disabled, but can be enabled through the property setting -Dhttp.webdir.enable=true. (Servlet invocation by class name was enabled by default in versions 10.1.2.x and prior.)
What is similar, but undocumented, is that this also applies to invoking a servlet through its <servlet-name> value when there is no corresponding <servlet-mapping> entry. Invoking a servlet through its servlet name in this way was enabled by default in 10.1.2.x and prior, but requires the setting -Dhttp.webdir.enable=true in 10.1.3.x versions.
For example, consider the following web.xml entry, with no corresponding <servlet-mapping> entry:
<servlet>
<servlet-name>TestIt</servlet-name>
<servlet-class>mypackage.TestIt</servlet-class>
</servlet>
In 10.1.2.x, you could access this servlet using /servlet/TestIt without any property setting. In 10.1.3.x, you must set -Dhttp.webdir.enable=true to access the servlet in this way with the given configuration.
This release note provides background information and workarounds for warnings, such as the following examples, that occur when the number of concurrent timers exceeds the maximum.
WARNING J2EE OJR-10002 The number of concurrent Timers has reached the maximum limit
By default in 10.1.3.1 and 10.1.3.2, OC4J allows only eight concurrent timers. (A timer can be triggered through an EJB timer, the timer service, or the scheduler.) This limit is low by default because we expect each timer to be of short duration. When the number of timers is at the limit, such as if timers are running longer for any reason, timers are no longer executed; when a new timer occurs, you will see the warning messages. There are two OC4J flags you can use in this circumstance:
timer.service.debug: Determines whether to output additional diagnostic information for the timer service, including information about the current number of running timers. For example: -Dtimer.service.debug=true
executor.concurrent.tasks: Specifies the number of concurrent tasks for the Executor Service. Through this flag you can increase the maximum number of concurrent timers allowed by OC4J. For example: -Dexecutor.concurrent.tasks=12
Note:
Each timer executes in a separate thread. If the maximum is set too high, resulting in numerous timers executing, then many threads will be used. It is advisable to recycle threads once they finish executing.By default, OC4J now ships with the http.file.allowAlias property set to false. This setting prevents the use of symbolic links. Oracle strongly recommends that this setting not be changed to true, which might allow JSP source code to be visible to end users in some circumstances.
Instead of changing the property setting, you can use one of the following workarounds:
Temporarily switch from using the OC4J lightweight HTTP listener to front ending the OC4J application through Oracle HTTP Server, so that browsers access the pages indirectly through MOD_OC4J and Apache JServ Protocol (AJP), rather than directly through HTTP.
Replace all symbolic links in an application with the names of the real files they represent.
You can use a shell script to automate the replacement of symbolic links. For example:
#!/bin/ksh
PROGNAME="${0##*/}"
LN_EXTN="ln"
function displaySyntax
{
echo "${PROGNAME}! SYNTAX: ${PROGNAME} <some_dir_path>"
exit 1
}
if [[ $# < 0 ]]
then
displaySyntax
fi
DIR="$1"
if [[ ! -d ${DIR}
then
displaySyntax
fi
find ${DIR} -type l|while read filepath
do
echo "FIXING: ${filepath} (=> ${filepath}.${LN_EXTN})"
mv ${filepath} ${filepath}.${LN_EXTN}
cp -L ${filepath}.${LN_EXTN} ${filepath}
done
This example KSH script would be invoked on Unix as follows:
$ fixLinks <web_module_root>
The script will recurse through any directory and, for any file it finds that is a symbolic link, will rename each link with an additional .ln extension and then place a copy of the link target in the original location where the link was found.
For a headless console, the -Djava.awt.headless=true parameter is necessary for starting OC4J using JDK 1.4.2 in an Oracle Application Server 10.1.3.1 or later 10.1.3.x release.
If you are using JDK 1.5, the default JDK for 10.1.3.x releases, you do not need this option to start OC4J applications from headless consoles.
Here is a sample opmn.xml section for an OC4J component with -Djava.awt.headless=true added:
<ias-component id="default_group"> <process-type id="home" module-id="OC4J" status="enabled"> <module-data> <category id="start-parameters"> <data id="java-options" value="-server -Dcom.sun.management.jmxremote -Djava.security.policy=$ORACLE_HOME/j2ee/home/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false"/> </category> <category id="stop-parameters"> <data id="java-options" value="-Djava.security.policy=$ORACLE_HOME/j2ee/home/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false"/> </category> </module-data>
The Oracle Containers for J2EE Configuration and Administration Guide, Version 10.1.3.1, describes the java.awt.headless system property under "Overview of General System Properties" in Chapter 4, "OC4J Runtime Configuration."
When an application is deployed to a group using the sequential option, the deployment operation is serialized, with deployment done to one OC4J instance at a time so that the target application is never entirely in a stopped state. In a sequential deployment, the deployment manager immediately commences deployment on the next instance as soon as the deployment operation completes on the current instance. The result is that the system may not be able to stabilize itself so that the new application is fully active before the next deployment commences, which introduces the following possible side effects:
The application can become inaccessible while it is stopped on one instance and before mod_oc4j is notified that the application is available on another instance.
Session replication activities may not have had an opportunity to execute.
In some circumstances the session state of an application may be lost when you redeploy an application to a cluster using the admin_client.jar command or the redeploy Ant task, even if you specify the sequential and keepsettings options.
In Oracle Containers for J2EE release 10.1.3.2 or 10.1.3.1, you can use either the waitsec parameter of the admin_client.jar -sequential waitsec subswitch or the sequentialDelay property of the redeploy Ant task to specify a number of seconds between redeployments to different OC4J instances in a cluster. This delay can provide enough time for replication of session state.
With the introduction of the optional waitsec or sequentialDelay value, the deployment manager will wait for the prescribed period between deployment operations on OC4J instances within a group. This delay enhances the ability of administrators to perform a group redeployment operation that enables the system to stabilize as redeployment operations occur across a group, reducing the opportunities for applications to be inaccessible or session state to be lost.
The new syntax of the admin_client.jar command for redeployment to a cluster follows:
java -jar admin_client.jar uri adminId adminPassword -redeploy -file path/filename -deploymentName appName [-keepSettings] [-sequential [waitsec -removeArchive
For example, the following admin_client.jar command specifies a wait time of 15 seconds between redeployments to different OC4J instances:
java -jar admin_client.jar deployer:cluster:opmn://host:port/home oc4jadmin password -redeploy -file "myapp.ear" -deploymentName rolling -sequential 15 -keepsettings
The new waitsec parameter also applies to the -sequential subswitch of the admin_client.jar deploy command.
An example of the redeploy Ant task with the new sequentialDelayproperty follows:
<oracle:redeploy
deployerUri="${deployer.uri}"
userid="${oc4j.admin.user}"
password="${oc4j.admin.password}"
file="${lib.dir}/${app.name}.archiveType"
deploymentName="${app.name}"
keepsettings="true"
sequential="true"
sequentialDelay="15"
logfile="${log.dir}/deploy-ear.log"/>
The new sequentialDelay option also applies to the deploy Ant task.
For more information on the admin_client.jar command or on the redeploy or deploy Ant task, see the Oracle Containers for J2EE Deployment Guide.
If you redeploy an application with scheduled jobs, the scheduled jobs will not run after the application is redeployed.
When redeploying an application with scheduled jobs, you should:
Remove all scheduled jobs.
Redeploy the application.
Resubmit all the jobs.
The Oracle Notification Service (ONS) that is included with the Oracle Application Server 10.1.3.x releases is incompatible with the ONS version included with the Database 10.1.0.x releases. The following error is received when the two versions attempt a connection:
invalid connect server IP format ... Terminating connection ...
The incompatibility causes RAC features, such as Fast Connection Failover, to fail. The workaround is to install the 10.1.0.6 patch set for the Oracle Database Server. The patch set includes an updated ONS. The patch can be downloaded from https://metalink.oracle.com.
You can use the OC4J Administrative Client Utility for incorporating Ant tasks using Ant 1.6.5 outside OC4J. Oracle Containers for J2EE Deployment Guide describes how to incorporate Ant tasks outside OC4J without the Administrative Client Utility in Chapter 10, "Using OC4J Ant Tasks for Deployment," available from the Oracle Technology Network at
http://download.oracle.com/docs/cd/B31017_01/web.1013/b28951/anttasks.htm#CHDGHFIE
The Administrative Client Utility enables you to use OC4J Ant tasks for configuration and deployment.
To incorporate Ant tasks using Ant 1.6.5 Outside OC4J with the OC4J Administrative Client Utility:
Download the oc4j_admin_client_ release_number.zip file from the Oracle Technology Network at
http://www.oracle.com/technology/software/products/ias/htdocs/utilsoft.html
For information about the Administrative Client Utility and how to use it, see "Downloading and Extracting the Remote Administration Client" in Oracle Containers for J2EE Configuration and Administration Guide, Chapter 6, "Using the admin_client.jar Utility," available from the Oracle Technology Network at
http://download.oracle.com/docs/cd/B31017_01/web.1013/b28950/adminclient.htm#CHDBEBHD
Extract the contents of oc4j_admin_client_ release_number.zip into a local directory of your choice, such as oc4j_admin_client.
Copy the ORACLE_HOME/ant/lib/ant-oracle.jar file from your Oracle Application Server 10g Release 3 (10.1.3.2) home directory to OC4J_ADMIN_CLIENT_DIR\ant\lib, in the local directory to which you extracted the contents of oc4j_admin_client_ release_number.
Set the ORACLE_HOME environment variable to the OC4J_ADMIN_CLIENT_DIR directory.
Add ANT_HOME/ant/bin to the system PATH environment variable.
Set the ANT_HOME environment variable to point to your Ant installation and the JAVA_HOME environment variable to point to the location of the Java 2 Standard Edition SDK.
The common ANT installation directory is ORACLE_HOME/ant.
Declare the oracle namespace in the <project> element in the Ant build file (build.xml).
<project name="test" default="all" basedir="." xmlns:oracle="antlib:oracle">
References to the OC4J Ant tasks in build.xml will use this namespace.
Copy the ant-oracle.properties file from the ORACLE_HOME/j2ee/utilities directory to the directory containing your build file (build.xml).
Although you can modify the file in ORACLE_HOME/j2ee/utilities and reference it from your build scripts, it is better to maintain the original file as a template.
Set the values for arguments to pass to the Ant tasks in the ant-oracle.properties file.
The properties within the file are set to the OC4J default values. The file also reads in environment variable settings, such as for ORACLE_HOME and JAVA_HOME. You can edit any of these properties as necessary to reflect the configuration of the target OC4J instance or instances.
Copy the ant-oracle.xml file from the ORACLE_HOME/j2ee/utilities directory to the directory containing your build file (build.xml).
At the top level of your build file, add this <import> element:
<import file="ant-oracle.xml"/>
For X.509 Certificate Authentication (X509Certificate), JAZN sets the mapping attribute for the Oracle Internet Directory (OID) provider to "DN" by default.
To change the default value, you can configure the value of the mapping.attribute property:
Locate the $Oracle_Home/j2ee/<oc4j_inst>/config/jazn.xml file.
Add the mapping.attribute property configuration to the <jazn> tag. For example:
<jazn provider... > ... <property name = "mapping.attribute" value="cn"/> ... </jazn>
Restart the OC4J instance.
Likewise, other login modules now rely on the mapping.attribute property in the jazn.xml file, including:
WS-Security Username token with no password (WSSLoginModule)
SAML (SAMLLoginModule)
SAMLLoginModule first looks at the SubjectNameIdentifier to determine the mapping. If blank, then the mapping.attribute is used.
X.509 client certificate authentication (X509LoginModule)
Third party login module (LDAPLoginModule)
The mapping attribute for these login modules must be set in the jazn.xml file as described here.
When you create an OC4J instance, a new <process-type> element containing the instance configuration is added to the opmn.xml configuration file. The <process-type> element for the OC4J home instance serves as a template for the new instance, which is created with the same settings as the home instance.You can change the configuration for the new instance by changing settings such as heapsize, numprocs, and timeout in the <process-type> element for the instance in the opmn.xml file. If you change the configuration for an OC4J instance, you need to restart it for the changes to take effect.
When you deploy an application utilizing state replication in a managed Oracle Application Server, OPMN dynamically allocates the ports that are used to propagate state across the cluster. You can restrict this allocation to a range of ports for an application that has peer-to-peer replication enabled. Specifying ports for state replication might be necessary in an installation with a firewall or network that uses a well-defined port range.
To specify a range of ports for peer-to-peer state replication
Add a <port> element to an OC4J instance configuration in the opmn.xml file.
Specify the name of an application that has peer-to-peer replication enabled as the value of the id attribute of the <port> element.
Specify a range of ports in the range attribute of the <port> element.
For example, for deployment of an application named rac-web that is set up for peer-to-peer replication, the line labeled <port id=rac-web .../> in the following OC4J instance configuration tells OPMN to use ports 15213 to 15214 for state replication:
<port id="default-web-site" range="80-100" protocol="http"/> <port id="rmi" range="12401-12500"/> <port id="rmis" range="12701-12800"/> <port id="jms" range="12601-12700"/> <port id="rac-web" range="15213-15214"/>
For more information about state replication, see Chapter 9, "Application Clustering in OC4J," in the Oracle Containers for J2EE Configuration and Administration Guide.
All OC4J instances in a group within an Oracle Application Server cluster must have the same version, such as 10.1.3.1.0. For more information about groups of OC4J instances, see Chapter 8, "Configuring and Managing Clusters and OC4J Groups," in Oracle Containers for J2EE Configuration and Administration Guide.
Through the oc4j.properties file, you can configure an OC4J instance to generate trace files to a specific debug destination instead of the default destination. Oracle does not support the configuration of two different OC4J instances to generate trace output to the same destination, even if the instances are in the same group. Each OC4J instance manages its own trace files.
For more information about default locations of component loggers for trace output, see Chapter 11, "Logging in OC4J", in Oracle Containers for J2EE Configuration and Administration Guide.
This section describes release notes for servlets. It covers the following topic(s):
Section 9.2.1, "Servlet Invocation by Classname Disabled by Default"
Section 9.2.2, "Enabling Access Logging for Web Applications"
Section 9.2.3, "OC4J 10.1.3.1.0 Honors Session id Value Differently"
Section 9.2.4, "Exception and Stack Trace No Longer Displayed in HTML Error Page"
In the 10.1.3.x implementation, servlet invocation by class name is not enabled by default. Therefore, in default mode, you must use standard servlet configuration in web.xml before a servlet can be invoked. For example:
<servlet>
<servlet-name>mytest</servlet-name>
<servlet-class>mypackage.MyTestClass</servlet-class>
</servlet>
...
<servlet-mapping>
<servlet-name>mytest</servlet-name>
<url-pattern>/servlet/mytest</url-pattern>
</servlet-mapping>
Without this configuration, attempts to invoke the servlet will result in a 404 NOT FOUND error. This differs from the default behavior in previous releases, where invocation by class name was enabled.
Alternatively, you can choose to enable invocation by class name when they start OC4J, by setting the http.webdir.enable property as follows:
-Dhttp.webdir.enable=true
In releases previous to 10.1.3.1.0, the default value of the access-log attribute of the <web-app> element of *-web-site.xml files was true. As of 10.1.3.1.0, the default value of access-log is false.
If you want to enable access logging, then set access-log to true in the appropriate <web-app> elements.
In 10.1.2.x, If SSL is enabled and a session cookie (a cookie with the name JSESSIONID) is present in the request from the browser, OC4J will honor the value from the cookie over the session id embedded in the SSL stream. In 10.1.3.x, the behavior is reversed, so that OC4J will attempt to honor the value from the SSL stream first.
In previous releases of OC4J, the default behavior when an error occurred in a Web application was to display both the exception and the stack trace in the HTML error page returned to the client.
This default behavior has changed and these details are no longer displayed by default; instead, a generic error message is displayed in the HTML error page. The exception and stack trace details are sent to the log file of the relevant application.
The previous behavior can be restored by setting the development attribute of the <orion-web-app> element to a value of "true" in the orion-web.xml file for the Web application, as in the following example:
<orion-web-app
jsp-cache-directory="./persistence"
jsp-cache-tlds="standard"
temporary-directory="./temp"
context-root="/myapp"
development="true">
...
</orion-web-app>
See the "Web Module Configuration Files" appendix in the Oracle Containers for J2EE Servlet Developer's Guide for more information about the development attribute.
In the global-web-application.xml file, you can force OC4J to not reload a specific servlet if the servlet is modified. This feature is enabled by setting the undocumented auto-reload attribute of the <servlet> element to false.
auto-reload="false">.
This parameter is not documented in the OC4J 10.1.3.x Servlet documentation.
The following example shows that this can be done for a single servlet.
In global-web-application.xml :
...
<servlet auto-reload="false">
<servlet-name>nlservlet</servlet-name>
<servlet-class>com.netledger.core.requesthandler.NLServlet
</servlet-class>
</servlet>
This section describes release notes for JavaServer Pages. It covers the following topic(s):
When you are running the JSP demos, if you receive a "Resource not found" exception when you attempt to view .jsp or .java files of the demo, then use the following workaround:
Add the following to the web.xml file located at j2ee/ojspdemos/applications/ojspdemos/ojspdemos-web/WEB-INF/web.xml.
<servlet-mapping>
<servlet-name>viewsrc</servlet-name>
<url-pattern>/servlet/ViewSrc/*</url-pattern>
</servlet-mapping>
Then, restart the OC4J server.
The following JSP configuration parameters of the <init-param> element of the global-web-application.xml and orion-web.xml files are deprecated in release 10.1.3.1.0.
external_resource
extra_imports
forgive_dup_dir_attr
old_include_from_top
setproperty_onerr_continue
jsp-print-null
In addition, Oracle plans to remove the following JSP configuration parameters of the <init-param> element of the global-web-application.xml and orion-web.xml files in a future release. These parameters are the only way to implement their behaviors in release 10.1.3.1.0. If you implement their behaviors, you will have to modify your code when you upgrade to a release where these parameters are removed.
xml_validate
no_tld_xml_validate
Oracle-proprietary ojsp tag libraries are deprecated in OC4J 10.1.3.x releases. They will be desupported in OC4J release 11g.
For efficiency in the production environment, the sample-web.war that is to be precompiled using ojspc should include the following declaration in its sample-web.war\WEB-INF\web.xml just after the <web-app> element:
<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>oracle.jsp.runtimev2.JspServlet</servlet-class>
<init-param>
<param-name>main_mode</param-name>
<param-value>justrun</param-value>
</init-param>
</servlet>
The settings of the main_mode parameter, including justrun, are described in Chapter 3, Configuring the OC4J JSP Environment, of the Oracle Containers for J2EE Support for JavaServer Pages Developer's Guide .
To use your own tag library with ojspc, the best method is to put your tag library under WEB-INF/lib in a WAR that contains a JSP page and then precompile the archive, which can be either a standalone WAR or an EAR that contains the WAR.
For example, mytaglib.war contains these files:
jsp/mytaglib_example.jspWEB-INF/web.xmlWEB-INF/orion-web.xmlWEB-INF/lib/mytaglib.jarThe mytaglib.jar file contains META-INF/mytaglib.tld as well as the class files for all tags declared in that tag library descriptor (mytaglib.tld).
In this example, the WAR (mytaglib.war) is inside an EAR file along with META-INF/application.xml.
The following ojspc command precompiles the EAR file:
ojspc -output out/mytaglib.ear mytaglib.ear
After the precompilation, the EAR file will be in out/mytaglib.ear and will contain a WAR file with the precompiled JSP page under WEB-INF/lib, __oracle_jsp_mytaglib_web.jar mytaglib.jar, as well as the original mytaglib.jar file.
You could deploy this EAR file to OC4, and if you set the <ojsp-init> attribute main-mode to the value justrun in the orion-web.xml deployment descriptor, the precompiled version in WEB-INF/lib will be used. Alternatively, you could set the main_mode parameter to justrun in an <init-param> element of the jsp servlet configuration for the OC4J instance in $J2EE_HOME/config/global-web-applications.xml.
This section describes release notes for EJBs. It covers the following topics:
In release 10.1.3.2.0, OC4J supports all but a small subset of the functionality specified in the final EJB 3.0 specification.
You may need to make code changes to your EJB 3.0 OC4J application when you upgrade your OC4J instance to 10.1.3.1.
For information on migrating a 10.1.3.0 JPA preview application to 10.1.3.1 JPA, see "Migrating a 10.1.3.0 TopLink JPA Preview Application to 10.1.3.1 TopLink Essentials JPA" in the Oracle Containers for J2EE Enterprise JavaBeans Developer's Guide.
Most EJB 3.0 session bean and message-driven bean features are supported with deployment descriptors with JDK 1.4. However, you cannot use EJB 3.0 interceptors in JDK 1.4. This is due to the fact that InvocationContext method getContextData() returns a JDK 1.5 generic type.
The EJB 3.0 specification states: "Propagation of persistence contexts only applies within a local environment. Persistence contexts are not propagated to remote tiers."
In a clustered OC4J environment, this means that an EJB 3.0 stateful session bean with a remote interface using an extended persistence context does not failover.
To work-around this limitation, you must configure your stateful session bean to use the ejbPassivate callback to null out any references to entities managed in the extended persistence context and then re-establish them in the ejbActivate callback.
The Orion persistence manager is deprecated. Oracle recommends that you use OC4J and the TopLink persistence manager for new development. Using the TopLink migration tool, you can migrate an existing OC4J application that uses EJB 2.0 entity beans with the Orion persistence manager to use EJB 2.0 entity beans with the TopLink persistence manager.
For more information, see "Migrating OC4J Orion Persistence to OC4J TopLink Persistence" in the Oracle TopLink Developer's Guide.
In this release, ejb-module attribute remote is deprecated in orion-ejb-jar.xml and orion-web.xml.
To access a remote EJB in an unclustered separate Web tier and EJB tier, use ejb-ref-mapping attributes remote-server-ref and jndi-properites-file.
For information, see "Configuring an Environment Reference to a Remote EJB: Unclustered Separate Web Tier and EJB Tier" in the Oracle Containers for J2EE Enterprise JavaBeans Developer's Guide
Due to a bug in JDK 1.5 (and below), you cannot bind a socket to an IPv6 address on RedHat 4 (Linux 2.6).
To work around this problem, OC4J uses IPv4 as its default IP address stack.
To override this default, set system property java.net.preferIPv4Stack=false.
When you configure an OC4J managed data source in data-sources.xml, you must set attribute manage-local-transactions to false if you plan to use the managed data source with Oracle JMS Connector (OJMS). This applies in both the queue and topic case.
The default algorithm that the managed data source uses to determine whether or not a connection may participate in a global transaction is inappropriate when using OJMS and may falsely prevent an MDB from joining a global transaction.
When this attribute is set to false, it allows OJMS and the underlying database management system to correctly determine the actual transaction status of a connection.
This section describes release notes for Web Services. It covers the following topics:
Note:
You can exercise your Web service and pinpoint errors by running it with a client created by WebServicesAssembler or JDeveloper. For more information on creating clients, see the Oracle Application Server Web Services Developer's Guide and the JDeveloper online help.This section describes problems that might arise as a result of incorrect configuration:
The Ant scripts used to install the WSIL-App component are sensitive to certain external configuration options. If Ant is not configured correctly, then the WSIL install might fail with a NoClassDefFound error.
When deploying the WSIL application using Ant, you must be sure that you are using the Ant distribution that is provided with OracleAS Web Services 10g. This release contains all of the Ant tasks needed for deployment.
For more information about the contents and functionality of the Ant distribution that is provided with OracleAS Web Services 10g, see the Oracle Containers for J2EE Deployment Guide.
This section describes problems that might arise in the operation of WebServicesAssembler.
Section 9.5.2.1, "Multiple Service Elements in Top Down Web Service Assembly"
Section 9.5.2.2, "Relative Path Names Are Not Supported in WSDL or XSD Imports"
WebServicesAssembler does not support multiple service elements for the topDownAssemble command.
WebServicesAssembler does not support relative path names, such as the following, in WSDL or XSD files.
<import location="../../file" ...>
As a work around use the WebServicesAssembler fetchWsdl command or the fetchWsdlImports argument. The fetchWsdl command is used in top down Web service assembly to copy the base (or top level) WSDL file and all of its imported and included WSDLs and schemas into a specified output directory. The boolean fetchWsdlImports argument indicates whether you want to make a local copy of the WSDL and everything it imports.
The schemaLocation attribute provides hints to a schema processor about where to find the schema for one or more namespaces. Values are provided as a list of URIs, separated by white-space characters. URIs must appear in pairs—first the namespace URI, then the location of the schema document for that namespace.
To process a schema successfully, WebServicesAssembler requires schema imports to be qualified by the schemaLocation attribute.
The following example specifies the schema location for the WS-I Basic Profile.
<xsd:import namespace="http://ws-i.org/profiles/basic/1.1/xsd" schemaLocation="http://ws-i.org/profiles/basic/1.1/xsd"/>
If you use the assemble Ant task to generate Web services from Java files that contain J2SE Annotations, then an exception will be raised. The assemble Ant task cannot correctly process annotated Java files.
To avoid this exception, use assemble on the command line.
This section describes problems that might arise in how OracleAS Web Services interprets WSDL files.
Section 9.5.3.1, "Support for Globalization Support (NLS) Characters in the WSDL"
Section 9.5.3.3, "genWsdl Command Does not Preserve Order of Variables"
Globalization Support (also known as" NLS" or "National Language Support") characters that occur in names in the WSDL, such as in the name of a service, port type, operation, binding or port, are not supported. This may also result in errors on the Web Services Test Page.
Multiple message formats, such as RPC-encoded and document-literal, are not supported in a single Web application.
To avoid this problem, ensure that your Web application defines only one message format.
If you use the WebServicesAssembler genWsdl command or Ant task, then the variables in the generated WSDL file will be in a different order from those in the original Java class files. This can cause problems if you continue to modify your Java code after generating the WSDL file. For example, clients may no longer be able to access the server's Web services.
To work around this problem:
Generate the WSDL file with genWSDL.
Edit the generated WSDL file to place the variables in the desired order.
If you are assembling the Web service bottom up, then replace the original WSDL file in the EAR/WAR file with the edited WSDL file.
This section describes Web Services schema features limitations. It covers the following topics:
If the schema contains a binding with an RPC-encoded message format and WebServicesAssembler encounters a complexType with attributes, then it will throw an "unsupported type encountered" error message.
If you are assembling Web services to- down or assembling Web service proxies, WebServicesAssembler cannot consume WSDLs that contain the xsd:choice or xsd:group XML types. If you want to consume a WSDL that contains these XML types, set the WebServicesAssembler dataBinding argument to false and code the SOAPElement so that the payload conforms to the schema definition in the WSDL file.
This section describes Web Services test page issues. It covers the following topics:
Section 9.5.5.1, "Recursive Schema Definitions Are Not Supported in the Web Services Test Page"
Section 9.5.5.3, "Test Page May Not Show Errors Originating from an Invalid Web Service WSDL"
Services that use recursive schema definitions are not fully supported from the Web Services Test Page. The HTML form in the Test Page allows you to add a recursive element, but when the message is sent, the recursive elements will be empty. An example of a recursive schema definition is shown below, where the element with the name of list has a reference back to itself:
<xs:element name="list"> <xs:complexType> <xs:sequence> <xs:element ref="list" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="value" type="xs:string"/> </xs:complexType> </xs:element>
If you wish to construct a message in the Test Page that contains a recursive element, then you must select the XML Source radio button and enter the contents of the message manually.
The returned content on the Formatted XML Test Page may be missing or display incorrectly if it includes a string containing XML entities for greater than (>) or less than (<) characters.
To check the content of the returned content, switch to the XML Source view.
If the Web Services Test Page invokes a service with an invalid WSDL, then you may see an empty or broken page. Neither the Test Page nor the logs will display any WSDL errors when such a service is invoked.
You can pinpoint WSDL errors in a Web service in any of the following ways:
Generate a service client with JDeveloper or with WebServicesAssembler.
Use the WSDL validation command in JDeveloper.
Use the WS-I validation tool in JDeveloper.
If you submit an invalid value in one of the Web Services Test Page's form fields, the field will be highlighted in red. If you submit the Test Page with an invalid value, then you may receive the following response:
Unable to get header stream in saveChanges
To avoid this error, correct invalid entries before submitting the page for execution.
If you include Globalization Support (also known as "NLS" or "National Language Support") characters in a user name or password for authentication in the Web Services Test Page, then authentication may fail with the following message:
Unable to authenticate <username>
In addition, the Test Page displays Globalization Support characters in the user name as "?" (question marks).
If the Web Services Test Page encounters any of the following schema features: group, choice, union, or derived simple type as an attribute, then the HTML form will not display input controls for them.
For example, if the schema contains the following code:
<xsd:element name="workflowContext" type="workflowContextType"/>
<xsd:complexType name="workflowContextType">
<xsd:choice>
<xsd:element name="credential" type="credentialType"/>
<xsd:element name="token" type="xsd:string"/>
</xsd:choice>
</xsd:complexType>
The HTML form will not display an input control for workflowContext.
As a work around, you can select the XML Source radio button and enter the message content manually.
If you run the Web services stress test from the Test Page in the Firefox or Mozilla browsers, then the report that is returned may not show correct aggregate values. To obtain the correct aggregate values, use the Internet Explorer browser instead.
This section describes problems that might arise during Web services deployment:
If an EJB 2.1 Web service is not available after you deploy it, then check whether the service deployment descriptor file, oracle-webservices.xml, is valid. It is possible to deploy a service with invalid resource references without an alert being sent.
This section describes other problems that might arise during the operation of OracleAS Web Services:
Section 9.5.7.1, "Get NodeLists by Using getFirstChild and getNextSibling Instead of getChildNode"
Section 9.5.7.3, "BEA Clients are Unable to Deserialize Responses from OC4J Web Services"
Section 9.5.7.4, "Mapping Issue with Simple Types (with Restrictions) on the .NET Platform"
Section 9.5.7.5, "genValueType Command Does Not Validate Restrictions"
You may see a performance degradation when iterating over a NodeList obtained by using node.getChildNode(). This degradation will only be significant for a NodeList with a very long length.
Instead of using the NodeList obtained by node.getChildNode(), the current Oracle XDK implementation offers an optimization of navigating a list of child nodes by using node.getFirstChild() and looping over node.getNextSibling(). The following code sample illustrates this technique.
Node n = ...;
if (n.hasChildNodes()) {
for(Node nd=n.getFirstChild(); nd!=null; nd=nd.getNextSibling()){
nd.getValue(); // do something with nd
}
}
If you edit a build.xml file that defines web service handlers in an Ant task, the handler code allows you to specify the handler class name using either the 'class' or 'handlerClass' attributes. However, if you use handlerClass to specify the class name in JDeveloper, the editor will display a red line under handlerClass and incorrectly indicate that it is not defined on the handler element. This occurs because the XML schema that is registered with JDeveloper does not recognize the handlerClass attribute.
To avoid this error, use the class attribute to specify the handler class name.
When OracleAS Web Services uses a soap encoded array of complex types, the element's xsi type is always set to the value of soapenc:Array (that is, xsi:type=soapenc:Array). OracleAS Web Services then uses the soap encoded arrayType to specify the actual type and length of the array (that is, soapenc:arrayType=<the Actual type>[length]).
In contrast, BEA 9.0 clients expect an element's xsi:type to reflect the actual type. If a BEA client receives a response from OracleAS We Services that contains a soap encoded array of complex types, then the client throws an error similar to the following:
internal error: no builtin runtime type for com.bea.staxb.buildtime.internal.bts.BuiltinBindingType
If interoperability with BEA and one or more of the following platforms: @ AXIS, IBM, or .NET are required, then avoid using soapenc arrays.
If you define an element of type simpleType with a restriction of xs:integer, it will be mapped to java.math.BigInteger on all Java platforms, such as OC4J, AXIS, and BEA.
For example, the element maxconcat in the following XML code sample will be mapped to BigInteger on all Java platforms:
<xs:element name="maxconcat" minOccurs="0" maxOccurs="1" type="aqltype:maxconcat"/>
com.bea.staxb.buildtime.internal.bts.BuiltinBindingType
<xs:simpleType name="maxconcat">
<xs:restriction base="xs:integer">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="255"/>
</xs:restriction>
</xs:simpleType>
However, all versions of the .NET platform (1.1, 2.0, and 3.0) map simpleType elements with a restriction of xs:integer to System.String. This can cause interoperability problems in the runtime if the value of this type is not an integer.
As a workaround, .NET developers should ensure that the string value passed for simpleType is an integer when this type is used in an outbound message.
In JAX-RPC Web services, the genValueType command generates bean classes for data types but does not validate restrictions in the XSD file.
For example, the following XSD fragment defines a SerialNumber data type based on string that restricts its length to 16 characters. When genValueType creates the bean classes, it does not validate the length.
...
xsd:element name="SerialNumber">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:length value="16"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>/
...
This is a known limitation: the Oracle Web Services JAX-RPC stack does not enforce most restrictions. To work around this problem, write your own bean classes instead of using generated bean classes.
If you attempt to expose a Java method that uses the array Java type as a Web service that uses the document-literal-bare (unwrapped) message format, then the serialization of the method will fail.
For example, assume that you want to expose the method public SearchResult[] WebServiceClass() which has the following definition:
public class SearchResult implements Serializable {
public SearchResult() { }
private String name;
private String value;
public void setName(String name) { this.name = name; }
public String getName() { return name; }
public void setValue(String value) { this.value = value; }
public String getValue() { return value; }
}
public SearchResult[] WebServiceClass(String testTriger) {
System.out.println(testTriger);
return STATIC_RESULT_A;
}
If you create the Web service bottom up, the WSDL file will contain the following XML for the SearchResult method:
...
<sequence>
<element name="result" type="tns:SearchResult" nillable="true" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
...
However, on executing the service, the following error will be returned:
ERROR OWS-04046 serialization error: java.lang.ClassCastException:
The work around for this issue is to use doc-literal-wrapped message format.
This section describes release notes for OC4J Services. OC4J Services include: Java Naming and Directory Interface (JNDI), Oracle Enterprise Messaging Service (OEMS), Data Sources, Remote Method Invocation (ORMI and IIOP), OC4J Transaction Support, Java Object Cache (JOC), XML Query Service (XQS), and Application Client Container.
The section contains release notes for the following OC4J Services:
This section describes release notes for JNDI. It covers the following topics:
In this release, when accessing an application through OPMN using ORMI, an application's name cannot contain spaces. For example:
opmn:ormi://<host>:<port>:home/my deploy
If the application name contains spaces, the following exception is thrown:
StrangeAppName not found
Remove any spaces in the name of the application to work around this issue.
In this release, when you deploy a client JAR to a clustered server, the jndi.properties file written to the /applications/appname/appname_client directory does not have the correct provider URL to connect to one of the clustered instances. The correct provider URL for accessing an application instance in a cluster is:
java.naming.provider.url=opmn:ormi://myhost:6003:home/appname
The example assumes the OPMN port is 6003 and the instance name is home.
In this release, the JNDI environment variables dedicated.connection, dedicated.rmicontext, and LoadBalanceOnLookup are deprecated.
To configure replication-based load balancing, use environment variable oracle.j2ee.rmi.loadBalance with the settings that Table 9-1 lists.
Table 9-1 Settings for Environment Variable oracle.j2ee.rmi.loadBalance
| Setting | Description |
|---|---|
|
|
The client interacts with the OC4J process that was initially chosen at the first lookup for the entire conversation (Default) |
|
|
The client goes to a new server when a separate context is used (similar to deprecated |
|
|
The client goes to a new server for every lookup. |
The java.naming.provider.url JNDI property does not support the value localhost when a remote client connects to an application server instance that is managed by OPMN. The value must be the complete hostname or IP Address. This does not affect clients that connect to standalone application server instances.
This section describes release notes for the Oracle Enterprise Messaging Service (OEMS). It covers the following topics:
Section 9.6.2.1, "Error Starting OC4J after OracleASjms is Undeployed"
Section 9.6.2.2, "OC4J May Fail to Restart after Abnormal OC4J Shutdown"
Section 9.6.2.3, "XA-styled JMS Connections Not Supported Between OC4J Versions"
Section 9.6.2.4, "JMS Auto-Enlisting in Global Transactions is Desupported"
Section 9.6.2.5, "Changes in JMS Client Properties Require Restart"
Section 9.6.2.7, "Poor Performance When Persisting Messages to a Database"
In this release, additional changes are necessary to start OC4J when the default instance of the OracleASjms resource adapter is undeployed.
The following additional changes must be made:
In $J2EE_HOME/config/application.xml comment out the following lines:
<web-module id="jmsrouter_web" path="../../home/applications/jmsrouter.war" /> <ejb-module id="jmsrouter_ejb" path="../../home/applications/jmsrouter-ejb.jar" />
In $J2EE_HOME/config/default-web-site.xml, comment out the following line:
<web-app application="default" name="jmsrouter_web" root="/jmsrouter" load-on-startup="true" />
If these changes are made, OC4J may be started, but the OracleAS JMS Router will not work.
To reinstate the JMS Router:
Fully redeploy the OracleASjms resource adapter instance.
Uncomment the lines mentioned above in $J2EE_HOME/config/application.xml and $J2EE_HOME/config/default-web-site.xml.
When OC4J is restarted, the OracleAS JMS Router should be available.
There are situations where you may encounter OC4J JMS Server startup problems, such as the following, after an abnormal OC4J shutdown:
(SEVERE) Failed to set the internal configuration of the OC4J JMS Server with: XMLJMSServerConfig[file:/D:/oas0104_web/j2ee/BLUE/config/jms.xml] WARNING: Application.setConfig Application: default is in failed state as initialization failed.
If this occurs, check that no other OC4J JMS Server is running and using the same persistence files. Then remove any .lock files from the following directory:
ORACLE_HOME/j2ee/instance_name/persistence
And try restarting again.
If problems persist, confirm that the jms.xml file is valid.
If problems still persist, remove the jms.state file from the persistence directory and try again, but be aware that removing this file may result in loss of transaction information. For additional information, see the section "Abnormal Termination" in the "Oracle Enterprise Messaging Service" chapter of the Oracle Containers for J2EE Services Guide.
In this release, Oracle Application Server does not support XA-styled JMS connections with Oracle Application Server 10.1.2.
For backward-compatibility reasons, it is still possible (but discouraged) to use the auto-enlisting feature in this release. The feature is disabled by default. Applications that previously relied on the auto-enlist feature to enlist XA and non-XA JMS connection into a global transaction, must now set the oc4j.jms.pseudoTransactionEnlistment configuration property to true in the jms.xml configuration file.
The OC4J server must be restarted when changes are made to the following JMS client properties:
oc4j.jms.serverPoll
oc4j.jms.messagePoll
oc4j.jms.noDms
The server must be restarted for the changes to take effect no matter what method is used to update the properties (either manually editing jms.xml or using the Application Server Control Console).
The 10.1.3.2 release includes an early-access version of a new, high-performance, fully CTS-compliant JMS provider. Use the following system property when starting OC4J to enable the new JMS provider (overriding the default OC4J-JMS provider):
-Doc4j.jms.implementation=oracle.j2ee.jms
The -Doc4j.jms.implementation=oc4j.j2ee.jms system property is also supported but has been deprecated.
Note:
The new JMS provider is configured by editing theJ2EE_HOME\config\jms.xml file. Configuration using the Enterprise Manager Application Server Control console is not supported.The OEMS database persistence feature performs poorly if the queue tables are configured to use old compatibility modes. The compatibility mode is set using the compatible parameter. For example:
DBMS_AQADM.CREATE_QUEUE_TABLE(
Queue_table => 'demoTestQTab',
Queue_payload_type => 'SYS.AQ$_JMS_MESSAGE',
sort_list => 'PRIORITY,ENQ_TIME',
multiple_consumers => false,
compatible => '8.1.5');
The compatible parameter should only be set to older modes if there are issues migrating to the new schema layouts or if existing queue tables cannot be exported to the new schema layouts.
When using the latest schema layouts, set the compatible parameter to 10.0.0.0.0 or omit the parameter to use the default compatibility mode. Either option ensures that the most efficient schema and locking mechanisms are used.
This section describes release notes for Data Sources. It covers the following topics:
The com.evermind.sql.DbUtil.oracleFatalError() method is no longer available for retrieving fatal errors (e.g. during RAC failover scenarios). The method has been replaced by the oracle.oc4j.sql.DataSourceUtils.isOracleFatalError() method. This is an internal method that is not intended for public use and should only be used for backwards compatibility. The method should not be used for new development.
The class oracle.jdbc.pool.OracleConnectionCacheImpl has been deprecated because it does not support multiple schemas. When defining the factory-class for connection factories and data-source-class for native data sources, use oracle.jdbc.pool.OracleDataSource.
Oracle CMP only works correctly with the default JDBC driver that is supplied with this release. Problems will arise if another version of the Oracle JDBC driver is added to an OC4J instance, such as through the OC4J Shared Library feature, and configured for use by the application using Orion CMP.
When using Orion CMP, always use the Oracle JDBC driver that is shipped with OC4J.
The JDBC THIN driver cannot be upgraded or changed at the Oracle Application Server-instance level due to component dependencies. JDBC THIN driver upgrades must be completed for each OC4J instance using the Shared Library feature.
Instructions for upgrading the JDBC THIN driver are located on the OTN How To site:
http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.html
This section describes release notes for OC4J Transaction Support. It covers the following topic:
The use of the in-database transaction coordinator by OC4J is deprecated as of release 10.1.3. Oracle recommends that the middle-tier transaction coordinator be used going forward.
The OC4J transaction manager contains a new feature called Recoverable Last Resource Commit (RLRC). The feature provides an enhanced recovery mechanism for Last Resource Commit (LRC) transactions and increases the overall performance of such transactions.
RLRC uses a database table to maintain a commit record of transaction IDs. This removes the need for a commit record in the OC4J transaction logs in the middle-tier. Writing commit records accounts for a large part of the performance cost of two-phase commit processing.
Note:
RLRC is currently only available when the non-XAResource participant is a database. In addition, because the commit record is maintained in this database, it is necessary that the database be accessible in the event that recovery of such RLRC transactions is necessary.To set up RLRC:
Stop the server if it is currently started.
Install the J2EE_HOME/database/j2ee/jta/oracle/last_resource_commit.sqland 2pc_jdbcstore.sql schemas on the database that will persist the commit record.
Open the J2EE_HOME/config/data-sources.xml file and edit or create a connection pool to access the commit record database and specify the commit-record-table-name attribute as part of the connection factory element. For example:
[…]
<connection-pool name="Example Connection Pool" num-cached-statements='10'>
<connection-factory factory-class="oracle.jdbc.pool.OracleDataSource"
user="scott"
password="tiger"
url="jdbc:oracle:thin:@myServer:5521:main"
commit-record-table-name="scott.OC4J_TX_RLRC_LOG">
<property name="connectionCachingEnabled" value="false"/>
<property name="implicitCachingEnabled" value="true"/>
<property name="maxStatements" value="50"/>
</connection-factory>
</connection-pool>
[…]
Note:
The name value for thecommit-record-table-name attribute must be fully qualified and the password specified must have delete and select privileges on this table.(Optional). Open the J2EE_HOME/config/transaction-manager.xml file and modify the runtime behavior of the RLRC feature. For example:
[...]
<commit-coordinator>
<middle-tier>
<recovery retry-interval = "300" rlrc-purge-interval="10"
rlrc-purge-size="1000">
</middle-tier>
</commit-coordinator>
[...]
]
rlrc-purge-interval: This attribute is the interval (in seconds) in which the batch purge of commit records in the database occurs
rlrc-purge-size: This attribute is the size of the batch that is deleted during the batch purge of commit records in the database.
Start the server.
New feature extensions to the standard TransactionManager interface have been added to the OC4JTransactionManager interface. These features are also available when using the OC4JJtaTransactionManager integration within the Spring framework (http://www.springframework.org).
The oracle.j2ee.transaction.TransactionUtility singleton provides direct access to the OC4JUserTransaction, OC4JTransactionManager, and OC4JTransaction interfaces. The singleton accesses these interfaces without the need for JNDI lookups using it's getOC4JUserTransaction(), getOC4JTransactionManager(), and getOC4JTransaction() methods.
The OC4JTransactionManager interface now includes the following methods:
void begin(String type) throws javax.transaction.NotSupportedException, javax.transaction.SystemException;
public void setType(String type);
public String getType();
void setTransactionIsolation(int transactionIsolation);
int getTransactionIsolation();
int getTransactionTimeout();
The OC4JTransaction interface now includes the following methods:
public void setType(String type);
public String getType();
void setTransactionIsolation(int transactionIsolation);
int getTransactionIsolation();
int getTransactionTimeout();
Transaction typing (or naming) allows for transactions to be categorized into logical groups for administration and reporting purposes.
Per- transaction isolation level designation provides the ability for all resources enlisted in a global transaction to share the same specified isolation-level. Currently, this feature is limited to JDBC connections.
This section describes release notes for OC4J Remote Method Invocation (RMI and IIOP). It covers the following topics:
In this release, note the following recommendations:
The RMI port is sometimes not released immediately.
Old tunneling is deprecated. Use the new URL format, as described in the "Configuring ORMI Tunneling through HTTP" section of the "RMI" chapter of the Oracle Containers for J2EE Services Guide.
In certain cases when there is something wrong with the provider URL format, the following incorrect error message is displayed:
" Provider URL must be of the form [opmn:]corbaname::host:port#/appname"
The URL format in the error message is incorrect. The correct URL format is:
[opmn:]corbaname::host:port#[instancename#]appname
This section describes release notes for the OC4J XML Query Service (XQS). It covers the following topics:
The XQS Client API now includes the XQSFactory class. The factory provided by this class is used to create instances of the new main XQS client interfaces:
oracle.xqs.client.QueryParameterI
oracle.xqs.client.XQSFacadeI
The previous classes have been deprecated:
oracle.xds.client.QueryParameter
oracle.xds.client.XQSFacade
The <xqsview-source> element is now used to define SQL queries for database access. The <wsdl-source> element is no longer used. The <xqsview-source> element is defined as part of a SQL-based XQS view.
The XQS chapter in the OC4J Services Guide contains an error. The example XQuery expression provided in the "Type-Checking for Input Parameters" section is incorrect. The following example is correct:
import schema namespace ns1="urn:namespace_1" at "http://mydomain/myschema.xsd"; declare namespace xqs = "http://xmlns.oracle.com/ias/xqs"; declare function xqs:takeNS1Input($param as element(ns1:InputElement)?) external; let $in := <ns1:InputElement>...</ns1:InputElement> let $y := xqs:takeNS1Input($in) return <result>$y//ns1:Content</result>
The XQS chapter in the OC4J Services Guide contains an error. The "XQuery Optional Features" section indicates that the XQuery schema import feature is not supported. XQS does support the schema import feature as defined by the W3C.
This section describes release notes for OC4J Application Client Container. It covers the following topics:
In this release, when implementing a custom security callback handler for an application client, the handler must set all three callback objects (NameCallback, PasswordCallback, and TextInputCallback). If you do not set all three objects, a java.lang.NullPointerException is given when trying to instantiate the remote connection to the OC4J server and the JNDI context setup fails.
This section describes release notes for J2EE Connector Architecture (J2CA). It covers the following topics:
Section 9.7.1, "New Class Loader Architecture for Standalone Resource Adapters"
Section 9.7.2, "Deployment Dependencies between Standalone Resource Adapters"
In this release, standalone resource adapters are no longer added to the default application's class loader (except for the internal JMS and data source resource adapters). Instead, standalone resource adapters are added as shared libraries that (by default) are available to all applications. The new architecture allows multiple versions of a standalone adapter to be deployed in OC4J. See the Oracle Containers for J2EE Resource Adapter Administrator's Guide for detailed information.
In this release, a standalone resource adapter can only import previously deployed standalone resource adapters. Therefore, a standalone resource adapter must be deployed prior to any dependent standalone resource adapter. This is different than the behavior in 10.1.3 where a standalone resource adapter can lookup and use a standalone resource adapter which was deployed after itself.
Starting in this release, resource adapters that rely on the default class loader to resolve non shared-library dependencies at runtime will fail. Dependencies on libraries and other standalone resource adapters are configured explicitly by importing shared libraries. A standalone resource adapter's proprietary deployment descriptor (oc4j-ra.xml) is used to import shared libraries. See the Oracle Containers for J2EE Resource Adapter Administrator's Guide for detailed information on importing shared libraries.
For the Oracle Application Server 10.1.3.1.0 implementation, you no longer need to restart the default application after deploying, redeploying, undeploying standalone resource adapters in an OC4J instance. You should restart any dependent J2EE applications that take advantage of the standalone resource adapter.
However, there are cases where a restart of the default application is still required. Specifically, if you perform a deployment operation on the adapters for accessing Oracle Enterprise Messaging Service (OEMS) file and memory based provider (OracleASjms.rar) or the OEMS database persistence provider (ojms.rar), then you will be required to restart the default application.
These adapters are Oracle-internal resource adapters for JMS connectivity and have administrative tasks that may require additional deployment and redeployment operations.
Be aware of the following notes when using the OracleAS JAAS Provider in release 10.1.3.1 or 10.1.3.2:
Section 9.8.2, "Use of JAAS Permissions and JAZNMigrationTool with External LDAP Provider"
Section 9.8.3, "Proper Specification of osso.conf File Name for SSO Configuration"
Section 9.8.4, "User and Role APIs Replace OracleAS JAAS Provider Realm API Functions"
Section 9.8.6, "Controlling Caching of JNDI Contexts for LDAP Connections"
Section 9.8.7, "JAZN Tool No Longer Includes -clustersupport"
Section 9.8.8, "AJP13 Protocol Vulnerable to Bypass User Authentication"
In the section "Migration Tool Command Syntax" in chapter 7, "File-Based Security Provider", of the 10.1.3.1 Oracle Containers for J2EE Security Guide, the syntax shown at the beginning of the section is incomplete. It should include the package of JAZNMigrationTool. Here is the correct syntax:
% java oracle.security.jazn.tools.JAZNMigrationTool [-st xml] [-dt ldap|xml] [-D binddn] [-w passwd] [-h ldaphost] [-p ldapport] [-sf sourcefilename] [-df destfilename] [-sr source_realm] [-dr dest_realm] [-m policy|realm|all] [-help]
(This is correctly shown in the example at the end of the section.)
For a situation where you are using JAAS authorization in conjunction with an external LDAP provider, this release note provides details to complete the very brief discussion in "Granting Additional Permissions to External LDAP Principals" in chapter 10, "External LDAP Security Providers", of the 10.1.3.1 Oracle Containers for J2EE Security Guide.
Note that JAZNMigrationTool, while more typically used to migrate from a file-based provider to an alternative file-based provider or to Oracle Internet Directory, can also be used in conjunction with an external LDAP provider to migrate JAAS policy information to the system-jazn-data.xml file on a target server.
Complete the following steps to grant necessary permissions to LDAP principals for the external LDAP provider:
Migrate JAAS policy information from system-jazn-data.xml on the development server to system-jazn-data.xml on the target server, using the "-m policy" setting. This is to migrate policy information only (to the target system-jazn-data.xml file)—you cannot use JAZNMigrationTool to directly migrate user and role information into the external LDAP provider. (More precisely, JAZNMigrationTool cannot create an LDIF file appropriate for external LDAP providers. It is capable of creating LDIF files appropriate for Oracle Internet Directory only, with the directory information tree and schema expected by Oracle Internet Directory.)
Manually edit the migrated policy information to use LDAPPrincipal.
After you migrate the policy information as discussed in step 1, the resulting entries in the target system-jazn-data.xml file will have grantees referencing the XMLRealmRole principal class. For use with an external LDAP provider, these entries must be updated to reference the LDAPPrincipal class instead. For example, assume system-jazn-data.xml includes the following principal configuration in a grantee element:
<principal>
<realm-name>jazn.com</realm-name>
<type>role</type>
<class>oracle.security.jazn.spi.xml.XMLRealmRole</class>
<name>jdoe</name>
</principal>
This must be updated manually to remove the <realm-name> and <type> elements and to specify LDAPPrincipal instead of XMLRealmRole, as follows:
<principal>
<class>oracle.security.jazn.realm.LDAPPrincipal</class>
<name>jdoe</name>
</principal>
Manually create any necessary user and role accounts in the external LDAP provider. Ensure that the user and role names you create conform to the principals referenced in the policy configuration you migrated to the target server in step 1.
Note:
Additional steps to updateorion-application.xml to enable JAAS mode and to set up necessary role mapping are already discussed in the 10.1.3.1 Oracle Containers for J2EE Security Guide.In chapter 8, "Oracle Identity Management", of the 10.1.3.1 Oracle Containers for J2EE Security Guide, in the section "Configure SSO (Optional)", under the first step, "Run the SSO Registration Tool", the following example is shown:
% $ORACLE_HOME/sso/bin/ssoreg.sh -oracle_home_path $ORACLE_HOME \ -site_name myhost.mydomain.com -config_mod_osso TRUE \ -mod_osso_url http://myhost.mydomain.com:7777 -remote_midtier \ -config_file $ORACLE_HOME/Apache/Apache/conf/osso/osso.conf
Actually, if you run this exact command, using the configuration file name osso.conf, there will be an error indicating that osso.conf already exists. (You should not overwrite the existing osso.conf file.) Instead of osso.conf, use some other file name such as midtier_osso.conf, for example. A new file will be created with the name you specify, containing the SSO partner application configuration for the middle tier you are associating with SSO. Copy this file to the middle tier you are configuring.
Tip:
We recommend that the file name indicate the host and port of the middle tier. For example,midtier1_7779_osso.conf.In the 10.1.3.1 Oracle Containers for J2EE Security Guide, the "What's New" section notes that the new user/role API framework includes replacement functionality for the deprecated UserManager, User, and Group classes in the com.evermind.security package.
It should also be noted that the user/role API framework has replacement functionality for realm APIs in or under the oracle.security.jazn package.
These packages are deprecated and will not be supported in the 11g release.
Be aware of the following issue when you use the OracleAS JAAS Provider migration tool to migrate policies from the file-based provider to the Oracle Identity Management (essentially, Oracle Internet Directory) security provider, either in "policy" mode or "all" mode: The migration tool prepends the Oracle Internet Directory realm name to custom or nonrealm principal names in grantee entries in the policy configuration. (A custom principal may come into play when authenticating through a custom login module, for example.)
In the migrated configuration, a custom principal name in a grantee entry becomes, for example, "us/anyone" instead of just "anyone", assuming "us" is the realm name. This results in permission issues. For ADF applications, for example, this results in public pages not working after migration to Oracle Internet Directory as the security provider.
This problem will be fixed in the 10.1.3.3 release. For 10.1.3.2 and prior 10.1.3.x releases, you can use either of the following workarounds:
Manually remove the "us/" prefix from the LDIF file that the migration tool creates, prior to importing it into Oracle Internet Directory.
Manually remove the "us/" prefix from relevant grantee entries after the migration, using Oracle Internet Directory administration tools.
By default in 10.1.3.x implementations, OC4J uses java.lang.ref.WeakReference objects to cache JNDI contexts when using connection pooling for connections to the LDAP-based provider, and uses JVM garbage collection to garbage-collect the JNDI contexts.
We recommend, however, that you not rely on this WeakReference and JVM garbage collection functionality. You can disable it with the following property setting:
<jazn ... > <property name="jndi.ctx_pool.weakref.enable" value="false" /> ... </jazn>
(The default setting is "true".) When this is disabled, OC4J uses the following properties, which you should set appropriately, to control caching in the connection pool:
jndi.ctx_pool.timeout: Timeout value, in milliseconds, for the LDAP JNDI connection pool. The default is 0, for no timeout. The recommended setting is 3600000 milliseconds, which is one hour.
jndi.ctx_pool.threshold_size: Threshold to limit the number of idle connections in the pool. The default, and recommended initial setting, is 100.
(Both properties are ignored if jndi.ctx_pool.weakref.enable is set to "true".)
For example:
<jazn ... > <property name="jndi.ctx_pool.weakref.enable" value="false" /> <property name="jndi.ctx_pool.threshold_size" value="100" /> <property name="jndi.ctx_pool.timeout" value="3600000" /> ... </jazn>
Notes:
The jndi.ctx_pool.weakref.enable and jndi.ctx_pool.threshold_size properties are not documented in the 10.1.3.x Oracle Containers for J2EE Security Guide.
The jndi.ctx_pool.timeout property is documented in the 10.1.3.x Oracle Containers for J2EE Security Guide, but without mention of the fact that this parameter is ignored if jndi.ctx_pool.weakref.enable is set to "true" (the default).
The DCM component is no longer supported in Oracle Application Server 10.1.3. Consequently, the -clustersupport option is no longer available in the jazn.jar administrative tool.
Problem
Using the -clustersupport option when invoking jazn.jar results in the following error:
An error has occured in propagating the changes to the cluster. java.lang.ClassNotFoundException oracle.security.jazn.smi.DcmUtil
This problem occurs because Distributed Configuration Management (DCM), used in prior releases of Oracle Application Server to replicate common configuration information across a cluster, is no longer supported with release 10.1.3. Consequently, the -clustersupport option is not supported in the JAZN (jazn.jar) administrative tool.
Solution
Do not use the -clustersupport option when invoking jazn.jar.
When OC4J is running a site using the AJP13 protocol, a security vulnerability exists if a remote attacker can directly access the AJP port on the machine running OC4J. The AJP13 protocol defines an AJP parameter remote_user, which is used by OHS to implement mod_osso. An attacker can use this parameter to bypass authentication on OC4J. If a user constructs an AJP packet that inserts a valid remote_user value as an AJP parameter, the user will be able to access resources that the specified user (remote user) has permission to access.
You must ensure that the system running OC4J does not expose the AJP port to the outside world.
You can protect against the vulnerability in either of the following ways:
Enable SSL between OC4J and Oracle HTTP Server (preferred). For 10.1.3.x releases, this is documented in the Oracle Containers for J2EE Security Guide. For release 10.1.2 or 9.0.4, this is documented in the Oracle Containers for J2EE Servlet Developer's Guide.
Use the <access-mask> element (a subelement of <orion-web-app>) in global-web-application.xml or orion-web.xml to restrict access to appropriate host names, domains, or IP addresses. This element is documented in the Oracle Containers for J2EE Servlet Developer's Guide.
This section discusses general OC4J issues:
If you restart a standalone OC4J instance multiple times through Application Server Control, you may encounter the error java.lang.OutOfMemoryError, reported on the server console, and the OC4J instance will be unusable.
The workaround is to manually stop and restart the OC4J instance.
This section describes known errors in the OC4J documentation in Oracle Application Server 10g releases 10.1.3.1 and 10.1.3.2. It covers the following book(s):
Section 9.10.2, "Oracle Application Server Advanced Web Services Developer's Guide"
Section 9.10.3, "Oracle Containers for J2EE Deployment Guide"
Section 9.10.6, "Oracle Containers for J2EE Developer's Guide"
Section 9.10.7, "Oracle Containers for J2EE Configuration and Administration Guide"
Section 9.10.8, "Oracle Containers for J2EE Servlet Developers Guide"
Section 9.10.9, "Oracle Containers for J2EE Enterprise JavaBeans Developer's Guide"
This section describes Web Services documentation errata. It covers the following topic(s):
Section 9.10.1.1, "Incorrect Link Provided for wsclient_extended.zip File"
Section 9.10.1.2, "Typos in XML Type Names in Advanced Web Services Developer's Guide"
The following incorrect link for the wsclient_extended.zip file and companion CD was used in Chapter 4 and Appendix A of the Oracle Application Server Web Services Developer's Guide:
http://download.oracle.com/otn/java/oc4j/10131/wsclient_extended.zip
The correct link should be:
http://www.oracle.com/technology/software/products/ias/htdocs/utilsoft.html
Table H–4, "Mapping Java Collection Classes to XML Types", in the Advanced Web Services Developer's Guide, contains the following typographical errors in XML type names:
--java.util.HashMap maps to owi:hashmap. This is incorrect. The correct mapping is to owi:hashMap (the M should be upper case)
--java.util.TreeMap maps to owi:treemap. This is incorrect. The correct mapping is to owi:treeMap (the M should be upper case)
The correct link should be:
http://www.oracle.com/technology/software/products/ias/htdocs/utilsoft.html
In the Web Services Developer's Guide, the section "How Stub Clients Can Get Headers with the ServiceLifecycle Interface" describes how the HTTP_SERVLET_REQUEST and HTTP_SERVLET_RESPONSE properties in the oracle.webservices.ServerConstants class can be used to access the HTTP message header.
This section claims that these properties can be used on the client as well as on the server to access the HTTP message header. This is incorrect. The client cannot access the HTTP layer at all by using these properties. Any attempt to call these properties on the client will return an exception similar to the following:
javax.xml.rpc.JAXRPCException: Stub does not recognize property:...
There is no work around.
This section describes errors in the Oracle Application Server Advanced Web Services Developer's Guide. It covers the following item(s):
The chapter titled "Using Web Service Providers" in the Oracle Application Server Advanced Web Services Developer's Guidecontains examples with incorrect XML.
Example 10-5
"oracle-webservices.xml Fragment, with a <provider-description> Clause" is not well-formed xml.
The spaces after slashes in closing tags must be removed:
Cchange: </ wsdl-service-name> to: </wsdl-service-name>
Change: </ implementation-class> to: </implementation-class>
Closing tag is missing a slash:
Change: <auditing>...<auditing> to: <auditing>...</auditing>
Example 10-6
"Provider Elements in the web.xml Deployment Descriptor" is well-formed but invalid XML.
The description and display-name elements are out-of-order and mis-positioned according to the JDeveloper 10.1.3.3.0.4157 schema validation:
Change:
<servlet-name>LoggerProviderPort</servlet-name>
<display-name>LoggerProviderPort</display-name>
<description>JAX-RPC endpoint Provider Port</description>
to:
<description>JAX-RPC endpoint Provider Port</description>
<display-name>LoggerProviderPort</display-name>
<servlet-name>LoggerProviderPort</servlet-name>
This section describes Web Services documentation errata. It covers the following topic(s):
Section 9.10.3.1, "Incorrect Attribute Name in Example of Ant Task"
Section 9.10.3.2, "File Name oracle-ant.jar Should Be ant-oracle.jar"
Section 9.10.3.4, "Checking for Updates by Comparing Directory and EAR or WAR Timestamps"
Section 9.10.3.5, "Incorrect Subswitch Names for admin_client.jar Commands"
Section 9.10.3.7, "deploymentPlan Property Not Valid in Ant Task for WAR Deployment"
The "name" attribute should be "connectionPoolName" in the example of the testDataSourceConnectionPool Ant task under "Testing a Data Source Connection Pool" in Chapter 10, "Using OC4J Ant Tasks for Deployment." This example is in version 10.1.3.1 of the Oracle Containers for J2EE Deployment Guide.
The correct example follows:
<oracle:testDataSourceConnectionPool deployerUri="deployer:oc4j:localhost" userid="oc4jadmin" password="welcome1" applicationName="default" connectionPoolName="ScottConnectionPool" sqlStatement="select * from dual" />
In Oracle Containers for J2EE Deployment Guide, Chapter 10, "Using OC4J Ant Tasks for Deployment", under "Preparing to Use OC4J Ant Tasks" and "Incorporating the OC4J Ant Tasks into Your Environment," the file name oracle-ant.jar should be ant-oracle.jar in two places:
The second paragraph
Incorrect text: The oracle-ant.jar file is installed by default within the ORACLE_HOME/ant/lib directory.
Correct text: The ant-oracle.jar file is installed by default within the ORACLE_HOME/ant/lib directory.
The description of ant-oracle.xml
Incorrect text: This is necessary only if oracle-ant.jar is not installed in the ORACLE_HOME/ant/lib directory.
Correct text: This is necessary only if ant-oracle.jar is not installed in the ORACLE_HOME/ant/lib directory.
In both places, the directory path is accurate.
In Oracle Containers for J2EE Deployment Guide, Chapter 10, "Using OC4J Ant Tasks for Deployment", the version property of the removeSharedLibrary Ant task should be libraryVersion in the "Removing a Shared Library" subsection of "Creating and Managing Shared Libraries."
A corrected example for the removeSharedLibrary Ant task follows:
<oracle:removeSharedLibrary
deployerUri="${deployer.uri}"
userid="${oc4j.admin.user}"
password="${oc4j.admin.password}"
logfile="${log.dir}/filename.log"
libraryName="name"
libraryVersion="version"/>
In Oracle Containers for J2EE Deployment Guide, Chapter 14, "Using Automatic Deployment in OC4J", the note under "Using the Check-for-Updates Feature" reads as follows:
Note:
An EAR or WAR file copied to theORACLE_HOME/j2ee/instance/applications directory will be deployed or redeployed by default upon OC4J startup, regardless of whether auto-deployment is enabled.The EAR or WAR file is also deployed when its timestamp is newer than the timestamp of the directory that contains the file.
The names of some command subswitches are incorrect in Chapter 11, "Using the admin_client.jar Utility for Deployment." Table 9-2 shows the incorrect and correct names for these subswitches. Also, the table shows the correct name for the -addDataSourceConnectionPool command, which was misspelled in the book.
Table 9-2 Correct Names for Subswitches of admin_client.jar Commands
| Command | Incorrect Subswitch Name | Correct Subswitch Name |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Some information is missing from the description of the -redeploy command subswitches under "Redeploying an Archive" in Chapter 11, "Using the admin_client.jar Utility for Deployment":
The -file subswitch can specify the name of an EAR, WAR, or RAR, not just an EAR.
The -bindAllWebApps [webSiteName] subswitch is missing. This optional subswitch binds all Web modules to the specified Web site, or to the default Web site if none is specified.
You can optionally supply a value for webSiteName, which is the name portion of the name_web-site.xml file that configures the Web site.
The deploymentPlan property is incorrectly listed in Table 10-7, "deploy Properties for Standalone WAR Deployment" in Chapter 10, "Using OC4J Ant Tasks for Deployment." You cannot use a deployment plan to deploy a standalone Web module.
Application Server Control Console is incorrectly listed as a tool under "Incremental Redeployment of EJB Modules" in Chapter 3, "Deploying EJB Modules." You cannot use Application Server Control for incremental redeployment of EJB Modules. Use one of the other tools listed instead:
The -updateEBJModule command of the admin_client.jar command-line utility (or admin.jar for standalone OC4J)
The updateEJBModule Ant task
JDeveloper
For more information about EJB redeployment, see the chapter.
This section describes OC4J Services Guide documentation errata. It covers the following topic(s):
Section 9.10.4.2, "Wrong Defaults Listed for Connection Pool Attributes"
Section 9.10.4.4, "Revised Description for max-connections Attribute"
The "Defining Data Source" chapter in the OC4J Services Guide contains an error. The Fifth bullet in the "Configuration Notes" section is incorrect. The bullet should read:
"Native data sources are defined using the <native-data-source> element. The data-source-class attribute can be set to any fully qualified class name of an object that implements the javax.sql.DataSource interface."
The Data Source chapter in the OC4J Services Guide contains an error. The Connection Pool Attributes table incorrectly lists default values for the time-to-live-timeout attribute and the abandoned-connection-timeout attribute. The default value for these features is actually 0 and not -1. The default value (0) indicates that these features are disabled.
Table 5-3, "Connection Pool Attributes," includes a description of the disable-server-connection-pooling attribute. This attribute is no longer supported and should not be added to the J2EE_HOME/config/data-sources.xml configuration file.
The Data Source chapter in the OC4J Services Guide contains an error. The Connection Pool Attributes table states that setting the max-connections attribute to 0 disables connection pooling. Setting this value to 0 does not disable connection pooling when using Oracle's Implicit Connection Cache (ICC). Instead, an SQL error is returned:
java.sql.SQLException: Unable to get a physical connection from the database... there are no connections available.
To disable connection pooling when using the oracle.jdbc.pool. OracleDataSource connection factory class, set the connectionCachingEnabled property to false. For example:
<connection-pool name="myConnectionPool"
<connection-factory
factory-class="oracle.jdbc.pool.OracleDataSource"
user="scott"
password="tiger"
url="jdbc:oracle:thin:@//localhost:1521/">
<property name="connectionCachingEnabled" value="false"/>
</connection-factory>
</connection-pool>
This section contains information about the following errata in the 10.1.3.1 Oracle Containers for J2EE Security Guide:
Section 9.10.5.1, "Incorrect Notes on 'Mixed Usage' between Identity Store and Policy Store"
Section 9.10.5.2, "Incorrect Note on Automatic Creation of Indirect User Accounts"
Section 9.10.5.4, "Invalid Reference to x509cert.mapping.attribute Property"
Section 9.10.5.5, "Form Authentication Method Supported with Custom Login Modules"
In the 10.1.3.1 Oracle Containers for J2EE Security Guide, there are two notes that include the following: "...the result would be a mixed usage where the provider configured in orion-application.xml would be the identity store used for authentication, while the provider specified in jazn.xml would be the policy store used for authorization. This is not recommended."
One appears under "Policy Repository Setting in jazn.xml" in the "Authorization in OC4J" chapter (chapter 5); the other under "Associate Oracle Internet Directory with OC4J" in the "Oracle Identity Management" chapter (chapter 8).
It is not appropriate to say this is not recommended. In fact, it is the only alternative when using external LDAP or a custom login module. While certain steps or precautions must be taken, these steps are already documented.
In the 10.1.3.1 Oracle Containers for J2EE Security Guide, the following note appears in the section "Using Password Indirection" (chapter 6): "If you choose to use indirect passwords in the current OC4J implementation, an indirect user is created in the system-jazn-data.xml file. Be aware that these indirect user accounts are not removed automatically when an application is undeployed; you must use Application Server Control Console to delete any stale indirect user accounts manually."
This note is misleading, as the indirect user account is created automatically only in the case of Web services, when Application Server Control Console is used to configure a keystore or keystore passwords (signature key and encryption key).
The point of the note should simply be that if an indirect user account is created, either automatically or manually, undeploying the application will not remove the account automatically; you must do so manually.
In the 10.1.3.1 and 10.1.3.0.0 Oracle Containers for J2EE Security Guide, in the section "Using Password Indirection" (chapter 6), a passage refers to the password attribute of the <data-source> element in file data-sources.xml. This actually should refer to the password attribute of the <native-data-source> element or <managed-data-source> element, which combined to replace the <data-source> element in the 10.1.3.0.0 release.
The Oracle Containers for J2EE Security Guide incorrectly refers to the OracleAS JAAS provider property x509cert.mapping.attribute. In particular, Chapter 13, Web Application Security Configuration, in the section "Using Client-Cert Authentication" contains the following incorrect example:
<orion-application ... >
...
<jazn provider="XML" ... default-realm="myrealm" ... >
<property name="x509cert.mapping.attribute" value="CN"/>
...
</jazn>
...
</orion-application>
This example and other references to x509cert.mapping.attribute are incorrect since the x509LoginModule utilizes the mapping.attribute property as do other providers. For more information about this property and how to configure it, see the release note at Section 9.1.18, "Specifying the Mapping Attribute"".
The Oracle Containers for J2EE Security Guide incorrectly states in at least two locations that the form authentication method is not supported with custom security providers (custom login modules). This is incorrect—in 10.1.3.x implementations, the form method is supported with custom security providers.
The error occurs in the following locations:
10.1.3.0.0:
Chapter 2, "Overview of OC4J Security", section "Authentication in the OC4J Environment";
Chapter 13, "Web Application Security Configuration", section "Specifying auth-method in web.xml".
10.1.3.1 and higher:
Chapter 2, "Java Platform Security", section "Web Application Standard Authentication Methods"
Chapter 17, "Web Application Security Configuration", section "Specifying auth-method in web.xml".
This section describes documentation errata for Oracle Containers for J2EE Developer's Guide, including the following topic:
Section 9.10.6.1, "Missing Character in Service URL Strings"
Section 9.10.6.2, "Incorrect Setting for Client Module in orion-application.xml"
Section 9.10.6.3, "Correction to Example: Replacing the Oracle XML Parser with the Xerces Parser"
In Oracle Containers for J2EE Developer's Guide, Chapter 5, "Creating MBeans to Manage Your Applications," under "Remote Management Using the JMX Remote API (JSR-160)," some of the service URL strings in the code segments are missing a required colon character (":"). The incorrect entries are like this one:
String url="service:jmx:rmi///opmn://opmnhost1.company.com:6003/home"
In this entry, ":" is missing between "rmi" and "///".
The correct service URL string follows:
String url="service:jmx:rmi:///opmn://opmnhost1.company.com:6003/home"
The description of the <client-module> element recommends the wrong value for the user attribute under "Elements in the orion-application.xml File" in Appendix A, "OC4J-Specific Deployment Descriptors." The descriptions of the auto-start and user attributes incorrectly recommend setting user to true when auto-start='true'.
These attribute settings, however, would prevent OC4J from calling the main method in an application client archive (CAR) at startup. When the auto-start attribute is set to true, you need to set user to anonymous. The descriptions of these <client-module> attributes should read as follows:
auto-start: Whether to automatically start the application in-process at OC4J server startup. The default is false. If this attribute is set to true, the user attribute must be set to anonymous.
user: Set to anonymous to run the client in-process. If the auto-start attribute is set to true, the user attribute must be set to anonymous.
The sample, at the end of the subsection "Example: Replacing the Oracle XML Parser with the Xerces Parser," is missing a closing quotation mark in the max-version attribute:
<import-shared-library name="xerces.xml" max-version="2.5.0/>
The sample code line should read as follows:
<import-shared-library name="xerces.xml" max-version="2.5.0"/>
This section describes documentation errata for Oracle Containers for J2EE Configuration and Administration Guide, including the following topics:
Section 9.10.7.1, "Incorrect Example for Disabling Text File Logging"
Section 9.10.7.2, "Incorrect Subswitch Names for admin_client.jar Commands"
Section 9.10.7.4, "Format for Variables That Configure Text Logging for Web Sites"
Section 9.10.7.5, "Incorrect Description of Queue Attribute for Thread Pools"
Section 9.10.7.6, "Configuration of OPMN Gateway Element Shows Incorrect Order"
Section 9.10.7.7, "Starting Order Incorrect for Static Peer-to-Peer Replication"
In Oracle Containers for J2EE Configuration and Administration Guide, Chapter 11, "Logging in OC4J," under "Enabling or Disabling Text File Logging," the example for disabling text file logging comments out the entire <log> element, but the text before the example says to remove or comment out the <file> element. The incorrect example follows:
<!-- <log> <file path="application.log" /> </log> -->
Here is a corrected example:
<log> <!-- <file path="application.log" /> --> </log>
The names of some command subswitches are incorrect in Chapter 6, "Using the admin_client.jar Utility." Table 9-3 shows the incorrect and correct names for these subswitches. Also, the table shows the correct name for the -addDataSourceConnectionPool command, which was misspelled in the book.
Table 9-3 Correct Names for Subswitches of admin_client.jar Commands
| Command | Incorrect Subswitch Name | Correct Subswitch Name |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Some information is missing from the description of the -redeploy command subswitches under "Redeploying an Archive" in Chapter 6, "Using the admin_client.jar Utility":
The -file subswitch can specify the name of an EAR, WAR, or RAR, not just an EAR.
The -bindAllWebApps [webSiteName] subswitch is missing. This optional subswitch binds all Web modules to the specified Web site, or to the default Web site if none is specified.
You can optionally supply a value for webSiteName, which is the name portion of the name_web-site.xml file that configures the Web site.
Information about the $cookie and $header variables is missing from the description of the format attribute of the <access-log> element under "Configuring Text-Based Access Logging" in Chapter 13, "Managing Web Sites in OC4J."
In the <access-log> subelement of the <web-site> element in a Web site's configuration file (*-web-site.xml), you can specify a number of variables in the format attribute that result in information being prepended to log entries. When you specify the $cookie or $header variable, the format needs to be as follows:
$cookie:[name] $header:[name]
The description of the queue attribute is incorrect in Table 10-2, "Attributes of <thread-pool> and <custom-thread-pool>," in Chapter 10, "Task Manager and Thread Pool Configuration." The incorrect description follows:
| Attribute | Description |
|---|---|
queue |
The maximum number of requests that can be kept in the queue. The default value is 0.
The |
Here is a corrected description of the queue attribute:
| Attribute | Description |
|---|---|
queue |
The maximum number of requests that can be kept in the queue. The default value is 0.
The |
The order of <topology> subelements is incorrect in the opmn.xml configuration example under "Configuring Cross-Topology Gateways" in Chapter 8, "Configuring and Managing Clusters and OC4J Groups," of Oracle Containers for J2EE Configuration and Administration Guide. The example shows a configuration for a gateway as follows:
<opmn> <notification-server> <port ... /> <ssl ... /> <topology> <gateway list="node1.com:6201&node2.com:6202&node3.com:6203/"/> <discover list="*224.0.0.37:8205"/> </topology> </notification-server> ... </opmn>
Because the <topology> subelements are incorrectly ordered according to the opmn.xsd file, using this configuration results in an OPMN error.
The correct configuration follows:
<opmn> <notification-server> <port ... /> <ssl ... /> <topology> <discover list="*224.0.0.37:8205"/> <gateway list="node1.com:6201&node2.com:6202&node3.com:6203/"/> </topology> </notification-server> ... </opmn>
The following paragraph shows an incorrect starting order for nodes under "Configuring Static Peer-to-Peer Replication" in Chapter 9, "Application Clustering in OC4J," of Oracle Containers for J2EE Configuration and Administration Guide.
In this configuration, each node specifies one other node as its peer. The result is that all of the nodes within the cluster are able to establish connections with one another. This scenario will work only if each node is started in succession; that is, www1.company.com must be started before www2.company.com. Otherwise, www2.company.com will not be able to "see" www1.company.com.
The following paragraph has the correct starting order.
In this configuration, each node specifies one other node as its peer. The result is that all of the nodes within the cluster are able to establish connections with one another. This scenario will work only if each node is started in succession; that is, www3.company.com must be started before www2.company.com. Otherwise, www2.company.com will not be able to "see" www3.company.com.
This section describes documentation errata for Oracle Containers for J2EE Servlet Developer's Guide, including the following topic:
The value specified for the domain attribute of a <host-access> element of an orion-web.xml file must be a domain, NOT a host.
In the Oracle Containers for J2EE Servlet Developer's Guide, 10g (10.1.3.1.0), Appendix B Web Module Configuration Files, Table B-9 "<host-access> Attributes" incorrectly states either a host or a domain can be specified for the domain attribute.
Only a domain can be specified for the domain attribute of a <host-access> element of an orion-web.xml file.
This section describes documentation errata for the Oracle Containers for J2EE Enterprise JavaBeans Developer's Guide. It includes the following topic:
In the Oracle Containers for J2EE Enterprise JavaBeans Developer's Guide, Chapter 20 Configuring Data Sources, section "Associating TopLink With an Oracle JDBC Driver", under "EJB 2.1. CMP Applications", we explain how to define a new Oracle JDBC shared library in the boot.xml file. Oracle recommends users should not edit the boot.xml file as documented, as this is not supported by Oracle.
|
 Copyright © 2008, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|