3
Migrating Java Servlets

This chapter provides the information you need to migrate Java servlets from WebLogic Server to Oracle Application Server. It covers the migration of simple servlets, WAR files, and exploded web applications.

This chapter contains these topics:

• Introduction

• Migrating a Simple Servlet

• Migrating Configuration and Deployment Descriptors

• Migrating a WAR File

• Migrating an Exploded Web Application

• Migrating Cluster Aware Applications

Introduction

Migrating Java servlets from WebLogic Server to Oracle Application Server is straightforward, requiring little or no code changes to the servlets migrated.

Both application servers are fully compliant with Sun Microsystem's J2EE Servlet specification, version 2.3. All servlets written to the standard specification will work correctly and require minimal migration effort.

The primary tasks involved in migrating servlets to a new environment are configuration and deployment. The use of proprietary extensions, such as htmlKona, will require additional tasks and complicate the migration effort.

The tasks involved in migrating servlets also depend on how the servlets have been packaged and deployed. Servlets can be deployed as a simple servlet, as a web application packaged with other resources in a standard directory structure, or as a web archive (WAR) file.

Differences Between WebLogic Server and Oracle Application Server Servlet Implementations

Oracle Application Server and WebLogic Server both support the Servlet 2.3 specification. Hence, migrating a servlet from WebLogic Server to Oracle Application Server is straightforward.

OC4J Key Servlet Container Features

One of the key distinguishing features of OC4J is the seamless integration with Single Sign-On (SSO) and Oracle Internet Directory (OID). This is achieved through Oracle's implementation of the Java Authentication and Authorization Service (JAAS) standard - JAAS provider is integrated with OC4J.

Migrating a Simple Servlet

Simple servlets are easily configured and deployed in OC4J. The manual process used to deploy a servlet is the same in both WebLogic Server and OC4J.

A servlet must be registered and configured as part of a web application. To register and configure a servlet, several entries must be added to the web application deployment descriptor.

The overall steps to deploy a simple servlet are as follows (detailed steps are in Table 3-1):

1. Update the web application deployment descriptor (web.xml) with the name of the servlet class and the URL pattern used to resolve requests for the servlet.

2. Copy the servlet class file to the WEB-INF/classes/ directory. If the servlet class file contains a package statement, create additional subdirectories for each level of the package statement. The servlet class file must then be placed in the lowest subdirectory created for that package.

3. Invoke the servlet from your browser by entering its URL.

To determine the effort involved in migrating servlets, we selected and migrated example servlets provided with WebLogic Server. We chose examples that did not use proprietary extensions.

Table 3-1 presents the manual process for migrating a simple servlet, HelloWorld, from WebLogic Server to Oracle Application Server OC4J.

Table 3-1 Migrating a Simple Servlet  

<servlet>
  <servlet-name>
   HelloWorldServlet
  </servlet-name>
  <servlet-class>
   examples.servlets.HelloWorldServlet
  </servlet-class>
</servlet>
<servlet-mapping>
  <servlet-name>
   HelloWorldServlet
  </servlet-name>
  <url-pattern>
   /HelloWorldMigrate/*
  </url-pattern>
</servlet-mapping>

dcmctl start|restart -i <appsvr_instance_name> -ct oc4j 
-co home

http://localhost:7777/j2ee/HelloWorldMigrate

Migrating a WAR File

A web application can be configured and deployed as a WAR file. This is easily accomplished in OC4J by using the Application Server Control administration GUI or manually copying the WAR file to the appropriate directory. This is also true for WebLogic Server. We will illustrate the process using Application Server Control to deploy an example WAR file from WebLogic Server.

Production web applications are typically deployed using WAR or EAR files through Application Server Control or the dcmctl utility. During the development of a web application, it may be faster to deploy and test edited code using an exploded directory format.

Table 3-3 presents the typical process for migrating a WAR file from WebLogic Server to OC4J.

Table 3-2 Migrating a WAR File  

http://<hostname>:7777/cookie

Table 3-3 Migrating a WAR File  

Migrating an Exploded Web Application

Web applications can also be configured and deployed as a collection of files stored in a standard directory structure or exploded directory format. This can be accomplished in OC4J by manually copying the contents of the standard directory structure to the appropriate directory in the OC4J installation. The same method can also be used for WebLogic Server. In this section, we will describe the manual process for deploying an exploded web application.

Deploying a web application in exploded directory format is used primarily during the development of a web application. It provides a fast and easy way to deploy and test changes. When deploying a production web application, package the web application in a WAR file and deploy the WAR file using Application Server Control.

To manually deploy an exploded web application in WebLogic Server, copy the top-level directory containing the exploded web application files into the following directories of your WebLogic Server installation:

(UNIX) <BEA_HOME>/config/<domain_name>/applications
(Windows) <BEA_HOME>\config\<domain_name>\applications

Once the top-level directory is copied to the appropriate directory, create an empty file with the name "REDEPLOY" within the top-level directory. WebLogic Server detects this file and deploys the web application. (WebLogic Server reads the timestamp of this file every few minutes to determine if the application needs redeploying. Hence, whenever an application file is updated, the REDEPLOY file's timestamp has to be updated to redeploy the file. In UNIX, this can be done by using the touch command.)

Manually deploying an exploded web application in OC4J varies slightly. Copy the top-level directory containing the exploded web application into the following directory of your OC4J installation:

(UNIX) <ORACLE_HOME>/j2ee/home/applications
(Windows) <ORACLE_HOME>\j2ee\home\applications

Then, modify the following application deployment descriptor to include the web application:

(UNIX) <ORACLE_HOME>/config/application.xml
(Windows) <ORACLE_HOME>\config\application.xml

Bind the web application to your website by adding an entry in the following website XML file (or the corresponding XML file if a non-default website is used):

(UNIX) <ORACLE_HOME>/config/default-web-site.xml
(Windows) <ORACLE_HOME>\config\default-web-site.xml

Finally, register the new application by adding a new <application> tag entry in the following files:

(UNIX) <ORACLE_HOME>/config/server.xml
(Windows) <ORACLE_HOME>\config\server.xml

When you modify server.xml and save it, OC4J detects the timestamp change of this file and deploys the application automatically. OC4J need not be restarted.

Migrating Configuration and Deployment Descriptors

Since WebLogic Server and Oracle Application Server fully support J2EE 1.3, there is a standard set of XML configuration files supported by both application servers. These are:

• web.xml (found in the WEB-INF directory of a web application's WAR file)

• application.xml (found in the META-INF directory of a web application's WAR file)

• ejb-jar.xml (found in the META-INF directory of an EJB module's exploded directory hierarchy)

In addition to the standard files, each application server has specific files used only by their respective environments. These are:

Oracle Application Server

• server.xml
Found in

  (UNIX) <ORACLE_HOME>/j2ee/home/config/
(Windows) <ORACLE_HOME>\j2ee\home\config\

  This is the overall OC4J runtime configuration file. It defines attributes such as the deployed applications directory, the server log file path and name, path and names of other XML files, names of applications and their EAR files, paths to runtime libraries, etc.

• application.xml
Found in

  (UNIX) <ORACLE_HOME>/j2ee/home/config\
(Windows) <ORACLE_HOME>\j2ee\home\config\

  This is the global configuration file common settings for all applications deployed on a particular OC4J installation. Note that this is different from the application.xml in a J2EE WAR file.

• <website_name>-web-site.xml
Found in

  (UNIX) <ORACLE_HOME>/j2ee/home/config\
(Windows) <ORACLE_HOME>\j2ee\home\config\

  This file defines a website and specifies attributes such as host name, HTTP listener port number, web applications it services and their URL contexts, and HTTP access log file and path. Note that the name and path of each *-web-site.xml file has to be specified in the server.xml file for OC4J to configure the defined website at runtime.

• data-sources.xml
Found in

  (UNIX) <ORACLE_HOME>/j2ee/home/config/
(Windows) <ORACLE_HOME>\j2ee\home\config\

  This file contains configuration information for data sources used by the OC4J runtime. Information in this file include: JDBC drivers used, JNDI binding for each data source, username and password for each data source, database schemas to use, maximum connections to each database, and time out values.

• principals.xml
Found in

  (UNIX) <ORACLE_HOME>/j2ee/home/config/
(Windows) <ORACLE_HOME>\j2ee\home\config\

  This file contains the user repository for the default XMLUserManager class. Groups, users belonging to them, and group permissions are defined in this file. The mapping of groups to roles is defined in the global application.xml file.

• orion-application.xml
Found in

  UNIX: <ORACLE_HOME>/j2ee/home/application-deployments/<app_name>

  or

  Windows: <ORACLE_HOME>\j2ee\home\application-deployments\<app_name>

  This file contains OC4J-specific information for an application (<app_name>) deployed on an OC4J installation. Web and EJB module names and security information for the application are included in the file. This file is generated by OC4J at deploy time.

• global-web-application.xml
Found in

  (UNIX) <ORACLE_HOME>/j2ee/home/config/
(Windows) <ORACLE_HOME>\j2ee\home\config\

  This file contains servlet configuration information used internally by the OC4J runtime. An example is the JSP translator servlet.

• orion-web.xml
Found in

  UNIX:
  <ORACLE_HOME>/j2ee/home/application-deployments/
<app_name>/<web_app_name>/

  or

  Windows:
  <ORACLE_HOME>\j2ee\home\application-deployments\
<app_name>\<web_app_name>\

  OC4J internal JSP and servlet information for <web_app_name> is specified in this file. This file is generated by OC4J at deploy time.

• orion-ejb-jar.xml
Found in

  UNIX:
  <ORACLE_HOME>/j2ee/home/application-deployments/
<app_name>/<ejb_jarfile_name>/

  or

  Windows:
  <ORACLE_HOME>\j2ee\home\application-deployments\
<app_name>\<ejb_jarfile_name>\

  This file contains OC4J internal deployment information for EJBs in the JAR file specified by <ejb_jarfile_name> belonging to the application <app_name>. This file is generated by OC4J at deploy time.

• oc4j-connectors.xml
Found in

  (UNIX) <ORACLE_HOME>/j2ee/home/config/
(Windows) <ORACLE_HOME>\j2ee\home\config\

  This file contains connector information for the OC4J installation.

WebLogic Server

• config.xml
Found in

  (UNIX) <BEA_HOME>/config/<domain_name>/
(Windows) <BEA_HOME>\config\<domain_name>\

  This file contains configuration information for an entire WebLogic Server domain. Information specified in this file include the domain administration server's host name and admin port number, JNDI mappings to data sources, JDBC connection pool information, applications deployed to all nodes in the domain, SSL certificate information,

• weblogic.xml
Found in

  UNIX:
  <BEA_HOME>/config/<domain_name>/applications/
<web_app_name>/WEB_INF/

  or

  Windows:
  <BEA_HOME>\config\<domain_name>\applications\
<web_app_name>\WEB_INF\

  This file defines JSP properties, JNDI mappings, resource references, security role mappings, and HTTP session and cookie parameters for a Web application. This file is WebLogic Server-specific but is created manually.

• weblogic-ejb-jar.xml
Found in an EJB module's META-INF subdirectory. This file maps WebLogic Server resources to EJBs. These resources include security role names, data sources, JMS connections, and other EJBs. This file also has performance attributes for caching and clustering for the EJBs defined in the corresponding ejb-jar.xml file.

  Note: The files mentioned above are not an exhaustive list of all XML configuration file used by each application server. They are files which are relevant to the configuration and deployment of servlet applications. Other XML files also exist to configure components such as HTTP listeners, RMI, security.

Migrating Cluster Aware Applications

Oracle Application Server provides more comprehensive clustering features than WebLogic Server.

WebLogic Server provides two primary cluster services, HTTP session state clustering and object clustering. The focus of this section is on HTTP session state clustering or web application clustering.

WebLogic Server supports clustering for servlets and JSP pages by replicating the HTTP session state of clients accessing clustered servlets and JSP pages. To benefit from HTTP session state clustering, you must ensure that the HTTP session state is persistent by configuring either in-memory replication, filesystem persistence, or JDBC persistence.

Oracle Application Server provides clustering support similar to that of WebLogic Server. In addition, Oracle Application Server provides:

• Servlet Clustering--OC4J provides facilities to cluster servlets without requiring any changes to the web application. The changes necessary are deployment configuration modifications that are transparent to the web application and allows session failover to multiple OC4J processes.

• Clustering Architecture and Simplicity--An important differentiator for Oracle Application Server is the ease with which different instances can be clustered and the robustness of the architecture used for clustering.

• Clustering Simplicity--Oracle Enterprise Manager Application Server Control provides a GUI to configure various OracleAS instances to belong to a single cluster, whether they are multiple servers with load balancing on a single machine or on different machines. Alternatively, you can also edit a single XML file. In contrast, it is more complex to configure WebLogic Server clusters with load balancing either with multiple instances on one machine or on multiple machines.

• Superior Clustering Architecture--OC4J uses dynamic IP addresses to register instances as part of a cluster. Any standard load balancer such as Cisco Local Director or BigIP has the ability to use a variety of load balancing mechanisms to route requests to different Oracle Application Server instances. Additionally, mod_oc4j intelligently routes requests from Oracle HTTP Server to OC4J processes using one of several load balancing algorithms. In contrast, WebLogic Server uses static IP addresses to configure clustering. Static IP addresses preclude the use of a load balancer to distribute requests across instances. As a result, you get either clustering or load balancing with WebLogic Server but not both.

  See Also: Oracle Application Server 10g High Availability Guide

Each OracleAS Farm consists of multiple OC4J islands and each island can consist of multiple applications. The sharing of session state for failover is within a particular island.

For instructions on how to set up OracleAS Clusters and OC4J islands, refer to the Oracle Application Server 10g High Availability Guide.