| Oracle® Application Server Release Notes 10g Release 3 (10.1.3) for HP-UX PA-RISC (64-Bit) B28068-01 |
|
 Previous |
 Next |
| Oracle® Application Server Release Notes 10g Release 3 (10.1.3) for HP-UX PA-RISC (64-Bit) B28068-01 |
|
Previous |
Next |
This chapter discusses release notes for Oracle Containers for J2EE (OC4J) for 10.1.3. It includes the following topics:
Section 5.1, "Configuration, Deployment, and Administration"
Section 5.7, "Release Notes for J2EE Connector Architecture (J2CA)"
Section 5.8, "Release Notes for OracleAS JAAS Provider and Security"
Section 5.10, "Oracle Application Server Containers for J2EE Job Scheduler"
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 topic(s):
Section 5.1.1, "JDK 5.0 Requires the -doCloseWithReadPending Option"
Section 5.1.3, "Deprecated Environment Variable ejb.batch.compile"
Section 5.1.5, "Web-Site-Related Options No Longer Available"
Section 5.1.6, "Unsupported Methods in JMX MBeanServer and MBeanServerConnection Interfaces"
Section 5.1.8, "Workaround for ORA-604/ORA-12705 Error Using a Not-Fully Supported Locale"
Section 5.1.9, "Incompatibility When Moving Between JDK 1.5 and 1.4"
Section 5.1.10, "Configuring a Machine to Work With and Without a Network Connection"
Section 5.1.11, "Converting Pre-10.1.3 Data Sources to 10.1.3 Format"
Section 5.1.12, "Xalan Library Not Supported as a Shared Library with JDK1.4"
Section 5.1.13, "Recommendation for <cluster> Element write-quota Setting"
For information on configuring OC4J, see the Configuration Guide for OC4J at:
http://www.oracle.com/technology/index.html
The -doCloseWithReadPending option in Java and JRE versions 1.5 or 5.0 allows one thread to close a socket when there is a read pending on the same socket from another thread.
When close() is called on a socket which has an outstanding read call from another thread, the close() by default blocks the socket until the read call completes.
With the -doCloseWithReadPending option, the socket close() call closes the socket and in the context of the thread with the pending read, a SocketException with the message "Socket closed" is thrown.
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 5-1 lists.
Table 5-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. |
Environment variable 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 deprecated:
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. |
The OC4J web-site-related options (accessible with the -site command) that were provided in the admin.jar utility in previous releases are no longer available.
For information on how to create and manage OC4J web-site configurations see the"Managing Web Sites in OC4J" chapter in the Oracle Containers for J2EE Configuration and Administration Guide .
A number of methods from the JMX MBeanServer interface are not available to J2EE applications when they use the MBeanServer object obtained from the following operation:
MBeanServer mbsrv = MBeanServerFactory.newMBeanServer();
The use of any of the following methods on the returned MBeanServer object will throw an UnsupportedOperationException exception:
public final ClassLoader getClassLoaderFor(ObjectName mbeanName) public final ClassLoader getClassLoader(ObjectName loaderName) public final ClassLoaderRepository getClassLoaderRepository() public final Object instantiate(String className) public final Object instantiate(String className, ObjectName loaderName) public final Object instantiate(String className, Object[] params, String[] signature) public final Object instantiate(String className, ObjectName loaderName, Object[] params, String[] signature) public final ObjectInstance createMBean(String className, ObjectName name) public final ObjectInstance createMBean(String className, ObjectName name, ObjectName loaderName) public final ObjectInstance createMBean(String className, ObjectName name, Object[] params, String[] signature) public final ObjectInstance createMBean(String className, ObjectName name, ObjectName loader, Object[] params, String[] signature) public final ObjectInputStream deserialize(ObjectName name, byte[] ) public final ObjectInputStream deserialize(String className, byte[] data) public final ObjectInputStream deserialize(String className, ObjectName loaderName, byte[] data)
A number of methods from the MBeanServerConnection interface are not supported when an application uses the Oracle JMX connectors. The use of any of the following methods on the MBeanServerConnection object that is created will throw an UnsupportedOperationException exception:
public final ObjectInstance createMBean(String className, ObjectName name) public final ObjectInstance createMBean(String className, ObjectName name, ObjectName loaderName) public final ObjectInstance createMBean(String className, ObjectName name, Object[] params, String[] signature) public final ObjectInstance createMBean(String className, ObjectName name, ObjectName loader, Object[] params, String[] signature)
Currently Oracle Application Server 10.1.3.0.0 is certified with JDK 1.4.2_08 and JDK 1.5.0_02. The product installs with JDK 1.5.0_02 by default.
In general, J2SE releases are number a.b.c_d, where "a.b.c" is the major release number, as in 1.4.2 or 1.5.0, and "d" is the minor release number, as in "05" or "06". As a general practice, Oracle recommends that customers upgrade to the latest minor release number of J2SE to ensure that they benefit from any bugs resolved in those specific J2SE upgrades. Oracle explicitly restates the certification matrix for major release numbers of J2SE.
Currently there is a known J2SE bug in J2SE 1.5.0_05 and J2SE 1.5.0_06 that manifests itself in an out-of-memory error in long-running stress tests involving BigDecimals numeric types. This bug is tracked by Sun at:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6360541http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6372116The workaround for this bug is to upgrade to J2SE 1.5.0_06 and set the JVM startup parameters for the impacted Oracle Containers for J2EE instance with this additional parameter:
-XX:CompileCommand=exclude,oracle/jdbc/driver/NumberCommonaccessor.getBigdecim
Information on configuring the J2SE runtime in Oracle Application Server can be found in the Oracle Containers for J2EE Configuration and Administration Guide at:
http://www.oracle.com/technology/index.htmlWhen you try to get a connection on a Locale that is not supported in JDBC, JDBC throws a SQLException. - Bug 4704421
Use the following to verify runtime Java's locale:
System.out.println(Locale.getDefault().toString())
Unsupported Locales include any Locale that is NOT listed in the "Fully Supported Locales" table in on the Java 5.0 Java Supported Locales page at the following URL: http://java.sun.com/j2se/1.5.0/docs/guide/intl/locale.doc.html
For example, Locales that are "Provided but not Tested" include the following:
ab_CD
fr_FR_EURO
it_IT_EURO
th_TH_TH, Thai (Thailand,TH)
be, Belarusian
be_BY, Belarusian (Belarus)
es_AR, Spanish (Argentina)
es_BO, Spanish (Bolivia)
es_DO, Spanish (Dominican Republic)
es_EC, Spanish (Ecuador)
es_HN, Spanish (Honduras)
es_PY, Spanish (Paraguay)
es_UY, Spanish (Uruguay)
mk, Macedonian
mk_MK, Macedonian (Macedonia)
no_NO_NY, Norwegian (Norway,Nynorsk)
sq, Albanian
sq_AL, Albanian (Albania)
The workaround for this problem is to update your default Locale setting of Java. You can do any of the following:
Change default Locale from the unsupported es_AR, to the fully supported es (Spanish):
Locale.setDefault(new Locale("es"));
When Locale has variant code such as fr_FR_EURO, remove variant code (EURO) and set default:
Locale.setDefault(new Locale("fr", "FR"));
Set English as the default Locale:
Locale.setDefault(Locale.ENGLISH);
When you deploy an application (including the OC4J default application) to OC4J running JDK 1.5 (Java 5), you cannot re-use that deployment on OC4J running JDK 1.4.
Code compiled with JDK 1.5 (Java 5) cannot be read by the JDK 1.4 VM. When OC4J is running under JDK 1.4 and tries to load a class which was compiled with JDK 1.5, a class loading exception will be thrown with the following message:
Unsupported major.minor version 49.0
This can occur in scenarios such as:
You deploy an application that contains EJBs to OC4J running under JDK 1.5, then, without undeploying the application, you restart OC4J under JDK 1.4. The problem is that the generated code associated with the EJBs will have been compiled with the same JDK version that was used to start the server and that the generated code is cached between server restarts on the file system in the OC4J_HOME/j2ee/home/application-deployments directory.
The workaround for this is to shutdown the server, remove either the contents of the OC4J_HOME/j2ee/home/application-deployments directory (or just the offending application's sub-directory) and restart the server with JDK 1.4.
You deploy an EAR file which contains classes that were compiled with and targeted to JDK 1.5 to OC4J running under JDK 1.4.
The workaround for this is to recompile the contents of the EAR using JDK 1.4 and redeploy.
|
Note: To simplify this discussion, we assume that no cross compilations are being used to target code to specific JDK versions. |
When you work on a single machine using localhost, add the IP address in the <ipaddr> subelement of the <notification-server> element and explicitly set up a discover list in the <discover> element to refer to the localhost OPMN remote port, as defined in the cluster <port> element. An example of this configuration follows:
<notification-server>
<ipaddr remote="127.0.0.1" request="127.0.0.1"/>
<port local="6101" remote="6201" request="6004"/>
<ssl enabled="true"
wallet-file="$ORACLE_HOME\opmn\conf\ssl.wlt\default"/> <topology>
<discover list="localhost:6201"/>
</topology>
</notification-server>
If you supply the localhost IP address, 127.0.0.1, the machine can work with or without a network.
For information on converting pre-10.1.3 data sources to 10.1.3 format, see the release note at Section 5.6.3.3, "Converting Existing Data Sources to Release 3 Format".
If you are using JDK1.4, Oracle Application Server 10.1.3 does not support using the Xalan library shipped with the JDK as a shared library. To use the Xalan library, you have two alternatives:
Use JDK1.5, in which the embedded Xalan library IS supported as a shared library.
With JDK1.4, use a standalone distribution of the Xalan library instead of the embedded version.
Chapter 9 of the 10.1.3 Oracle Containers for J2EE Configuration and Administration Guide documents the <cluster> element of the orion-application.xml file, including use of the write-quota attribute. This attribute determines the number of other "group members" within a cluster to which application state information should be replicated.
Be aware, however, that a "group member" is actually a JVM, not a node, and that it is possible to have multiple JVMs per node.
To ensure that more than one node receives state replication, set write-quota to a number greater than the highest number of JVMs on any one node within the cluster. For example, if there are three nodes, which have six JVMs, four JVMs, and three JVMS, respectively, set write-quota to a value of at least 7.
If any application uses OCI drivers for a datasource connection, then add the following in opmn.xml for that particular OC4J instance. For example, if the application is deployed to the default home instance, configure the OCI drvier as follows:
<ias-component id="OC4J"> <environment> <variable id="SHLIB_PATH" value="$ORACLE_HOME/lib32" /> </environment> <process-type id="home" module-id="OC4J" status="enabled">
This section describes release notes for servlets. It covers the following topic(s):
Section 5.2.1, "Servlet Invocation by Classname Disabled by Default"
Section 5.2.3, "Warning Issued for servlet.init() Not Working with run-as"
Section 5.2.4, "Request Parameters Not Available During Filter Execution"
In the 10.1.3 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, customers 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
A physical file must be present for a welcome file to dispatch to a servlet. To create a servlet mapped to /index.html that maps to the JSP /index.jsp and have it serve as a welcome file, the web.xml file should include the following entries:
<servlet> <servlet-name> index_jsp </servlet-name> <jsp-file> /index.jsp </jsp-file> </servlet> <servlet-mapping> <servlet-name>index_jsp</servlet-name> <url-pattern>/index.html</url-pattern> </servlet-mapping>
This works only if there is a physical file, /index.html, in the Web application. The file can be zero length. As long as the file exists, this servlet will be loaded as the welcome file. Otherwise, a java.lang.StringIndexOutOfBoundsException exception will be thrown.
For a Web application, when run-as user is specified in the web.xml file, all method invocations except the Servlet.init() method will be invoked as the specified user. With the JMS Router being the default application of OC4J, calls need to be authorized to the router's EJBs. This is done by defining the application role "jmsRouter", which is mapped to the JAAS "oc4j-administrators" role, and specifying <method-permission> for all methods of the router's EJBs.
The init() method of the servlet within the router's Web model creates a router EJB object. Regardless of whether run-as is specified in web.xml for the servlet, a security exception is thrown:
@ oracle.oc4j.rmi.OracleRemoteException: anonymous is not allowed to call this EJB method, check your security settings (method-permission in ejb-jar.xml and security-role-mapping in orion-application.xml).
Workaround
The security warning can be removed by commenting out '*' in the <method-name> element of <method-permission> in ejb-jar.xml and explicitly enumerating all methods in AdminMgrBean that the jmsRouter role can access, as follows.
<!--
<method-permission>
<role-name>jmsRouter</role-name>
<method>
<ejb-name>AdminMgrBean</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
-->
<method-permission>
<role-name>jmsRouter</role-name>
<method>
<ejb-name>AdminMgrBean</ejb-name>
<method-name>getConfig</method-name>
</method>
</method-permission>
...
runAsRoleName is correctly parsed in ServletDescriptor.java, stored in info and thread in HttpApplication.loadServlet().
HTTP request parameters will not be available to servlet filters that are meant to be executed before dispatch of the request to a static resource (an .html file, for example). Note that filters that execute before dynamic resources, such as a servlet or JSP, will have access to the parameters.
This section describes release notes for EJB. It covers the following topics:
Section 5.3.4, "Stateful Session Bean Replication Trigger Configuration"
Section 5.3.5, "EJB 3.0 Entities and Application Server Control"
Section 5.3.6, "Entity and Session Deployment Attribute tx-retry-wait"
In this release, OC4J supports a subset of the functionality specified in the EJB 3.0 proposed final draft at http://jcp.org/aboutJava/communityprocess/pr/jsr220/index.html
For example, support for some EJB 3.0 features such as persistence API, external lifecycle listener class, and interceptors may not be compliant with the latest EJB 3.0 specification.
You may need to make code changes to your EJB 3.0 OC4J application after the EJB 3.0 specification is finalized and OC4J is updated to full EJB 3.0 compliance.
The Orion persistence manager is deprecated. Oracle recommends that you use OC4J and the TopLink persistence manager for new development. Using the migration tool, you can easily 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.
When using the (deprecated) Orion persistence manager with CMP and a non-Oracle database, OC4J does not read the schema XML file specified by the data-sources.xml file managed-data-source element schema attribute.
For example, consider the data-sources.xml and orion-ejb-jar.xml files shown in the following examples:
Example 5-1 Non-Oracle Database data-sources.xml
<connection-pool
name="ConnectionDB2"
max-connections="20"
min-connections="1">
<connection-factory
factory-class="com.oracle.ias.jdbcx.db2.DB2DataSource"
user="jdoe"
password="password"
url="jdbc:oracle:db2://server.foo.com:50000;...>
<property name="databaseName" value="appdb"/>
<property name="packageName" value="JDBCPKG"/>
<property name="serverName" value="server.foo.com"/>
<property name="portNumber" value="50000"/>
<xa-recovery-config>
<password-credential>
<username>jdoe</username>
<password>password</password>
</password-credential>
</xa-recovery-config>
</connection-factory>
</connection-pool>
<managed-data-source
connection-pool-name="ConnectionDB2"
schema="database-schemas/db2.xml"
jndi-name="jdbc/OracleDS"
name="OracleDS"
/>
Example 5-2 orion-ejb-jar.xml
<enterprise-beans>
<persistence-manager name="orion"/>
<entity-deployment name="EmployeeBean" max-tx-retries="0" location="EmployeeBean">
<primkey-mapping>
<cmp-field-mapping
name="empNo" persistence-name="empNo" persistence-type="integer"
/>
</primkey-mapping>
<cmp-field-mapping
name="empName" persistence-name="empName"
/>
<cmp-field-mapping
name="salary" persistence-name="salary"
/>
<finder-method lazy-loading="true">
<method>
<ejb-name>EmployeeBean</ejb-name>
<method-name>findAll</method-name>
<method-params></method-params>
</method>
</finder-method>
</entity-deployment>
</enterprise-beans>
Deploying this application will raise an error like:
Error creating table: [oias][DB2 JDBC Driver][DB2]ILLEGAL SYMBOL
To work around this problem, update the orion-ejb-jar.xml to manually define the mapping data types as Example 5-3 shows.
Example 5-3 Updated orion-ejb-jar.xml
<enterprise-beans>
<persistence-manager name="orion"/>
<entity-deployment name="EmployeeBean" max-tx-retries="0" location="EmployeeBean">
<primkey-mapping>
<cmp-field-mapping
name="empNo" persistence-name="empNo" persistence-type="integer"
/>
</primkey-mapping>
<cmp-field-mapping
name="empName" persistence-name="empName" persistence-type="varchar(255)"
/>
<cmp-field-mapping
name="salary" persistence-name="salary" persistence-type="double"
/>
<finder-method lazy-loading="true">
<method>
<ejb-name>EmployeeBean</ejb-name>
<method-name>findAll</method-name>
<method-params></method-params>
</method>
</finder-method>
</entity-deployment>
</enterprise-beans>
In this release, for stateful session beans, OC4J supports session-deployment attribute replication settings of:
inherited (default)
onShutdown
onRequestEnd
none
The replication attribute for stateful session beans cannot be configured in Application Server Control. The inherited value is never displayed and the value cannot be reset to none.
To work around this problem, for all stateful session beans, you must manually configure the orion-ejb-jar.xml file session-deployment element replication attribute.
When you deploy EJB 3.0 entities to OC4J, you cannot manage them using Application Server Control: when you use Application Server Control to view your EJB module, the Entity Beans area will display "No entity beans found".
You can manage all other EJB 3.0 beans such as session beans. For example, if you deploy an EJB module that contains both EJB 3.0 entities and EJB 3.0 session beans, your session beans will be visible through Application Server Control.
The orion-ejb-jar.xml file entity-deployment and session-deployment element tx-retry-wait attribute is not in orion-ejb-jar-10_0.xsd (nor in orion-ejb-jar.dtd).
You can still use this attribute in your orion-ejb-jar.xml file but if you do, do not configure OC4J to perform XML file validation (using the -validateXML option on the OC4J startup command line).
This section describes release notes for Web Services. It covers the following topics:
Section 5.4.2, "SoapFaultException Will Not Invoke a Handler's handleFault Method"
Section 5.4.3, "Clients Cannot Deserialize SOAP-Encoded anyType Arrays"
Section 5.4.5, "NLS Characters in SYS.XMLTYPE Values May Not be Supported"
Section 5.4.6, "Self Referential WSDL Imports Fail to Load in the Test Page"
Section 5.4.7, "SOAP 1.2 Results May Not be Properly Deserialized"
Section 5.4.10, "Multiple Service Elements in Top Down Web Service Assembly"
Section 5.4.11, "Multiple Message Formats in a WSDL Application"
Section 5.4.12, "Invalid Configuration Not Detected for EJB 2.1 Web Services"
Section 5.4.14, "Limitations on Top Down Processing of Type Mappings"
Section 5.4.15, "REST-Enabled Web Services Cannot be Deployed with Application Server Control"
Section 5.4.16, "Explicit HTTP Data Chunking is Not Supported"
Section 5.4.17, "Runtime Exception Masked By java.io.NotSerializableException"
Section 5.4.18, "Get NodeLists by Using getFirstChild and getNextSibling Instead of getChildNode"
If the combined length of the generated file and directory names passes a certain size limit, then deployment will fail and throw an error. This size limit varies for different operating systems. For example, on the Windows operating system, the size limit is 255 characters. - Bug 4673270
|
Note: You can avoid this problem by upgrading to a more recent version of the J2SE 5.0 JDK (jdk-1_5_0_06 or later). |
The length of the names is controlled by WebServicesAssembler and the deployment code. WebServicesAssembler generates file names based on the method name in the Java class or the operation name in the WSDL. The deployment code creates directories for code generation based on the names of the EAR and the WAR files.
To avoid the generation of file and directory names that are too long, limit the number of characters in the following names to a reasonable length.
Method names in Java classes
Operation names in the WSDL
Directory name for the location of the OC4J installation (also be aware that the JDeveloper's built-in OC4J instance is typically placed in a directory below the JDeveloper installation)
File name for a WAR file
File name for an EAR file
On the server, a SoapFaultException() thrown by an implementation class will not invoke a handler's handleFault() method. The handleResponse() method is called instead.
Clients of SOAP-encoded services are not able to deserialize arrays of type anyType.
Arrays may not be supported in document-literal encoding when mapped directly to a Java method parameter. This issue has been seen in DII and WSIF clients.
It also occurs in document-literal Web services that map base64Binary (or hexBinary) arrays to the type byte[][].
There are two possible ways to work around this issue:
Keep the wrapper by specifying the WebServicesAssembler argument unwrapParam="false".
Use RCP-encoded or RPC-literal styles.
In Database Web Services, NLS characters that occur in a SQL SYS.XMLTYPE value may not be properly handled.
The test page (Web Services Home Page) fails to load when using self-referential WSDL imports to the same application. For example:
location="http://samebox:8888/sameapp/import.wsdl"
Since the WSDL is available locally in the application, it should be referenced with a relative path instead. For example:
location="./import.wsdl"
In certain cases, the SOAP 1.2 response may not be properly deserialized, resulting in an element-name-mismatch exception. Specifically, this happens if the Web services returns output parameters and a result value, but this result element does not immediately follow after an http://www.w3.org/2003/05/soap-rpc result element.
WSIF invocations will map the primitive and nillable XML schema types to primitive Java types. This does not permit the representation of XML nil values.
As a work around, you may want to use SOAP-encoded XML types in the WSDL.
NLS 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 test page (Web Services Home Page).
WebServicesAssembler does not support multiple service elements for the topDownAssemble command.
Multiple message formats, such as RPC-encoded and document-literal, are not supported in a single Web application.
EJB 2.1 Web services will be deployed during server side code generation even if the configuration is incorrect.
This section describes Web Services schema features limitations. It covers the following topic(s):
Section 5.4.13.1, "Schema Features that are Mapped to a SOAPElement"
Section 5.4.13.2, "Derived complexTypes Are Not Handled Properly"
Section 5.4.13.3, "RPC Encoded Does Not Support Complex Types With Attributes"
If any of the following schema features are encountered in the WSDL, they will be mapped to a SOAPElement.
Any model group with multiple xsd:any elements
xsd:choice elements
Mixed content
Substitution groups
A type with multiple xsd:anyAttribute
If a complexType derives from another by adding some attributes, then once the complexType is run through the OC4J WSDL2Java tool, all of the attributes in the subtype will be deleted. If the subtype does not have additional elements, it will be presented as a SOAPElement in the generated Java code.
If you are able to edit the WSDL, then you can work around this problem in either of the following ways:
Move the attribute definitions from the sub type to the supertype.
Avoid using type extensions.
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 top 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.
You can specify the WebServicesAssembler ddFileName argument to define type mappings. A type mapping maps a schema type to an existing Java class and allows an optional custom serializer. In the top down use case, if you do not supply a custom serializer, then WebServicesAssembler will always generate a bean for the type.
The work around for this limitation is to ensure that the existing Java class is in the classpath given to WebServicesAssembler and that the overwriteBeans argument is set to false.
Application Server Control cannot successfully deploy EAR files containing REST-enabled Web services. Instead of using Application Server Control, you can use JDeveloper, Ant, or admin_client.jar to deploy the EAR file.
Enabling chunked data transfer for HTTP as described in Chapter 13 of the Oracle Application Server Web Services Developer's Guide by explicitly setting DO_NOT_CHUNK or CHUNK_SIZE properties will not have any effect. However, chunking will still be implicitly enabled when using attachments.
When the Web Service client is invoked by an EJB, the RMI protocol requires that the client parameter, return, and exception implement java.io.Serializable.In the current release, however, the oracle.j2ee.ws.common.util.localization.LocalizableSupport class does not implement java.io.Serializable. Consequently, exceptions thrown by a Web service client invoked by EJB are not properly returned to the invoker. Instead, the invoker receives the description below.
Error deserializing return-value: writing aborted;java.io.NotSerializableException:/@ oracle.j2ee.ws.common.util.localization.LocalizableSupport; nested /exception is:java.io.WriteAbortedException: writing aborted;java.io.NotSerializableException:/@ oracle.j2ee.ws.common.util.localization.LocalizableSupport/java.rmi.UnmarshalException: Error deserializing return-value: writingaborted; java.io.NotSerializableException:
You may see a performance degradation when iterating over a NodeList obtained by using node.getChildNode. This degradation will only be significant for NodeLists with very long lengths.
Instead of using the NodeList obtained by node.getChildNodes, 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
}
}
This section describes release notes for Web Services Security. It covers the following topic(s):
In release 10.1.3, you must use Application Server Control to obfuscate the keystore, signature key, and encryption key passwords. During obfuscation, an indirect user account is created in the system-jazn-data.xml file.
If you undeploy the application, these indirect user accounts are not removed. You must manually delete the them by using Application Server Control.
The following list describes how you can identify the names of indirect user accounts for global-level and port-level keystores and keys.
For a port-level keystore, the name of the indirect user account is created with the following format:
applicationName.portName.keystore.actual-keystore-name
For example:
my-security-sample.myport.keystore.myks.jks
For a global-level keystore, the name of the indirect user account is created with the following format:
default.keystore.actual-keystore-name
For example:
default.keystore.myks.jks
For port-level keys, the name of the indirect user account is created with the following format:
applicationName.portName.key.actual-key-alias
For example:
my-security-sample.myport.key.mysignkey
For global-level keys, the name of the indirect user account is created with the following format:
default.key.actual-key-alias
For example:
default.key.mysignkey
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), and XML Query Service (XQS).
The section contains release notes for the following OC4J Services:
This section describes release notes for JNDI. It covers the following topic(s):
Section 5.6.1.1, "New Package Names for RMI and Application Client Initial Context Factories"
Section 5.6.1.2, "These Environment Properties Are No Longer Supported"
Section 5.6.1.4, "Objects that Implement javax.naming.Referenceable Interface"
In this release, note the following new package names for the initial context factories:
oracle.j2ee.rmi.RMIInitialContextFactory
oracle.j2ee.naming.ApplicationClientInitialContextFactory
The following environment properties are no longer supported as of release 10.1.3:
dedicated.connection
dedicated.rmicontext
In release 10.1.3, the known ORMI /JNDI bugs that required these flags have been resolved. To enable client-side ORMI load-balancing in 10.1.3, use the oracle.j2ee.rmi.loadBalance property described in the "Load Balancing" section of the JNDI chapter of the Oracle Containers for J2EE Services Guide.
The package structure for context factories provided by previous releases of OC4J is deprecated, and is replaced by a more consistent naming structure. The following context factories are deprecated in release 10.1.3:
com.evermind.server.rmi.RMIInitialContextFactory
com.evermind.server.ApplicationClientInitialContext Factory
com.oracle.iiop.server.IIOPInitialContextFactory
For the new context factory names that replace the deprecated ones, see the java.naming.factory.initial initial context property described in the "Constructing a JNDI Context" section of the JNDI chapter of the Oracle Containers for J2EE Services Guide.
OC4J JNDI in 10.1.3 now provides full support for binding objects that implement the javax.naming.Referenceable interface
This section describes release notes for the Oracle Enterprise Messaging Service (OEMS). It covers the following topic(s):
Section 5.6.2.2, "OC4J May Fail to Restart after Abnormal OC4J Shutdown"
Section 5.6.2.3, "getconfigProperties() Lists Some Unsupported Properties"
OC4J cannot be started with OracleASjms, the pre-packaged standalone JMS Connector, undeployed without certain changes. This note deals with additional changes necessary to start OC4J while the default instance of the Oracle gJRA resource adapter, OracleASjms, is undeployed. For general undeployment of a resource adapter, see the Oracle Containers for J2EE Services Guide. 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.
If you encounter OC4J JMS Server startup problems after an abnormalOC4J shutdown, first check that no other OC4J JMS Server is running and using the same persistence files. Then remove any.lock files from the
ORACLE_HOME/j2ee/instance_name/persistence
directory 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.
The list of properties returned by the JMS Administrator MBean's getconfigProperties() method includes the following properties that are neither documented nor supported:
oc4j.jms.checkPermissions
oc4j.jms.j2ee14
oc4j.jms.noJmx
oc4j.jms.printStackTrace
oc4j.jms.rememberAllXids
This section describes release notes for Data Sources. It covers the following topics:
Section 5.6.3.3, "Converting Existing Data Sources to Release 3 Format"
Section 5.6.3.4, "Configuring OC4J instance for oci drivers"
The data sources subsystem has been completely rewritten. Part of the rewrite includes a new syntax for the configuration using the data-sources.xml file. The pre-10.1.3 syntax is still supported but users are encouraged to use the new syntax. Also users are encouraged to convert their existing application data-sources.xml files to the new syntax. See the Oracle Containers for J2EE Services Guide for details on converting data-sources.xml.
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 instead of oracle.jdbc.pool.OracleConnectionCacheImpl.
The OC4J 10.1.3 implementation understands the 10.1.3 and the pre-10.1.3 (10.1.2 and 9.0.4) formats of the data-sources.xml file. For an application that was previously used in a pre-10.1.3 OC4J implementation and contains its own data-sources.xml file, the OC4J 10.1.3 implementation automatically converts the data-sources.xml file from the pre-10.1.3 format to the 10.1.3 format when you use the Application Server Control Console to change anything in the data-sources.xml file, such as modifying an existing data source or creating or deleting a data source.
With an active OC4J instance in a standalone environment, you can alternatively use admin.jar with the following syntax to manually convert a pre-10.1.3 data-sources.xml file to the 10.1.3 format. This is discussed in the Oracle Containers for J2EE Configuration and Administration Guide. The guide does not mention that you can specify an ORMI URL only when OC4J is running or that the ORMI URL is optional.
java -jar admin.jar ormi://oc4jHost:oc4jOrmiPort adminId adminPassword -convertDataSourceConfiguration old-data-sources.xml new-data-sources.xml
You can also convert a data-sources.xml file before deployment, without a running OC4J instance. The syntax for this offline conversion is as follows:
java -jar admin.jar -convertDataSourceConfiguration old-data-sources.xml new-data-sources.xml
|
Notes:
|
Check for Consistency Between Your Application and the New data-sources.xml File
After conversion, whether manual or automatic, visually inspect the new data-sources.xml file and confirm that there is consistency between your application and the new file regarding the JNDI location used to refer to a data source. This is advisable because the new file may contain data source definitions that are not used.
This happens because the old format uses multiple location attributes (such as location, ejb-location, xa-location, and so on). The conversion to the new 10.1.3 format creates a separate data source in the new data-sources.xml file corresponding to each location attribute specified in the old data-sources.xml file. In most cases, client applications will only use the data source defined by either the location or ejb-location attribute. But we cannot be sure of this. Therefore, the converted data-sources.xml may have definitions that are not used by the applications and can be removed from the file.
You can also refer to examples of the new data-sources.xml format in the "Data Sources" chapter of the Oracle Containers for J2EE Services Guide.
If any application uses oci drivers for a datasource connection then, add the following <environment> section in opmn.xml for that particular OC4J instance. For example, if the application is deployed to the default home instance, then configure the OC4J instance as follows:
<ias-component id="OC4J">
<environment>
<variable id="SHLIB_PATH" value="$ORACLE_HOME/lib32" />
</environment>
<process-type id="home" module-id="OC4J" status="enabled">
This section describes release notes for OC4J Transaction Support. It covers the following topics:
Section 5.6.4.1, "Change the Default JTA Recovery Password Immediately"
Section 5.6.4.2, "New Configuration File for Transaction Manager"
Section 5.6.4.4, "The Mid-Tier Coordinator Does Not Use a Persistent Store By Default"
Section 5.6.4.5, "DMS must be enabled to obtain JTA statistics"
Section 5.6.4.6, "Transaction Propagation Between 10.1.3 Instances Only"
The default JTA recovery password should be changed immediately. OC4J is shipped with a default password, which should be changed after install. The recovery password is configured in the configuration file jazn-data.xml, which is in the $J2EE_HOME/config directory. To modify the transaction recovery password, change the credentials value for the user JtaAdmin in the jazn-data.xml file.
<user>
<name>JtaAdmin</name>
<display-name>JTA Recovery User</display-name>
<description>Used to recover propagated OC4J transactions</description>
<credentials>!newJtapassword</credentials>
</user>
Even if OC4J is configured to use a security service other than JAZN, such as OID the transaction recovery password must still be configured in jazn-data.xml.
All transaction-manager-related configuration is now done in the transaction-manager.xmlfile.
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 mid-tier coordinator does not use a persistent store by default. Prior to use in production, the mid-tier coordinator should be configured to use a persistent store which will enable transaction recovery.
To obtain JTA statistics, ensure that DMS is enabled.
Transaction propagation is only supported between 10.1.3 instances.
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:
Environment variables dedicated.connection and dedicated.rmicontext are not required for lookup using EJBs in 10.1.3
The dedicated.connection environment variable is still required for EJBs hosted in 10.1.2 being looked up from 10.1.3 - Bug 4895256
The RMI port may not be released immediately sometimes. - Bug 4892487
Old tunneling is deprecated. Use the new URL, as described in the "Configuring ORMI Tunneling through HTTP" section of the "RMI" chapter of the Oracle Containers for J2EE Services Guide.
Old package names for context factories deprecated and new names are recommended to be used, as described in the "Constructing JNDI Context" section of the "JNDI" chapter of the Oracle Containers for J2EE Services Guide.
Setting the JNDI property oracle.j2ee.rmi.loadBalance to either context or lookup currently creates separate ORMI connections for each call to new InitialContext. Closing the context does not cause the connection to be closed. Doing this repeatedly will result in performance degredation. - Bug 4902304
The following workaround is necessary for HTTP Tunnelling failover to work in iAS mode. This workaround applies to iAS mode, where the provider URL points to OHS using mod_oc4j. The workaround is not needed in standalone mode, where the provider URL lists multiple OC4J instances.- Bug 4599521
The workaround must be done for all OC4J server instances in the cluster, such as home1, home2, and so on.
Go to Application Server Control Console.
Select a server instance, such as "home".
In the instance window, select the Applications tab.
Select the "default" application.
In the Application:default window, select the Administration tab.
Select the Clustering Properties task.
Select the "Override parent application clustering settings" radio button. Specify Clustering Enable.
Click the OK button.
Repeat for each OC4J server instance.
Add the <distributable /> element to the <ORACLE_HOME>/j2ee/home/default-web-app/WEB-INF/web.xml file.
Restart the server using opmnctl stopall and then opmnctl startall.
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 XML Query Service (XQS). It covers the following topic(s):
The only arguments that the current implementation of the built-in XQuery functions fn:doc and fn:collection support are URLs with the "file" protocol that specify a path to a file on the local file system, as in this function call:
fn:doc("C:/MyDocuments/XQS/myView.xq")
The protocol part of the URL is always assumed to be "file" and can be omitted.
As an alternative to the fn:doc() function, you can use an XQS document function to access a document using any URL that Oracle Application Server supports. For example, a <document-source> element has the following configuration:
<document-source>
<function-name prefix="ns"> genericFile </function-name>
</document-source>
The XQS function genericFile() can be used in a query expression, as follows:
declare namespace ns = "…"; declare function ns:genericFile() external;
This section describes release notes for J2EE Connector Architecture (J2CA). It covers the following topics:
Section 5.7.2, "Cannot Cast a Connection Handle to a Concrete Type"
Section 5.7.4, "Set inactivity-timeout-check in oc4j-ra.xml"
Section 5.7.5, "Stop the Resource Adapter Before Redeploying It"
Unable to deploy multiple versions of a standalone RAR - Bug 4253861
A standalone RAR takes precedence over one in an application. When the same fully-qualified class exists in both a standalone RAR and also in a RAR deployed in an EAR, the class will always be loaded from the standalone RAR. - Bug 4415389
When stopping a resource adapter, OC4J does not always properly stop dependent applications.
OC4J wraps all connection handles with connection handle proxies to perform connection association and therefore connection handles can only be cast to interfaces implemented by the connection handle. An attempt to cast a connection handle to a concrete class will cause a ClassCastException.
NullPointerException occurs if an attempt is made to deploy an RAR when there is already an RAR deployed with the same name. - Bug 4884317
Set inactivity-timeout-check in the oc4j-ra.xml file. Changing the inactivity-timeout-check property for an RAR connection pool with ASControl does not work properly. This property should be set to the proper value in the oc4j-ra.xml file prior to deploying the resource adapter. - Bug 4455421
When a resource adapter with active endpoints is redeployed without stopping it first, OC4J throws a DeployerException due to active endpoints. To work around this issue, stop the resource adapter prior to redeploying it. - Bug 4740441
XA transaction recovery can be configured using Application Server Control using the following steps:
In the Connection Factories tab accessed from the Resource Adapter Home page for the appropriate resource adapter, choose the JNDI location of the connection factory that you want to configure.
In the Options tab of the resulting Edit Connection Factory page, you can do any of the following:
Add a new user name.
After specifying the user name, you can specify a password directly or indirectly. For a direct password, choose Password and type the password itself.
For an indirect password, choose Indirect Password and type a key (which might just be the user name, for example). OC4J uses the key to do a lookup in the User Manager (specifically, in the jazn-data.xml file).
Change an existing user name or password
Changes to work manager thread pool properties from ASControl are not persisted to the server.xml file if there is no <work-manager-thread-pool> element defined. - Bug 4871940
This section describes release notes for the OracleAS JAAS Provider in Release 10.1.3.0.0. It covers the following topics:
Section 5.8.2, "Restart Application After Configuring Through Security Provider MBean"
Section 5.8.3, "Necessary Permission Grants When Using Security Manager"
Section 5.8.5, "JAAS Policy Configuration with Custom Realms"
Section 5.8.6, "User Manager Delegation for the File-Based Provider"
Section 5.8.7, "JNDI Context Pool Timeout Property for Oracle Internet Directory"
Section 5.8.8, "Miscellaneous OracleAS JAAS Provider and Security Release Notes"
The initial version of the 10.1.3.0.0 OC4J Release Notes pointed out that as of the 10.1.3.0.0 release, you cannot use the COREid Access security provider for J2EE Web applications deployed in 10.1.3 OC4J. This update is to point out that, in fact, you cannot yet use any functionality through the COREid custom login module. In other words, COREid integration with Web and EJB applications will not be supported until a patch is made available. (Because the Oracle Web Services Manager agent covers integration with COREid, there *is* COREid integration for Web services in the 10.1.3.0.0 implementation.) Refer to OracleMetaLink to check the status of the future 10.1.3.0.0 patch set. - Bugs 4887466, 4772443, 4745790
Whenever a configuration change is made using Application Server Control or the OC4J security provider MBean, the application must be restarted. Until the application is restarted, all other operations of the security provider MBean are invalidated and will return the following message: "The security provider has been changed. Operation temporarily invalidated till application or OC4J restart."
Users running with a SecurityManager in an Oracle Application Server environment should be aware that if an OC4J instance name other than home is used, adding the following permission grants to ORACLE_HOME/j2ee/instance_name/config/java2.policy will be necessary for proper operation of OC4J:
grant codebase
"file:${oracle.home}/j2ee/${oracle.oc4j.instancename}/connectors/OracleASjms/OracleASjms/gjra.jar" {
permission java.security.AllPermission;
};
grant codebase "file:
${oracle.home}/j2ee/${oracle.oc4j.instancename}/connectors/datasources/datasources/datasources.jar"
{
permission java.security.AllPermission;
};
(Failure to add these does not compromise security but may hinder OC4J operations.) - Bug 4942880
If you choose to use indirect passwords in the OC4J 10.1.3.0.0 implementation, an indirect user is created in the system-jazn-data.xml file when you use this feature. 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.
When you use custom realms, and JAAS policies are granted to users or roles in the custom realm, you should do the following:
In the <jazn> element of your application orion-application.xml file, specify a default-realm setting of "custom_realm_name".
Do not specify a location attribute setting in the <jazn> element.
Set the jaas.username.simple property to "false" in jazn.xml, using a <property> subelement of the <jazn> element.
These steps allow the custom realm and its users, roles, and policies to be persisted in system-jazn-data.xml.
Note that to use JAAS authorization, in particular to grant permissions to users or roles in a custom realm, the custom realm and its users and groups must be defined and persisted in system-jazn-data.xml, not in a jazn-data.xml file deployed in the application EAR file.
Before HTTP requests can be dispatched to the target servlet, the OracleAS JAAS Provider JAZNUserManager coordinates authentication. JAZNUserManager supports the OC4J UserManager delegation model, but effectively this applies only to the file-based provider. With delegation, if a user or group is not found at the application-level JAZNUserManager instance, the request is delegated to the parent user manager.
Specifically, note the following restrictions and additional details:
If the application and parent application are both configured to use the file-based provider, delegation goes up through the parent hierarchy as far as necessary, until a parent is not configured to use the file-based provider. Delegation is not propagated beyond that point.
If the application is configured to use the file-based provider, and the parent is configured to use the LDAP-based provider, an external LDAP provider, or a custom login module, there is no delegation support.
If the application itself is configured to use the LDAP-based provider, an external LDAP provider, or a custom login module, there is no delegation support.
|
Note: In OC4J, thesystem application is at the root of the hierarchy, but the default application is the default parent of any deployed application. Both use system-jazn-data.xml as the user repository. |
For the LDAP-based provider (Oracle Internet Directory), the OC4J 10.1.3 implementation includes a new property, JNDI_CTX_POOL_TIMEOUT, that you can set in order to specify a timeout for the JNDI context pool. This may be useful, for example, when there is a firewall between the middle tier, including OracleAS JAAS Provider, and the Oracle Internet Directory. The timeout on the firewall connection could be coordinated with the timeout of the directory context.
Set this property through a <property> subelement of the <jazn> element in the jazn.xml file, specifying the timeout in milliseconds. The following example specifies a timeout of 5 seconds.
<jazn ... > <property name="JNDI_CTX_POOL_TIMEOUT" value="5000"> ... </jazn>
Although it is already stated in the 10.1.3.0.0 OC4J Security Guide, make special note of the fact that the OC4J administration account, admin in previous releases, has changed to oc4jadmin.
Security context propagation is supported only between OC4J 10.1.3 instances.
This section describes known errors in the OC4J documentation in Oracle Application Server 10g Release 3 (10.1.3). It covers the following book(s):
This section describes Web Services documentation errata. It covers the following topic(s):
Book: Oracle Application Server Web Services Developer's Guide
Chapter 4, "OracleAS Web Services message Formats", Section: "Selecting Message Formats"
The list of WebServicesAssembler commands that can use the use and style arguments includes genInterface. This is an error. The genInterface command cannot use these arguments.
Book: Oracle Application Server Web Services Advanced Developer's Guide
Chapter 8, "Using JMS as a Web Service Transport", Section: "Assembling a Web Service Bottom Up that Uses JMS Transport"
In Step 1, there is a missing closing angle bracket in the <oracle:porttype clause, at the end of the sendConnectionFactoryLocation attribute. The <oracle:porttype clause should read as follows:
...
<oracle:porttype
interfaceName="oracle.j2ee.ws.jmstransport.Echo"
className="oracle.j2ee.ws.jmstransport.EchoImpl"
>
<oracle:port
uri="/echo"
sendQueueLocation="jms/senderQueue"
name="EchoPort"
sendConnectionFactoryLocation="jms/senderQueueConnectionFactory">
</oracle:port>
...
This section describes errors in the Oracle Application Server Advanced Web Services Developer's Guide. It covers the following item(s):
The Oracle Application Server Advanced Web Services Developer's Guide Chapter 6, "Auditing and Logging Messages" lists the paths to the auditing and logging log.xml files as: <ORACLE_HOME>\log\wsmgmt\logging\log.xml and <ORACLE_HOME>\log\wsmgmt\audit\log.xml
These paths are incorrect. The correct paths are: <ORACLE_HOME>\j2ee\<OC4J_instance_name>\log\wsmgmt\auditing\log.xml and <ORACLE_HOME>\j2ee\<OC4J_instance_name>\log\wsmgmt\logging\log.xml
This section describes errors in the Oracle Containers for J2EE Services Guide. It covers the following item(s):
In the Oracle Containers for J2EE Services Guide Chapter 4, "Data Sources", the "Enabling Fast Connection Failover in the data-sources.xml File" section, in the native data source example for fast connection failover labelled "Enabling Fast Connection Failover in the data-sources.xml File" is incorrect.
The url is not correct for a RAC environment.
The brackets in the <native-data-source> element do not match correctly.
The INCORRECT example is as follows:
<native-data-source> name="nativeDataSource" jndi-name="jdbc/nativeDS" description="Native DataSource" data-source-class="oracle.jdbc.pool.OracleDataSource" user="scott" password="tiger" url="jdbc:oracle:thin:@localhost:1521:oracle"> <property name="connectionCacheName" value="ICC1"/> <property name="connectionCachingEnabled" value="true"/> <property name="fastConnectionFailoverEnabled" value="false"/> </native-data-source>
A CORRECT example is as follows:
<native-data-source name="nativeDataSource" jndi-name="jdbc/nativeDS" description="Native DataSource" data-source-class="oracle.jdbc.pool.OracleDataSource" user="scott" password="tiger" url="jdbc:oracle:thin:@(DESCRIPTION= (LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=TCP)(HOST=host1) (PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=service_name)))"> <property name="connectionCacheName" value="ICC1"/> <property name="connectionCachingEnabled" value="true"/> <property name="fastConnectionFailoverEnabled" value="false"/> </native-data-source>
This section describes issues associated with Oracle Application Server Containers for J2EE Job Scheduler. It includes the following topics:
Section 5.10.1, "Invalid Data Source Configuration May Result in Initialization Exception"
Section 5.10.3, "Lower Than Expected Throughput may be Experienced for Large Number of Jobs"
Section 5.10.4, "Removing a Job May Impact Job Scheduler Event Listener Processing"
Section 5.10.5, "Preemptory Shutdown of OC4J Container may Prevent Subsequent Restart"
In the JDBC persistence configuration, a null pointer exception results on container startup if the associated data source is improperly configured or the database server is not up.
There is no workaround for this issue; make sure the data sources are configured correctly and the target database is up.
If the Cancel API is invoked within a JTA transaction, all outstanding executions are canceled synchronously, not after the transaction is committed.
There is no workaround for this issue.
Lower than expected execution throughput may be observed when there are large burst jobs with concurrent schedules.
To work around this issue, disable the management bean and DMS statistics publication in order to increase throughput. This can be accomplished by setting the value of the following environment entries in the Job Scheduler configuration to false:
oracle.ias.scheduler.dms
oracle.ias.scheduler.jmx
Removing a job in the JMS persistence configuration may result in event processing delays. This behavior is exacerbated in a deployment where jobs are created and removed with high frequency.
To work around this issue, disable the management bean and DMS statistics publication in order to increase throughput. This can be accomplished by setting the value of the following environment entries in the Job Scheduler configuration to false:
oracle.ias.scheduler.dms
oracle.ias.scheduler.jmx
The JMS server creates recover lock files in the $ORACLE_HOME/j2ee/home/persistence directory. As a result of a preemptory shutdown, these files may not be properly cleaned up and may prevent the container from restarting. Refer to the JMS release notes for more information.
This issue is only pertinent to Job Scheduler running in a JMS persistence environment.
