| Oracle® Application Server Release Notes 10g Release 3 (10.1.3.1.0) for Microsoft Windows B31012-02 |
|
 Previous |
 Next |
| Oracle® Application Server Release Notes 10g Release 3 (10.1.3.1.0) for Microsoft Windows B31012-02 |
|
Previous |
Next |
This chapter discusses release notes for Oracle Containers for J2EE (OC4J) for 10.1.3.1.0. It includes the following topics:
Section 12.1, "Configuration, Deployment, and Administration Issues and Workarounds"
Section 12.3, "JavaServer Pages (JSP) Issues and Workarounds"
Section 12.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:
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
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. |
This section describes release notes for servlets. It covers the following topic(s):
Section 12.2.1, "Servlet Invocation by Classname Disabled by Default"
Section 12.2.2, "Enabling Access Logging for Web Applications"
Section 12.2.3, "OC4J 10.1.3.1.0 Honors Session id Value Differently"
Section 12.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.
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
This section describes release notes for EJBs. It covers the following topics:
In release 10.1.3.1.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 From 10.1.3.0 TopLink JPA Preview Persistence" 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.
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 12.5.2.1, "Multiple Service Elements in Top Down Web Service Assembly"
Section 12.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"/>
This section describes problems that might arise in how OracleAS Web Services interprets WSDL files.
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.
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 12.5.5.1, "Recursive Schema Definitions Are Not Supported in the Web Services Test Page"
Section 12.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:
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
}
}
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:
Section 12.6.1.2, "Wrong Provider URL in the jndi.properties File"
Section 12.6.1.3, "New Package Names for RMI and Application Client Initial Context Factories"
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 following InitialContext factories are deprecated:
com.evermind.server.RMIInitialContextFactory
com.evermind.server.ApplicationClientInitialContextFactory
com.oracle.iiop.server.IIOPInitialContextFactory
The new package names for the initial context factories are:
oracle.j2ee.rmi.RMIInitialContextFactory
oracle.j2ee.naming.ApplicationClientInitialContextFactory
oracle.j2ee.iiop.IIOPInitialContextFactory
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 12-1 lists.
Table 12-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. |
This section describes release notes for the Oracle Enterprise Messaging Service (OEMS). It covers the following topics:
Section 12.6.2.1, "Error Starting OC4J after OracleASjms is Undeployed"
Section 12.6.2.2, "OC4J May Fail to Restart after Abnormal OC4J Shutdown"
Section 12.6.2.3, "XA-styled JMS Connections Not Supported Between OC4J Versions"
Section 12.6.2.4, "JMS Auto-Enlisting in Global Transactions is Desupported"
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.
This section describes release notes for Data Sources. It covers the following topics:
Section 12.6.3.1, "The oracleFatalError method is no Longer Available"
Section 12.6.3.3, "Orion CMP Fails Due to JDBC Driver Clash"
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.
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.
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.
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 12.7.1, "New Class Loader Architecture for Standalone Resource Adapters"
Section 12.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.
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.
