5-12 Oracle Fusion Middleware Upgrade Guide for Java EE
As a result, if an application is using the ODL framework for logging, it requires no modification when deployed to Oracle WebLogic Server. The JRF ODL integration into
Oracle WebLogic Server is as follows:
■
ODL log messages are sent to a separate log file that is kept in a well-known location on the file system:
domain_directoryserversserver_namelogsserver_name-diagnostic.log
■
Critical messages errors are double-logged both in the ODL and WebLogic domain log file.
■
ODL log queries and configuration JMX MBeans are available in the domain’s WebLogic administration server.
For more information, see Oracle Fusion Middleware Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.
5.4 Task 4: Redeploy the Application on Oracle WebLogic Server
After you have compiled your application successfully, you can then deploy the application on the Oracle WebLogic Server environment you installed and configured
earlier.
You can redeploy your Java EE applications using any of the following typical tools:
■
Apache Ant
■
WLST, the Oracle WebLogic Server scripting tool
■
The Oracle WebLogic Administration Console For more information, see Oracle Fusion Middleware Deploying Applications to Oracle
WebLogic Server.
5.5 Task 5: Verify the Redeployed Applications
After you have deployed your Java EE applications on Oracle WebLogic Server, you can verify the applications by doing the following:
■
Log in to the Oracle WebLogic Administration Console and review the deployments on the domain. You can also perform various monitoring tasks and
post-deployment tasks from the console.
■
Navigate in your browser to the application URL and verify that the features of the application are working as they did when you verified them on OC4J earlier in
this procedure.
If find any problems with the application, review the domain log files to diagnose the problem. For more information, see Configuring Log Files and Filtering Log
Messages in the Oracle WebLogic Server documentation library.
6
Upgrading Application Clients 6-1
6
Upgrading Application Clients
When you upgrade your Java EE applications to Oracle WebLogic Server and Oracle Fusion Middleware 11g, the external interfaces exposed by your applications can be
affected. In turn, client applications that depend on those interfaces can be affected.
The following sections describe the ramifications of upgrade on application clients, as well as guidelines for addressing any the resulting client issues:
■
Impact of Upgrade on Java Server Pages and Servlet Clients
■
Impact of Upgrade on Java Naming and Directory Interface Clients
■
Impact of Upgrade on Enterprise Java Bean Clients
■
Impact of Upgrade on JMS Clients
6.1 Impact of Upgrade on Java Server Pages and Servlet Clients
When an application is upgraded to WebLogic Server, JSP and servlet clients can be affected because of differences in the HTTP session state replication model between
Oracle WebLogic Server and OC4J.
Unlike OC4J clusters, which can support any number of in-memory replicated copies of the HTTP session state, Oracle WebLogic Server in-memory HTTP session state
replication supports only a primary-secondary, two-copy model.
In most cases, this difference should have no impact on JSP and Servlet clients; however, for rare cases where an application might explicitly rely on more than two
copies of the HTTP session state to be available for its clients, consider using Oracle Coherence.
For more information, refer to the information about Oracle Coherence on the Oracle Technology Network OTN:
6.2 Impact of Upgrade on Java Naming and Directory Interface Clients
The following sections describe considerations for clients of upgraded applications that use the OC4J Java Naming and Directory Interface JNDI provider:
■
Modifying Clients to Use the Oracle WebLogic Server JNDI Provider
■
Understanding the Scope of the Oracle WebLogic Server JNDI Namespace
