Oracle Application Server 10g Migrating from Oracle Application Server 10g (9.0.4) Part Number B10424-01 |
|
This chapter discusses migration of JWeb applications from Oracle Application Server to OC4J in Oracle Application Server 10g.
Topics discussed are:
This section provides background information on JWeb and OC4J. It also describes the differences between JWeb and OC4J applications.
JWeb applications execute within the Oracle Application Server cartridge infrastructure, while OC4J runs on a standard virtual machine.
In Oracle Application Server, the HTTP listener receives a request for a JWeb cartridge. The listener passes the request to the dispatcher, which communicates with the Security or Web Request Broker (WRB). The WRB uses a URL mapping to identify the cartridge instance to which the request should be sent. If no cartridge instances exist for the requested cartridge, the cartridge server factory creates a cartridge server process to instantiate the cartridge. In JWeb, the cartridge server process loads a JVM, which runs a JWeb application (of the Oracle Application Server application paradigm). Figure 2-1 depicts this process graphically.
OC4J consists of a Web container including servlet and JSP engines, EJB container, J2EE services APIs (JNDI, JTA, JMS, and JAAS), and enterprise information systems APIs (JDBC, SQLJ, J2EE connector architecture).
mod_oc4j
is a dynamically loaded module of Oracle HTTP Server with the purpose of routing requests through Oracle HTTP Server to OC4J processes. mod_oc4j
takes into account OC4J sessions information to route requests back to the original OC4J process and to re-route failed session requests to other members of the same OC4J Island when the original OC4J process is unreachable.
The mod_oc4j
interacts with two components, Oracle Process Manager and Notification Server (OPMN) and OC4J. mod_oc4j
interacts with OC4J by routing requests to it. OPMN starts Oracle HTTP Server (which starts mod_oc4j)
and starts all OC4J processes. OPMN monitors each process that it starts and periodically verifies that each process is reachable. If a process dies, or becomes unreachable, OPMN restarts that process. In addition, OPMN communicates OC4J process status to mod_oc4j
so that mod_oc4j
knows when OC4J processes are started and stopped. The mod_oc4j
uses this information to maintain an internal OC4J process table for rapid request routing.
Figure 2-2 illustrates a one-to-many configuration.
A one-to-many configuration, consists of one Oracle HTTP Server listener and multiple OC4J instances. In the figure below, a single Oracle HTTP Server instance is communicating with two OC4J hosts. OC4J Host 1 is running two servlet containers, and OC4J Host 2 is running one servlet container. Three connections are open between the servlet containers and a single mod_oc4j
in the OC4J instance.
A servlet container provides the runtime environment to execute servlets implementing the servlet 2.3 Application Programming Interface (API) specifications. It runs in a JVM process in the same or different host as mod_oc4j
. Each JVM has one servlet container, and the number of servlet containers is not proportional to the number of Web servers (mod_oc4j
modules). One mod_oc4j
can work with more than one servlet container and vice versa. Or, multiple mod_oc4j
modules can work with multiple servlet containers.
When a servlet container is located on the same machine as the Web server, you can set up the mod_oc4j
module to start or stop the servlet container and JVM when the Web server starts or stops, respectively. The module performs all the necessary tasks to gracefully shut down the JVM. In this scenario, mod_oc4j
can also perform failover by checking JVM status regularly and starting another JVM if the first one becomes unavailable.
JWeb classes and OC4J applications have different life cycles.
JWeb classes use the standard main()
entry point to start their execution logic. Their life cycle resembles that of a standard Java class in loading, linking, initializing, and invoking main()
.
See Also:
|
In OC4J, servlet life cycle is in compliance with servlet 2.3 specifications. The life cycle is defined by the javax.servlet.servlet
interface, which is implemented directly or indirectly by all servlets. This interface has methods which are called at specific times by the servlet engine in a particular order during a servlet's lifecycle. The init()
and destroy()
methods are invoked once per servlet lifetime, while the service()
method is called multiple times to execute the servlet's logic.
Figure 2-3 illustrates the servlet life cycle.
The JWeb cartridge and OC4J servlet container support single or multiple threads of execution, but the threading implementations are different.
Threading for the JWeb cartridge is defined in the Oracle Application Server cartridge configuration by toggling the Stateless
parameter. If the stateless parameter is set to true
, then a cartridge instance is shared by more than one client. If the stateless perimeter is set to false
, then it is not shared, and only one client can access it at any one time. Also, if Oracle Application Server is in min/max mode, the min/max cartridge servers and min/max threads values can be varied to change the way multi-threading is implemented for the cartridge.
The OC4J servlet container is multi-threaded by default. The OC4J servlet container manages the threads that service client requests. Each instance of a servlet class can be given multiple threads of execution. In this case, a servlet instance is shared between more than one client. Alternatively, you can specify a class to execute only one thread at a time by having that class implement the javax.servlet.SingleThread
interface. In this case, a pool of instances of this servlet class is maintained and each instance is assigned to one client only at any one time (instances are not shared).
In the JWeb cartridge, you can enable client sessions using the Oracle Application Server Node Manager. In OC4J, in accordance with servlet 2.3 specifications, only programmable sessions are available. Consequently, if you are migrating a JWeb application that was session-enabled by means other than code, you must implement the session mechanism programmatically using the servlet session API.
A JWeb Toolkit feature is available for generating dynamic content in HTML pages. The JWeb Toolkit embeds special placeholders in an HTML page. When this file is imported into a JWeb class as an oracle.html.HtmlFile
object, the setItemAt()
method places the data generated from the code at the placeholder locations.
Since this is a JWeb-specific feature, it is not available in Oracle Application Server 10g. If you would like to embed dynamic information in HTML pages (scripting), consider using JSP in Oracle Application Server 10g.
See Also:
Oracle Application Server Containers for J2EE Support for JavaServer Pages Developer's Guide |
OC4J provides complete support for J2EE 1.2, as well as support for major J2EE 1.3, such as complete servlet 2.3, partial EJB 2.0 (message-driven beans), complete JAAS and JCA support. If you have JWeb or JServlet applications deployed on Oracle Application Server 4.x and wish to migrate to Oracle Application Server 10g, you must modify your JWeb or JServlet applications to comply with applicable specifications for OC4J.
Table 2-1 presents the comparison of compliance standards between the JWeb and JServlet cartridges in Oracle Application Server and OC4J in Oracle Application Server 10g. When migrating JWeb or JServlet from Oracle Application Server to OC4J servlet in Oracle Application Server 10g, you must modify the code to comply with servlet 2.3 specifications.
Standard Complied | JWeb | JServlet | OC4J |
---|---|---|---|
Servlet Specifications |
NA |
2.3 |
2.3 |
JSP Specifications |
NA |
NA |
1.2 |
See Also:
http://java.sun.com
for more information regarding servlet specifications.
In order to migrate, you must understand and use the following key methods:
JWeb: contains a Java class with a main()
method, also known as JWeb cartridge. The infrastructure of JWeb maps a URL to this method.
Servlet: contains a Java class that includes a few doGet()
and doPut()
methods, specified by Sun Microsystems Inc., which map to a URL.
As a primary migration approach, you can call the main()
method of the JWeb cartridge in the corresponding doGet()
servlet method.
Specifically, you must focus on the following aspects:
oracle.html.*.
package is not available.
See Also:
http://jakarta.apache.org/ecs/index.html
for more information regarding html.*.
packages.
getClientCertificate()
and getLogin()
.
To migrate JWeb applications to OC4J, you must modify code in these areas:
You can session-enable a JWeb application with the cartridge's Client Session parameter in the "Node Manager Web Parameters" form. This allows the static parameters of an invoked class to contain per client data across calls. In OC4J, as per the servlet 2.3 API, session state is not kept in static variables of servlet classes. Instead, a session object is explicitly obtained to store session state using named attributes.
In OC4J, there is no support for configurable sessions. Therefore, you must enable sessions in code using the getSession()
method in javax.servlet.http.HttpServletRequest
, as shown below:
HttpSession session = request.getSession(true);
State information for a session can be stored subsequently and retrieved, for example, by the setAttribute(java.lang.String
, java.lang.Object)
and getAttribute(java.lang.String)
methods of javax.servlet.http.HttpSession
, respectively.
session.setAttribute("List", new Vector()); Vector list = (Vector) session.getAttribute("List");
The default session timeout for an OC4J container can be specified in the session.config
element in the XML deployment descriptors. You can use the getMaxInactiveInterval
method in the HTTPSession
interface. To set the time-out value for a container, use setMaxInactiveInterval
method.
The JWeb session time-out callback is not available in OC4J.
In JWeb, an application can manage threads using the oracle.owas.wrb.WRBRunnable
class. This class allows application threads to access request and response information. For OC4J, you only need standard Java thread management to manage application threads (the java.lang.Runnable
interface is used). For both JWeb and OC4J, using application threads is not recommended because multi-threaded applications limit the effectiveness of the load balancer.
In Oracle Application Server, JWeb applications log messages using the logger service provided by the WRB. This service allows applications to write messages to a central repository, such as a file system or database. The oracle.owas.wrb.services.logger.OutputLogStream
class interfaces with the logger service.
In Oracle Application Server 10g, OC4J generates diagnostic messages associated with servlet logging APIs. These logging files are located at ORACLE_HOME
/j2ee/home/log/
digit digit_island-name/server.log
.
Oracle Application Server includes a JWeb toolkit containing proprietary Java packages. If you used any of those packages in JWeb applications that you are migrating to Oracle Application Server, you must modify the code to use servlet 2.3 equivalent classes and methods. If no equivalent functionality is available, you must rewrite the code to implement the functionality provided by the JWeb packages.
Because some of the JWeb toolkit packages were designed specifically to interact with Oracle Application Server components such as the WRB, the functionality in these packages is not reproducible in the standard servlet API. Consequently, the migration process may also include some redesign of applications.
Table 2-2 through Table 2-8 list JWeb methods and their functional equivalents for the following servlet API classes.
Table 2-2 lists JWeb equivalents for javax.servlet.http.HttpServletRequest
Class Methods.
JWeb Method | Servlet Method |
---|---|
oracle.owas.wrb.services.http.HTTP.getHeader(String) |
getHeader(string) |
oracle.owas.wrb.services.http.HTTP.getCGIEnvironment(" |
getAuthType() |
oracle.owas.wrb.services.http.HTTP.getHeaders()Foot 1 |
getHeaderNames()Foot 2 |
oracle.owas.wrb.services.http.HTTP.getCGIEnvironment(" |
getPathInfo() |
oracle.owas.wrb.services.http.HTTP.getCGIEnvironment(" |
getPathTranslated() |
oracle.owas.wrb.services.http.HTTP.getCGIEnvironment(" |
getQueryString() |
oracle.owas.wrb.services.http.HTTP.getCGIEnvironment(" |
getMethod() |
oracle.owas.wrb.services.http.HTTP.getCGIEnvironment(" |
getRemoteUser() |
oracle.owas.wrb.services.http.HTTP.getCGIEnvironment(" |
getServletPath() |
1
return a hashtable of header names and values 2 return an enumeration of header names |
Table 2-3 lists JWeb equivalents for javax.servlet.ServletRequest
Class Methods.
JWeb equivalents for javax.servlet.ServletRequest Class Methods
Table 2-4 lists JWeb equivalents for javax.servlet.ServletResponse
Class Methods.
JWeb Method | Servlet Method |
---|---|
oracle.owas.wrb.WRBWriter |
getWriter() |
Table 2-5 lists JWeb equivalents for javax.servlet.ServletContext
Class Methods.
JWeb Method | Servlet Method |
---|---|
oracle.owas.wrb.services.http.HTTP.getCGIEnvironment(" |
getServerInfo() |
oracle.OAS.Services.Logger package |
log(String) |
Table 2-6 lists JWeb equivalents for javax.servlet.http.HttpUtils
Class Methods.
Table 2-7 lists JWeb equivalents for Javax.servlet.ServletOutputStream
Class Methods.
JWeb Method | Servlet Method |
---|---|
oracle.html.HtmlStream.print() |
javax.servlet.ServletOutputStream.print() |
oracle.html.HtmlStream.println() |
javax.servlet.ServletOutputStream.println() |
Table 2-8 lists JWeb equivalents for javax.servlet.ServletInputStream
Class Methods.
JWeb Method | Servlet Method |
---|---|
oracle.owas.wrb.services.http.MultipartElement() |
javax.servlet.ServletInputStream.readLine() |
|
![]() Copyright © 2002, 2003 Oracle Corporation. All Rights Reserved. |
|