|
Oracle® Application Server 10g Forms and Reports Services Upgrade Guide
10g (9.0.4) for UNIX Part No. B13547-01 |
|
|
|
|
Oracle® Application Server 10g Forms and Reports Services Upgrade Guide
10g (9.0.4) for UNIX Part No. B13547-01 |
|
|
|
|
This chapter describes tasks you may need to perform to complete the upgrade after the OracleAS Upgrade Assistant has finished processing. Some or all of these may be necessary, depending on the configuration upgraded. This section discusses the following topics:
Section 3.1, "Completing the Oracle Application Server Containers for J2EE (OC4J) Upgrade"
Section 3.2, "Completing the Oracle HTTP Server Upgrade"
Section 3.3, "Completing the OracleAS Web Cache Upgrade"
Section 3.4, "Completing the Oracle Application Server Forms Services Upgrade"
Section 3.5, "Completing the Oracle Application Server Reports Services Upgrade"
Section 3.6, "Upgrading the tnsnames.ora File"
Section 3.7, "Disabling Oracle Application Server Single Sign-On in the Upgraded Instance"
Section 3.8, "Port Values and the portlist.ini File After Upgrade"
Section 3.9, "Upgrading Application Server Clusters"
Section 3.10, "Starting the Upgraded Forms and Reports Services Instance"
Section 3.11, "Validating the Forms and Reports Services Upgrade"
Section 3.12, "Considerations for the Source Oracle Home After Upgrade"
The OracleAS Upgrade Assistant performs many of the Oracle Application Server Containers for J2EE (OC4J) upgrade tasks. However, some components of OC4J may require manual adjustments, or may have characteristics of which you should be aware before using OracleAS 10g (9.0.4).
This section details upgrade considerations for some sub-components of OC4J. If you use Oracle JMS, Oracle JDBC, the XML Parser for JAXP/XDK, or Oracle JSP pages, some or all of the topics in this section may be useful to you.
The OracleAS Upgrade Assistant does not upgrade the JAZN settings (the orion-application.xml file). Therefore, if you upgraded OC4J applications that use the JAZN LDAP User Manager for security, to complete the upgrade, you must perform the following steps:
Using the Oracle Enterprise Manager Application Server Control, in the General Properties section of the OC4J application, under User Manager, select the JAZN LDAP User Manager.
In the Security Settings section of the OC4J application, under Security Roles, map Users/Groups to the same role defined in the source Oracle home.
In Oracle Application Server 10g (9.0.4), the jazn.jar file has been split into two JAR files: jazn.jar and jazncore.jar. For this reason, after upgrading OC4J applications that use JAZN, both JAR file names must have library path entries in the application.xml file.
Ensure that the application.xml file contains both of the entries below:
<library path="904 J2EE HOME/jazn.jar"/>
<library path="904 J2EE HOME/jazncore.jar"/>
where
<904 J2EE HOME> = <destination_MT_OH>/j2ee/home
Customizations that were made to OC4J instances in the file must be upgraded manually. This includes the instances created by the installer (home, OC4J_WIRELESS, OC4J_DEMOS, OC4J_PORTAL OC4J_BI_FORMS). The OracleAS Upgrade Assistant upgrades customizations to OC4J instances that were created by the user.
If you have customized entries in the application.xml file, such as library paths, Java options, and OC4J options, you must upgrade them manually.
The jms.xml file is not automatically upgraded from earlier versions. All queues, topics, and connection factories defined in the jms.xml file in the source Oracle home must be added to the jms.xml file in the destination Oracle home.
In Oracle Application Server 10g (9.0.4), OC4J by default complies with the J2EE 1.3 specification. In some cases, this results in behavior that differs from that seen with previous OC4J implementations. To allow for backward compatibility, OC4J supports a CTS compliance flag that you can set to false to revert to previous OC4J behavior in the following components:
Oracle JMS
Oracle JDBC
Oracle XML parser for JAXP/XDK
The compliance behavior of OC4J is determined by the flag oracle.cts.useCtsFlags, with a default value of true. If any of the upgrade issues are critical in a particular application, you can disable CTS compliance and revert to old behavior for an OC4J instance by setting the flag value to false in an OC4J properties file, and providing the location of the properties file to OC4J.
For example, the file <destination_MT_OH>/j2ee/home/config/oc4j.properties might contain the flag:
oracle.cts.useCtsFlags=false
Supply the name and location of a properties file to OC4J through an <oc4j-option element in the <destination_MT_OH>/opmn/conf/opmn.xml file, as in the following example:
Example 3-1 oc4j-option Element in opmn.xml File
<oc4j> ... <oc4j-option value="-p <destination_MT_OH/j2ee/home/config/oc4j.properties"/> ... </oc4j>
This is equivalent to starting OC4J as follows in standalone mode (where % is a system prompt):
Example 3-2 Starting OC4J in Standalone Mode
% java -jar oc4j.jar -p <destination_MT_OH/j2ee/home/config/oc4j.properties
In the OracleAS 10g (9.0.4) implementation of Oracle JMS (OJMS), which complies with J2EE 1.3, some behavior differs from OJMS behavior in Oracle9iAS Release 1 (1.0.2.2). (There are no such upgrade considerations between Oracle9iAS releases 9.0.2 and 9.0.3.) The differences are as follows:
JMSExpiration—In the OJMS 10g (9.0.4) J2EE 1.3-compliant implementation, the JMSExpiration header value in a dequeued message is the sum of the JMS timestamp when the message was enqueued, and the time-to-live. This value is expressed in milliseconds from midnight, January 1, 1970 to the current Greenwich Mean Time. If a message never expires, the value is 0.
In the OJMS 1.0.2.2 implementation, the JMSExpiration header value in a dequeued message is the duration until expiration of the message, in milliseconds. If a message never expires, the value is -1.
JMSPriority—In the OJMS Release 2 (9.0.4) 1.3-compliant implementation, 9 is the highest priority, 0 is the lowest priority, and 4 is the default priority.
In the OJMS 1.0.2.2 implementation, java.lang.Integer.MIN_VALUE is the highest priority, Integer.MAX_VALUE is the lowest priority, and 1 is the default priority.
Durable subscribers—In the OJMS 10g (9.0.4) J2EE 1.3-compliant implementation, durable Topic Subscribers with the same name are not allowed under any circumstances.
In the OJMS 1.0.2.2 implementation, durable Topic Subscribers with the same name are allowed if they are subscribed to different topics.
Strongly typed JMS selectors—In accordance with the JMS 1.02b specification and J2EE 1.3 compliance requirements, the OJMS 10g (9.0.4) implementation uses only a certain subset of SQL92 syntax for selector expression syntax, with the following mandated restrictions:
Selector expressions are strongly typed, meaning operators and operands in arithmetic comparisons must be of the same type. Automatic type conversions for the purpose of comparison, such as converting the string "1" to the integer 1, are prohibited.
String and boolean comparisons are restricted to "=", "<", and ">". Two strings are equal only if they contain the exact same sequence of characters.
The OJMS 1.0.2.2 implementation is not subject to these restrictions or to the limited subset of SQL92 syntax for selector expression syntax.
In the OracleAS 10g (9.0.4) implementation of Oracle JDBC, which complies with J2EE 1.3, some behavior differs from JDBC behavior in Oracle9iAS Release 2 (9.0.2) and prior. The differences are as follows:
Java types for NUMBER columns—In 10g (9.0.4), the getObject() method of a result set (java.sql.ResultSet instance) returns a java.lang.Double value for a NUMBER column with precision, or a java.math.BigDecimal value for a NUMBER column without precision.
In Release 2 (9.0.2) and prior releases, getObject() returns a BigDecimal value for any NUMBER column.
Metadata for NUMBER columns—In 10g (9.0.4), the getColumnTypeName() method of a result set metadata object (java.sql.ResultSetMetaData instance) returns "FLOAT" for a NUMBER column with precision, or "NUMBER" for a NUMBER column without precision. The getColumnType() method returns java.sql.Types.FLOAT for a NUMBER column with precision, or Types.NUMBER for a NUMBER column without precision.
In Release 2 (9.0.2) and prior releases, getColumnTypeName() returns "NUMBER" for any NUMBER column, and getColumnType() returns Types.NUMBER for any NUMBER column.
Java types for DATE and TIMESTAMP columns—In 10g (9.0.4), the getObject() method of a result set returns a java.sql.Date value for a DATE column, and a java.sql.Timestamp value for a TIMESTAMP column.
In Release 2 (9.0.2) and prior releases, getObject() returns a java.sql.Timestamp value for a DATE column. (TIMESTAMP columns were not supported.)
Exceptions for inappropriate SQL statements—In 10g (9.0.4), if an executeQuery() call in a statement object contains anything but a SELECT statement (such as if it instead contains an INSERT or UPDATE statement), the JDBC driver properly throws an exception. Similarly, if an executeUpdate() call contains a SELECT statement, the driver properly throws an exception. (An UPDATE, INSERT, or DELETE statement is expected.)
In Release 2 (9.0.2) and prior releases, these situations did not result in exceptions.
In the OracleAS 10g (9.0.4) implementation of the XML parser for JAXP/XDK, which complies with J2EE 1.3, some behavior differs from XML parser behavior in Oracle9iAS Release 2 (9.0.2) and prior. The differences are as follows:
getNamespaceURI() null return values—In 10g (9.0.4), the getNamespaceURI() method returns 'null' if the namespace is not defined for an element or attribute.
In Release 2 (9.0.2) and prior releases, the getNamespaceURI() method returns '""' in these circumstances.
getLocalName() null return values—In 10g (9.0.4), the getLocalName() method returns 'null' if the element or attribute was created using a DOM level 1 API call to createElement() or createAttribute().
In Release 2 (9.0.2) and prior releases, the getLocalName() method returns '"Transfer interrupted!"' in these circumstances.
getPrefix() null return values—In 10g (9.0.4), the getPrefix() method returns 'null' if the element or attribute was created using a DOM level 1 API call to createElement() or createAttribute().
In Release 2 (9.0.2) and prior releases, the getPrefix() method returns '""' in these circumstances.
|
Note: ThegetNamespaceURI(), getLocalName(), and getPrefix() methods exist with the above changes in the XMLElement and XMLAttr classes of the oracle.xml.parser.v2 package.
|
SAX exceptions—In 10g (9.0.4), registered error handlers throw a SAXException or SAXParseException in error conditions.
In Release 2 (9.0.2) and prior releases, error handlers throw an XMLParseException in error conditions.
I/O exceptions—In 10g (9.0.4), an IOException is thrown as is in I/O error conditions.
In Release 2 (9.0.2) and prior releases, an IOException is wrapped in an XMLParseException.
Beginning with Oracle9iAS Release 2 (9.0.3), Oracle Application Server Containers for J2EE complies with the J2EE 1.3 specification and implements the Enterprise Java Beans (EJB) 2.0 specification in entirety. Therefore, if you are upgrading from Release 2 (9.0.2) to 10g (9.0.4), applications using EJB features in the areas of container-managed persistence and container-managed relationships will require modification.
|
See Also: Oracle Application Server Containers for J2EE Enterprise JavaBeans Developer’s Guide, Appendix C. |
This section describes JSP settings that are affected by the upgrade.
Beginning with Oracle9iAS Release 2 (9.0.3), the OC4J JSP container by default imports the packages listed below into any JSP page, in accordance with the JSP specification. No page directive import settings are required.
javax.servlet.*
javax.servlet.http.*
javax.servlet.jsp.*
In previous releases, the following packages were also imported by default:
java.io.*
java.util.*
java.lang.reflect.*
java.beans.*
For backward compatibility, you can use the JSP extra_imports configuration parameter as a workaround. Alternatively, you can add desired imports through page directives or global includes. See the Oracle Application Server Containers for J2EE Support for JavaServer Pages Developer’s Guide for information about these topics.
When upgrading to Oracle Application Server 10g (9.0.4) and using JSP pages, use appropriate settings for the following important JSP configuration parameters.
check_page_scope
forgive_dup_dir_attr
These are set as initialization parameters for the JSP front-end servlet, either in the global-web-application.xml file or in the application orion-web.xml file. Here is an example:
Example 3-3 JSP Configuration Parameters for Upgrading to 10g (9.0.4)
<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>oracle.jsp.runtimev2.JspServlet</servlet-class>
<init-param>
<param-name>check_page_scope</param-name>
<param-value>true</param-value>
</init-param>
...
</servlet>
See the Oracle Application Server Containers for J2EE Support for JavaServer Pages Developer’s Guide for more information about JSP configuration parameters.
check_page_scope (boolean; default: false): This parameter was introduced in Oracle9iAS Release 2 (9.0.3). For OC4J environments, set it to true to enable Oracle-specific page-scope checking by the JspScopeListener utility.
This parameter is not relevant for non-OC4J environments. For JServ, Oracle-specific page-scope checking is always enabled. For other environments, the Oracle-specific implementation is not used and you must use the checkPageScope custom tag for JspScopeListener page-scope functionality. See the Oracle Application Server Containers for J2EE JSP Tag Libraries and Utilities Reference for information about JspScopeListener.
forgive_dup_dir_attr (boolean; default: false): This parameter was introduced in Oracle9iAS Release 2 (9.0.3). Set it to true to avoid translation errors in a JSP 1.2 environment such as OC4J if you have duplicate settings for the same directive attribute within a single JSP translation unit (a JSP page plus anything it includes through include directives).
The JSP 1.2 specification directs that a JSP container must verify that directive attributes, with the exception of the page directive import attribute, are not set more than once each within a single JSP translation unit.
The JSP 1.1 specification did not specify such a limitation. OC4J offers the forgive_dup_dir_attr parameter for backward compatibility.
Among the migration considerations in moving to a Sun Microsystems JDK 1.4 environment, which is the environment that is shipped with Oracle Application Server 10g (9.0.4), there is one of particular importance to servlet and JSP developers.
As stated by Sun Microsystems, "The compiler now rejects import statements that import a type from the unnamed namespace." (This was to address security concerns and ambiguities with previous JDK versions.) Essentially, this means that you cannot invoke a class (a method of a class) that is not within a package. Any attempt to do so will result in a fatal error at compilation time.
This especially affects JSP developers who invoke JavaBeans from their JSP pages, as such beans are often outside of any package (although the JSP 2.0 specification now requires beans to be within packages, in order to satisfy the new compiler requirements). Where JavaBeans outside of packages are invoked, JSP applications that were built and executed in an OC4J 9.0.3 / JDK 1.3.1 or prior environment will no longer work in an OC4J 9.0.4 / JDK 1.4 environment.
Until you update your application so that all JavaBeans and other invoked classes are within packages, you have the alternative of reverting back to a JDK 1.3.1 environment to avoid this issue.
For more information about the "classes not in packages" issue and other JDK 1.4 compatibility issues, refer to the following Web site:
http://java.sun.com/j2se/1.4/compatibility.html
In particular, click the link "Incompatibilities Between Java 2 Platform, Standard Edition, v1.4.0 and v1.3".
When upgrading to Oracle Application Server 10g (9.0.4) and using servlets, consider the following changes in servlet APIs and behavior:
Changes relating to getRequestURI()
Changes regarding filtering of servlets that are forward or include targets
In previous Oracle9iAS releases, whenever Oracle HTTP Server received a request, it would unencode the URI before passing it to OC4J. Therefore, servlets making computations based on the response of getRequestURI() (a method on the request object) were implicitly getting a value that had been unencoded one time. As of the OC4J 9.0.4 implementation, Oracle HTTP Server will send OC4J an unaltered version of the URI, which in turn is used by OC4J as the return value of getRequestURI().
If the mod_rewrite module is being used in conjunction with mod_oc4j in communications between Oracle HTTP Server and OC4J, the rewritten URI that is sent to mod_oc4j is the same as what is sent to OC4J, and the return value of getRequestURI() will have had mod_rewrite rules applied to it.
The mod_rewrite and mod_oc4j modules are discussed in the Oracle HTTP Server Administrator’s Guide. Further details about mod_rewrite are available in the Apache Server documentation.
In previous OracleAS releases, if a filtered servlet forwards to or includes another servlet, the target servlet, by default, is also filtered. In Oracle Application Server 10g (9.0.4), this is no longer the default behavior. Having the target servlet not filtered by default matches the intention of the servlet specification.
This behavior is configurable: in the OC4J 9.0.4 implementation, it is according to the oracle.j2ee.filter.on.dispatch environment flag (false by default); in future implementations, it will be according to web.xml configuration as set forth in the servlet 2.4 specification.
This section describes post-upgrade tasks for the Oracle HTTP Server that you may need to perform. The OracleAS Upgrade Assistant upgrades the standard settings for the Oracle HTTP Server. If you have configuration files or documents that are in non-standard locations or referenced in non-standard ways, you must upgrade these manually. These, and other configuration-specific cases for manual upgrade, are detailed below.
If you want the Oracle HTTP Server to listen on a port numbered lower than 1024: The HTTP server executable apachectl must have root user privileges to bind to ports numbered lower than 1024. Follow these steps to grant root privileges to the executable:
Log in to the root account.
Navigate to <destination_MT_OH>/Apache/Apache/bin and issue these commands:
chown root .apachectl
chmod 6750 .apachectl
Exit the root account.
If mod_osso was configured: If mod_osso was configured, after upgrade, the osso.conf file continues to use the Release 2 (9.0.2) partner entry in the Single Sign-On server. The 10g (9.0.4) partner entry in the Single Sign-On server is not being used, and will cause a broken link (invalid URL) when the application logs out. You should remove the 10g (9.0.4) partner entry. In addition, if the name of the entry in use is obsolete (in that it refers in some way to the source Oracle home), you may wish to rename it.
If there are configuration files in non-default locations: If httpd.conf, mod_oc4j.conf, mod_osso.conf and moddav.conf files are not in the default location, you must upgrade them manually by applying the customizations in the files in the source Oracle home to the files in the destination Oracle home.
If there are custom files and directories referenced by Oracle HTTP Server configuration files: Because the OracleAS Upgrade Assistant only upgrades the items listed in Section A.1.4.1, "OHS Upgrade Items" on page A-7 of Oracle Application Server 10g Upgrading to 10g (9.0.4), there could be files or directories referred to by directives such as Alias, mod_rewrite, and log directives, such as ErrorLog, that are not present after the upgrade. Ensure that all such items are upgraded manually and exist in the locations expected by the directives. If these files or directives are missing after the upgrade, the Oracle HTTP Server may not start. You can identify errors by starting the Oracle HTTP Server individually after the upgrade, and examining the <destination_MT_OH>/Apache/Apache/logs/error_log for errors associated with these items.
If there are Dynamic Monitoring Service (DMS) configuration elements in the httpd.conf and mod_oc4j.conf files: You must relocate these configuration elements into the dms.conf file.
If Oracle Application Server Web Cache is the first listener: If OracleAS Web Cache is configured as the first listener, ensure that the Oracle HTTP Server directives listed in Table 3-1 have the same values as the corresponding OracleAS Web Cache elements. In particular, note that the Oracle HTTP Server Port directive specifies the port number of a front-end load balancer or reverse proxy. Thus, if Oracle Application Server Web Cache is used, then the Oracle HTTP Server Port directive should have the value of the port on which OracleAS Web Cache is listening.
If you have static documents in the default DocumentRoot directory that you want to upgrade: The OracleAS Upgrade Assistant locates static document files and directories for upgrade in the location specified in the DocumentRoot directive. The DocumentRoot directive defines the location for static documents and related directories. The base server has a document root location, and each virtual host has one. The OracleAS Upgrade Assistant copies files under these directories to the destination Oracle home. The default DocumentRoot directory <source_MT_OH>/Apache/Apache/htdocs contains demonstration programs and release notes placed there by the installer, so the OracleAS Upgrade Assistant does not upgrade this directory. You must upgrade this directory manually.
This section outlines tasks you may need to perform to complete the OracleAS Web Cache upgrade after the OracleAS Upgrade Assistant has finished processing. These tasks include enabling the use of privileged ports, and upgrading a cluster.
OracleAS Web Cache will not start after upgrade if the port settings of 80 and 443 were upgraded from the Oracle9iAS Release 2 (9.0.2) Web Cache to the Oracle Application Server 10g (9.0.4) Web Cache.
Because port numbers under 1024 are reserved for privileged processes in UNIX, the webcached executable in 10g (9.0.4) must run as root in order to start the cache server process and bind to these ports.
A script is provided that enables the webcached executable to run as the root user:
<destination_MT_OH>/webcache/bin/webcache_setuser.sh
Log in to the system as the root user and run the script.
|
See Also: Oracle Application Server Web Cache Administrator’s Guide |
If you have a OracleAS Web Cache cluster, you can upgrade one cache cluster member at a time. The caches will continue to function, but because the other cluster members have a different version of the configuration, the caches will not forward requests to cache cluster members operating with a different version.
For example, if you upgrade Cache_A to the current version, but have not yet upgraded Cache_B and Cache_C, Cache_A will not forward requests to the cache cluster members Cache_B and Cache_C.
In this situation, the Operations page in Web Cache Manager indicates that the Operation Needed is Incompatible software version.
|
Note: When the cache cluster members are not running the same version of OracleAS Web Cache, you can still invalidate documents and you can propagate the invalidation to other cluster members, but the invalidation request must originate with the cache that is operating with 9.0.2 version of OracleAS Web Cache. |
After you upgrade the cache cluster members, you must perform the following additional steps to synchronize the configuration for the members of the cluster:
If the caches have not been started, for each upgraded cache, start OracleAS Web Cache and OracleAS Web Cache Manager. On the command line, enter:
opmnctl startproc ias-component=WebCache
This command starts the OracleAS Web Cache cache server process and admin server process.
In a browser, enter the URL for the OracleAS Web Cache Manager for one of the upgraded caches, and, when prompted, enter the username and password for the ias_admin or administrator user.
In the navigator frame, select Administration > Operations.
The Operations page appears.
In the Operations page, click Retrieve.
Web Cache retrieves the cache-specific configuration information from the remote cache cluster members. Then, Web Cache Manager indicates that the Operation Needed is Propagate Configuration.
To propagate the configuration to all cache cluster members, select All caches and an Interval of Immediate. Then, click Propagate.
Restart the caches by selecting All caches and an Interval. Then, click Restart. (Note that you can perform this operation as you upgrade each cache, or you can perform this operation after all of the cache cluster members have been upgraded.)
A Release 2 (9.0.2.x) cache cannot accept invalidation messages from a 10g (9.0.4) cache. In a configuration that uses a OracleAS Web Cache cluster with a mixture of Release 2 (9.0.2.x) and 10g (9.0.4) cluster members, you must configure the Load Balancer to send invalidation messages only to the Release 2 (9.0.2.x) members.
When upgrading a cache cluster from Release 2 (9.0.2.x) to 10g (9.0.4), remove cluster members one at a time from the invalidation pool for the Load Balancer prior and upgrade them. Once all the cluster members are upgraded, add them back to the invalidation pool. As an example, assume a configuration with a Load Balancer in front of a cache cluster that is comprised of four members, webche1-host, webche2-host, webche3-host, and webche4-host, all running Release 2 (9.0.2.x). To upgrade this cache cluster:
In the Load Balancer configuration, remove webche1-host from the pool that is responsible for invalidation.
Upgrade webche1-host from Release 2 (9.0.2.x) to 10g (9.0.4).
In the Load Balancer configuration, remove webche2-host from the pool that is responsible for invalidation.
Upgrade webche2-host from Release 2 (9.0.2.x) to 10g (9.0.4).
In the Load Balancer configuration, remove webche3-host from the pool that is responsible for invalidation.
Upgrade webche3-host from Release 2 (9.0.2.x) to 10g (9.0.4).
Upgrade webche4-host from Release 2 (9.0.2.x) to 10g (9.0.4). As this is the last cache member in the Load Balancer configuration, it is not necessary to remove it from the invalidation pool.
In the Load Balancer configuration, add webche1-host, webche2-host, and webche3-host back into the pool that is responsible for invalidation.
The OracleAS Upgrade Assistant moves most of the Oracle Application Server Forms Services configuration data from the source to the destination Oracle home. However, there may be manual tasks remaining after the upgrade. This section explains how to perform these tasks.
Entries may have been added to, or changed in, the tnsnames.ora file between the installation of Oracle9iAS Release 2 (9.0.2) and upgrade to 10g (9.0.4). If so, you must upgrade this file manually so that any added or changed entries are available in 10g (9.0.4).
If an error occurs after upgrade, it may be because the tnsnames.ora file was overwritten by another component upgrade. A missing or incorrect entry yields the following error:
If you have deployed these files within the source Oracle home, you must manually copy them to the same location in the destination Oracle home. If the *.fmx files are not under the Oracle home on the file system, then no action is needed, as the FORMS90_PATH will be upgraded by the OracleAS Upgrade Assistant, and it will be valid after the upgrade.
If you defined any aliases for the OracleAS Forms Services servlets in:
<source_MT_OH>/j2ee/OC4J_BI_FORMS/applications/forms90app/forms90web/WEB-INF/web.xml, then you must manually copy these entries to:
<destination_MT_OH>/j2ee/OC4J_BI_FORMS/applications/forms90app/forms90web/WEB-INF/web.xml.
The forms90app.ear file is deployed by default into the OC4J_BI_Forms OC4J instance. Note that the Upgrade Assistant upgrades all user-defined OC4J instances and the applications deployed under these instances to the destination Oracle home.
Thus, if you have deployed the forms90app.ear file into one of the user-defined OC4J instances in the source Oracle home, the Upgrade Assistant will upgrade this deployment into the corresponding OC4J instance in the destination Oracle home.
As a result, the source Oracle home Release 2 (9.0.2) forms90app.ear file is deployed into the destination Oracle home. This causes the configuration of OracleAS Forms Services 10g (9.0.4) to be incorrect, because it requires the 10g (9.0.4) EAR file in order to function properly.
Therefore, you must undeploy the forms90app.ear file from these upgraded OC4J instances in the destination Oracle home, and then deploy forms90app.ear in the destination Oracle home again.
The Oracle Application Server Forms Services 10g (9.0.4) forms90app.ear file is located in: <destination_MT_OH>/forms90/j2ee.
The OracleAS Upgrade Assistant performs most of the Oracle Application Server Reports Services upgrade. However, it does not process the script files <source_MT_OH>/bin/rw*.sh and the configuration file <source_MT_OH>/reports/ conf/jdbcpds.conf. If you have customized any of these files, you must apply the customizations to the corresponding files in the destination Oracle home.
|
Note: To apply the customizations, you must copy the customized entries from the source Release 2 (9.0.2) instance to the destination 10g (9.0.4) instance. It is not safe to replace the 10g (9.0.4) file with the Release 2 (9.0.2) file, because the files are different. |
In addition, you may want to perform the following optional manual steps:
To preserve the cache files and the cache directory from Release 2 (9.0.2), copy the reports server cache directory from the source Oracle home to the destination Oracle home.
To monitor additional reports server instances with the Oracle Process Manager and Notification Server (OPMN), define the reports server instances in <destination_MT_OH>/opmn/conf/opmn.xml.
|
See Also: Oracle Application Server Reports Services Publishing Reports to the Web, section entitled "Configuring Reports Server with Oracle Process Manager and Notification Server and Oracle Enterprise Manager" |
To manage additional reports server instances with the Oracle Enterprise Manager Application Server Control, define the reports server instances in <destination_MT_OH>/sysman/emd/targets.xml.
|
See Also: Oracle Application Server Reports Services Publishing Reports to the Web, section entitled "Configuring Reports Server with Oracle Process Manager and Notification Server and Oracle Enterprise Manager" |
The OracleAS Upgrade Assistant upgrades the Oracle9iAS Release 2 (9.0.2) Business Intelligence & Forms configuration to the Oracle Application Server 10g (9.0.4) Business Intelligence & Forms configuration. It is not aware of OC4J instances outside of these configurations that may contain deployed reports, or of customizations made to those instances in order to enable the deployed reports to run.
Therefore, if you are using OC4J instances other than the standard Business Intelligence and Forms OC4J instance, you must apply any manual deployment steps that you performed on those instances in Oracle9iAS Release 2 (9.0.2) to the equivalent instances in Oracle Application Server 10g (9.0.4).
You must also add the Java option below to the java-options tag in <destination_MT_OH>/opmn/conf/opmn.xml to these OC4J instances before you can use them for Oracle Application Server Reports Services.
-Xbootclasspath^/p:<destination_MT_OH>/vbroker4/lib/vbjboot.jar
In the OracleAS 10g (9.0.4) reports server configuration file, the <identifier> element is encrypted, and matches the value in the <destination_MT_OH>/sysman/emd/targets.xml file.
During the upgrade, the OracleAS Upgrade Assistant copies the Oracle9iAS Release 2 (9.0.2) reports server configuration files into the OracleAS 10g (9.0.4) Reports configuration files. The <identifier> element in the Oracle9iAS Release 2 (9.0.2) is different from that in the 10g (9.0.4) targets.xml file, so some of the features of the OracleAS Reports Services will not work after the upgrade.
Edit the <destination_MT_OH>/reports/conf/<server name>.conf file and modify the <identifier> element to specify the user name and password and set the encrypted attribute to no. For example, if the user name is scott and the password is tiger:
<identifier confidential="yes" encrypted="no>scott/tiger</identifier
In the <destination_MT_OH>/sysman/emd/targets.xml file, locate the TYPE="oracle_repserv" and DISPLAY_NAME="Reports Server: server name" entries.
Set the UserName and Password properties to the same values as those in the <identifier> element in the <server name>.conf file. Set the ENCRYPTED attribute to FALSE for both properties.
|
Note: The configuration changes will not be in effect until after the reports server and Oracle Enterprise Manager are both restarted. |
A Oracle9iAS Release 2 (9.0.2) Reports application can publish a report to Oracle9iAS Portal. By default, the Release 2 (9.0.2) Reports server configuration file contains a connection string that points to the Oracle9iAS Portal instance in the Infrastructure.
If you need to integrate OracleAS Reports Services with OracleAS Portal, you should upgrade to the OracleAS 10g (9.0.4) Business Intelligence and Forms installation type. If you upgrade to Forms and Reports Services in 10g (9.0.4), and still attempt to publish reports to a standalone or Infrastructure Portal instance, Oracle Corporation does not guarantee that that feature will function.
A Oracle9iAS Release 2 (9.0.2) Reports application can store a connection string in Oracle Internet Directory in Oracle9iAS Release 2 (9.0.2) and execute a report using the SSOCONN parameter that points to the connection string in Oracle Internet Directory.
If you need to integrate OracleAS Reports Services with Oracle Internet Directory, you should upgrade to the OracleAS 10g (9.0.4) Business Intelligence and Forms installation type. If you upgrade to Forms and Reports Services in 10g (9.0.4), and still attempt to execute reports with the SSOCONN paramter, the report requests will fail. In this case, you must replace the SSOCONN parameter with a clear connection string.
The <source_MT_OH>/network/admin/tnsnames.ora file contains connection information for various databases. It is shared among Oracle Application Server components.
You should examine this file to determine whether it contains any entries that will be needed to operate a component in the 10g (9.0.4) installation, but which do not exist in the <destination_MT_OH>/network/admin/tnsnames.ora file. For example, entries might have been added since the Oracle9iAS Release 2 (9.0.2) installation to provide access to additional databases, or the entry for the Infrastructure Services repository might have been changed in some way.
If new or changed entries exist, you have two choices for upgrading: append individual entries, or copy the entire file.
Copy all new and changed entries to the <destination_MT_OH>/network/ admin/tnsnames.ora file.
If you are certain that doing so will not eliminate entries added or changed by other components, you can copy the entire tnsnames.ora file from the source to the destination Oracle home, restoring the EXTPROC_CONNECTION_DATA.US.ORACLE.COM entry (which is introduced in 10g (9.0.4)).
To upgrade by copying the entire file, follow the steps below:
Create a backup of <source_MT_OH>/network/admin/tnsnames.ora and <destination_MT_OH>/network/admin/tnsnames.ora.
Copy the entire tnsnames.ora file from the source to the destination Oracle home.
Copy the EXTPROC_CONNECTION_DATA.US.ORACLE.COM entry (used for executing external procedures in the database) from the 10g (9.0.4) backup file created in step 1 to the Oracle9iAS Release 2 (9.0.2) file.
Some applications upgraded from the source Oracle home may have been configured to use OracleAS Single Sign-On in the source Oracle home. Because the Forms and Reports Services installation type does not use OracleAS Single Sign-On, you must disable it in the destination Oracle home after the upgrade.
To disable Oracle Application Server Single Sign-On in the Oracle HTTP Server, you must comment out the Include directive for the mod_osso.conf file in the <destination_MT_OH>/Apache/Apache/conf/httpd.conf file, as shown below:
#include "<destination_MT_OH>/Apache/Apache/conf/mod_osso.conf"
By default, OracleAS Reports Services is enabled for OracleAS Single Sign-On. To disable it after the upgrade, you must edit the files that contain security-related configuration elements.
You must edit the in-process server and reports server configuration files to eliminate security tags.
The in-process server configuration file is:
<destination_MT_OH>/reports/conf/rep_<host name>.conf
The reports server configuration file is:
<destination_MT_OH>/reports/conf/<server name>.conf
To disable OracleAS Single Sign-On in these files, you must:
If OracleAS Forms Services was configured to run with OracleAS Single Sign-On in Oracle9iAS Release 2 (9.0.2), then the Single Sign-On configuration information will not be available in the OracleAS 10g (9.0.4) Forms and Reports Services installation after the upgrade. When OracleAS Forms Services applications are accessed after upgrade, users are prompted for login information via dialog box. The users will have to enter the information into the dialog at each access.
If there is a common user name and password for a given application, you may wish to provide the connect string in the application section of <destination_MT_OH>forms90/server/formsweb.cfg file, so that the login dialog box does not appear.
After you upgrade a middle tier to OracleAS 10g (9.0.4), the upgraded instance is using the same ports that the Oracle9iAS Release 2 (9.0.2) instance used. For this reason, after upgrade, you cannot start the source and destination middle tier instances at the same time, because of port conflicts.
The <destination_MT_OH>/install/portlist.ini file does not reflect the upgraded port settings; it lists the port values assigned by the installer before the upgrade. Table 3-2 lists pre- and post-upgrade values for Oracle HTTP Server, Oracle Enterprise Manager Application Server Control, and Oracle Application Server Web Cache.
Table 3-2 Port Values Before and After Upgrade
| Component | Port in Source Oracle Home | Port Value in Destination Oracle Home Assigned by Installer and Recorded in portlist.ini File | Post-Upgrade Port Value |
|---|---|---|---|
| Oracle HTTP Server
|
Port: 7777
Listen: 7778 |
Port: 7783
Listen: 7784 |
Port: 7777
Listen: 7778 |
| Oracle Enterprise Manager Application Server Control
|
1810 | 1812 | 1812 |
| Oracle Application Server Web Cache
|
Administration: 4000
Invalidation: 4001 Statistics: 4002 |
Administration: 4003
Invalidation: 4004 Statistics: 4005 |
Administration: 4000
Invalidation: 4001 Statistics: 4002 |
Upgrading an application server cluster is a two-stage process. First, you must upgrade the configuration of one of the instances in the cluster from the source Oracle home to the newly installed 10g (9.0.4) middle tier instance in the destination Oracle home. Then, you reconstruct the cluster by installing and clustering additional instances in new destination Oracle homes.
Follow these steps to upgrade an application server cluster:
Determine the instance name of the instance to upgrade with the command:
<source_MT_OH>/dcm/bin/dcmctl listinstances
Stop all processes in the source instance with the command:
<source_MT_OH>/dcm/bin/dcmctl shutdown
Stop all processes in the destination instance with the command:
<destination_MT_OH>/dcm/bin/dcmctl shutdown
Follow the instructions in Section 1.3.3, "Performing an Upgrade with the OracleAS Upgrade Assistant (Graphical User Interface (GUI) Version)" or Section 1.3.4, "Performing an Upgrade with the OracleAS Upgrade Assistant (Command-line Version) ".
Follow the instructions that apply to the upgraded configuration in the following sections:
Section 3.1, "Completing the Oracle Application Server Containers for J2EE (OC4J) Upgrade"
Section 3.2, "Completing the Oracle HTTP Server Upgrade"
Section 3.3, "Completing the OracleAS Web Cache Upgrade"
Section 3.4, "Completing the Oracle Application Server Forms Services Upgrade"
Section 3.5, "Completing the Oracle Application Server Reports Services Upgrade"
Section 3.6, "Upgrading the tnsnames.ora File"
Section 3.7, "Disabling Oracle Application Server Single Sign-On in the Upgraded Instance"
Start the Oracle Enterprise Manager Application Server Control with the command:
<destination_MT_OH>/bin/emctl start iasconsole
Display the OracleAS Instance Home Page.
Start the upgraded instance by following the instructions in Section 3.10, "Starting the Upgraded Forms and Reports Services Instance".
Create a cluster with the command:
<destination_MT_OH>/dcm/bin/dcmctl createcluster <name of cluster>
Join the upgraded instance to the cluster with the command:
<destination_MT_OH>/dcm/bin/dcmctl joincluster -cl <name of cluster>
Join each additional instance to the cluster with the command:
<destination_MT_OH>/dcm/bin/dcmctl joincluster -cl <name of cluster>
If the upgraded configuration used mod_oc4j.conf for request routing, do the following:
View the <destination_MT_OH>/Apache/Apache/conf/mod_oc4j.conf file in one of the instances, noting the instance and cluster names in the Oc4jMount directives.
Change the instance (and, if necessary) cluster names to the instance name of the upgraded instance.
Copy the Oc4jMount directives to the mod_oc4.conf file in each instance in the new cluster.
Verify that requests that match the URL patterns in the Oc4jMount directives are routed to the correct instances.
After the OracleAS Upgrade Assistant has finished processing, and you have completed all of the applicable manual upgrade tasks, start the upgraded Forms and Reports Services instance.
Follow these instructions to start the middle tier instance:
Start the application server components by issuing this command:
<destination_MT_OH>/opmn/bin/opmnctl startall
Oracle Process Management and Notification and all of the processes it manages are started (i.e., Distributed Configuration Management, Oracle HTTP Server, OC4J instances, OracleAS Web Cache, Oracle Application Server Forms Services, and Oracle Application Server Reports Services).
Start the Application Server Control by issuing this command:
<destination_MT_OH>/bin/emctl start iasconsole
If the upgrade succeeds, but components that use the Oracle Call Interface do not function properly, it may be that the tnsnames.ora file was not upgraded, or was upgraded incorrectly. Review the instructions and upgrade strategies presented in Section 3.6, "Upgrading the tnsnames.ora File" and verify that the file contains all necessary entries for the components that use it.
This section describes tasks you should perform after the upgrade to validate that the upgrade was successful.
Follow these steps to verify that the middle tier components that were upgraded are started:
In a browser, access the Oracle Enterprise Manager Application Server Control in the 10g (9.0.4) middle tier Oracle home by entering its URL. Ensure that you provide the correct host name and port number. For example:
http://midtierhost.mycompany.com:1812
The Oracle Enterprise Manager page appears. A link for the middle tier instance appears in the Standalone Instances section.
Click the link.
The System Components page appears.
Verify that the components are running.
Verify that the configuration information for the components in use is reflected in the 10g (9.0.4) Oracle home.
Follow these steps to verify that you can access the Oracle HTTP Server and application URLs:
Verify that you can access the Oracle HTTP Server on the same host and port that you did in the previous release by entering the URL. Ensure that you provide the correct host name and port number. For example:
http://midtierhost.mycompany.com:7777
Verify that you can access the URLs for the applications you operated in the previous release, and ensure that the applications are functioning as they did in the previous release.
The upgrade process leaves the source Oracle home unchanged. Depending on the type of installation you have, and your future needs, you may elect to remove the source Oracle home, or to retain it for specific reasons. This section discusses decommissioning the source Oracle home, as well as reasons for retaining it, including the steps you must perform to revert to using it.
|
Note: If you retain the source Oracle home, you cannot operate it simultaneously with the destination Oracle home, because certain components have the same port values after upgraded. See Section 3.8, "Port Values and the portlist.ini File After Upgrade". |
When you are certain that the upgrade was successful, you have all of the necessary backups, and have no plans to revert to the source Oracle home, you may elect to remove the files from the source Oracle home. Use the Oracle Universal Installer to deinstall the instance.
|
See Also: Oracle9i Application Server Installation Guide in the Release 2 (9.0.2) documentation library |
Deinstalling a Release 2 (9.0.2) or instance when there is also a 10g (9.0.4) instance on the computer requires a patch, and there are issues associated with this deinstallation that may apply to your configuration.
If there are application files or log files in the source Oracle home that are being referenced or used by the destination Oracle home, you should move them to another location before you decommission the source Oracle home, and, in the destination Oracle home, change any references to the files to the new location.
