|
Oracle® Containers for J2EE Servlet Developer's Guide
10g Release 3 (10.1.3) B14426-01 |
|
 Previous |
 Next |
|
Oracle® Containers for J2EE Servlet Developer's Guide
10g Release 3 (10.1.3) B14426-01 |
|
|
Previous |
Next |
After being deployed, a servlet is invoked by OC4J when a request for the servlet arrives from a client. The client request may come from a Web browser or a Java client application, or from another servlet in the application using the request-forward or request-include mechanism, or from a remote object on a server.
A servlet is requested through its URL mapping, which is according to how the servlet is configured and deployed, with a portion of the URL (the servlet path) being specified in the standard web.xml file, and another portion (the context path) being determined either during deployment or according to the standard application.xml file, depending on how you deploy.
The following sections cover servlet deployment and invocation:
Before discussing deployment and invocation of servlets in OC4J, we summarize some initial considerations and scenarios:
OC4J supports the following standards for deploying and managing applications in a J2EE environment:
Java Management Extensions (JMX) 1.2 specification allows standard interfaces to be created for managing resources, such as services and applications, in a J2EE environment. The OC4J implementation of JMX provides a user interface that you can use to completely manage an OC4J server and applications running within it.
Java 2 Platform, Enterprise Edition Management Specification (JSR-77) allows objects known as MBeans (managed beans) to be created for runtime management of applications in a J2EE environment. In OC4J, you can directly access MBeans through a System MBean Browser in Oracle Enterprise Manager 10g, but many of their properties are exposed in a more user-friendly way through other features of Enterprise Manager.
Java 2 Enterprise Edition Deployment API Specification (JSR-88) defines a standard API for configuring and deploying J2EE applications and modules into a J2EE-compatible environment. The OC4J implementation includes the ability to create or edit a deployment plan containing the OC4J-specific configuration data needed to deploy a component into OC4J.
The OC4J deployment plan editor and System MBean Browser are exposed through Oracle Enterprise Manager 10g Application Server Control, referred to as Application Server Control. The user interface for this is the Application Server Control Console. Additionally, for convenience, many parameters corresponding to MBeans properties, including key properties relating to Web modules, are exposed through other pages of the Application Server Control Console.
In general, avoid direct manipulation of OC4J MBeans or OC4J-specific XML configuration files where possible. The XML files are updated automatically by OC4J when you use the Application Server Control Console. For this reason, this document contains relatively few examples of OC4J-specific XML configuration, although there is reference information in Appendix B, "Web Module Configuration Files". There may be deployment situations, however, where an orion-web.xml property is not exposed through the Application Server Control Console. In these situations, directly manipulating the XML file may be the only option.
For general information about OC4J deployment, configuration, and administration, refer to the Oracle Containers for J2EE Deployment Guide and the Oracle Containers for J2EE Configuration and Administration Guide. For more information about Application Server Control, you can also refer to the introduction to administration tools in the Oracle Application Server Administrator's Guide.
During development, it is typical to use OC4J by itself, outside an Oracle Application Server environment. We refer to this standalone OC4J (or, sometimes, as unmanaged OC4J). In this scenario, OC4J can use its own Web listener and is not managed by any external Oracle Application Server processes.
By contrast, a full Oracle Application Server environment (sometimes referred to as managed OC4J), includes the use of Oracle HTTP Server as the Web listener, and the Oracle Process Manager and Notification Server (OPMN) to manage the environment.
See the Oracle Containers for J2EE Configuration and Administration Guide for additional information about Oracle Application Server versus standalone environments and about the use of Oracle HTTP Server and OPMN with OC4J.
See the Oracle HTTP Server Administrator's Guide for general information about Oracle HTTP Server and the related mod_oc4j module. (Connection to the OC4J servlet container from Oracle HTTP Server is through this module.) See the Oracle Process Manager and Notification Server Administrator's Guide for general information about OPMN.
In either an Oracle Application Server or standalone environment, you can deploy, bind, configure, and administer your J2EE applications in OC4J through the Application Server Control, introduced in "A Brief Overview of OC4J Administration". This is generally the preferred way to manage your applications, and is therefore emphasized in this document. You can deploy an application through the Application Server Control Console "Deploy" feature in the Applications tab that is accessible from the OC4J Home page. Application Server Control Console pages for Web module configuration are discussed in Appendix A, "Web Module Administration".
In standalone OC4J, you also have the option of using the command-line OC4J admin_client.jar tool to deploy and bind your J2EE applications.
Alternatively, if you use the Oracle JDeveloper tool to develop your application, you can use it to deploy and bind the application as well.
Also, in some cases and particularly during development, it may be necessary to configure aspects of an OC4J application through direct manipulation of OC4J-specific XML files. For this reason, reference documentation for these files is included in the OC4J documentation set. Elements and attributes of the global-web-application.xml (global) and orion-web.xml (application-level) OC4J-specific Web module configuration files are documented in Appendix B, "Web Module Configuration Files".
See the Oracle Containers for J2EE Deployment Guide and Oracle Containers for J2EE Configuration and Administration Guide for general information about using the Application Server Control Console or admin_client.jar tool to deploy and manage your applications. There is also extensive online help for the Application Server Control Console.
Before discussing servlet deployment and invocation, it is useful to summarize the components of a URL and what determines their values. Here is the generic construct (though note that pathinfo is usually empty):
protocol://host:port/contextpath/servletpath/pathinfo
You can also have additional information following any delimiters, such as request parameter settings following a question mark ("?") delimiter:
protocol://host:port/contextpath/servletpath/pathinfo?param1=value1...
Table 3-1 describes the components of the generic construct.
Table 3-1 URL Components
| Component | Description |
|---|---|
| Protocol | The network protocol to be used when invoking the Web application. General examples are HTTP, HTTPS, FTP, or ORMI (for EJBs). In a standalone environment, OC4J typically uses HTTP protocol directly through its own Web listener. In an Oracle Application Server environment, Oracle HTTP Server is the Web listener and it uses AJP (Apache JServ Protocol) to communicate to OC4J, although AJP is invisible to the end user.
Protocol for an OC4J Web site is reflected in the |
| Host | The network name of the server that the Web application is running on. If the Web client is on the same system as the application server, you can use localhost. Otherwise, use the host name (as defined in /etc/hosts on a UNIX system, for example), such as:
www.example.com |
| Port | The server port that the Web server listens on. If a URL does not specify a port, most browsers assume port 80 for HTTP protocol or port 443 for HTTPS.
The port number for an OC4J Web site is reflected in the Refer to the Oracle Containers for J2EE Configuration and Administration Guide for general information about OC4J Web site configuration and Web site XML files. |
| Context path (sometimes referred to as context root) | The designated root path for the servlet context. When you deploy an EAR file using the Application Server Control Console, this is according to a <context-root> element in the standard application.xml file within the EAR file, as shown in "Create the application.xml File".
When you deploy a WAR file using the Application Server Control Console, you can specify the context path during deployment. When you deploy an EAR file using In OC4J, the specified context path is reflected in the setting of the The <web-app application="ojspdemos" name="ojspdemos-web"
root="/ojspdemos" />
When you deploy a WAR file by itself, it is associated with the OC4J default J2EE application. |
| Servlet path | The designated path, beyond the context path, for the particular servlet you want to invoke. Specify the servlet path through standard mappings in the Web module web.xml file.
A servlet class is mapped to a servlet name of your choosing through <web-app>
...
<servlet>
<servlet-name>logout</servlet-name>
<servlet-class>
oracle.security.jazn.samples.http.Logout
</servlet-class>
</servlet>
...
<servlet-mapping>
<servlet-name>logout</servlet-name>
<url-pattern>/logout/*</url-pattern>
</servlet-mapping>
...
</web-app>
|
| Path information | (This is typically empty.) Beyond the context path and servlet path, a URL can contain additional information that is supplied to the servlet through the HTTP request object. Such information is presumably understood by the servlet. This information is separate from any request parameter settings or other URL components that follow delimiters such as question marks. Such delimiters would follow any path information. |
|
Note: The name specified in a<servlet-name> element is the name you input to the servlet context getNamedDispatcher() method if you want a request dispatcher for that servlet.
|
Consider the following sample URL:
http://www.example.com:port/foo/bar/mypath/myservlet/info1/info2?user=Amy
In the process of invoking a servlet according to a URL supplied by a client browser, the servlet container takes the following steps:
It examines everything in the URL after the port number, then examines its own configuration settings (such as in a Web site XML file) for recognized context paths, then determines what part of the URL is the context path.
Assume for this example that /foo/bar is the context path.
It examines everything in the URL after the context path, then examines the servlet mappings in the web.xml file for recognized servlet paths, then determines what part of the URL is the servlet path.
At this point, the servlet can be invoked. The servlet container does not use any information beyond the servlet path.
Assume for this example that /mypath/myservlet is the servlet path.
If anything remains in the URL after the servlet path and preceding any URL delimiters (such as "?" in this example, which delimits request parameter settings), that portion of the URL is taken as extra information and is passed to the servlet through the HTTP request object.
Assume for this example that /info1/info2 is the extra path information.
As shown in this example, the context path, servlet path, and any path information can all be "compound" components, with one or more forward-slashes between parts. In many cases, the context path may be simple, such as just foo, and the servlet path may also be simple, such as just myservlet, and any path information may be simple as well. But it is impossible to know by just looking at a URL what part of it is the context path, what part is the servlet path, and what part is extra path information (if any). You must examine the configuration in the Web site XML file and web.xml file to determine this.
|
Notes:
|
In OC4J, according to the J2EE specification, you deploy a J2EE application as an EAR file. The EAR file contents include zero or more WAR files for Web applications (combinations of servlets and JSP pages) that are part of the overall J2EE application.
If you want to deploy a Web application only, you can either package the WAR file inside an EAR file, effectively defining a J2EE wrapper application, or you can deploy the WAR file directly.
The following sections, after a review of standard application structure, discuss the general steps for each approach:
Note that this discussion does not go into detail—it is intended only as a summary. See the Oracle Containers for J2EE Deployment Guide for specific information and procedures for deploying to OC4J.
The standard Web application structure, as specified in the Java Servlet Specification, is as follows:
root_directory/ Static files (for example, index.html) JSP pages WEB-INF/ web.xml classes/ servlet classes (directory substructure according to Java package) lib/ JAR files (libraries and dependency classes)
This structure is reflected in the structure of a standard WAR file, used to deploy a Web application. The standard web.xml file, also specified in the Java Servlet Specification, is where you configure servlets and JSP pages (among other things). See "Summary of General Steps to Deploy a WAR File", which follows shortly, for additional information about WAR files and web.xml.
|
Note: For OC4J-specific Web module settings, you can include anorion-web.xml under /WEB-INF along with the web.xml file. Alternatively, you can let OC4J create the orion-web.xml file automatically and use the Application Server Control Console for OC4J-specific settings (which are then reflected in orion-web.xml).
|
The standard J2EE application structure, as specified in the Java 2 Enterprise Edition Specification, is a superset of the Web application structure, as follows:
root_directory/ META-INF/ application.xml WebModule/ Static files (for example, index.html) JSP pages WEB-INF/ web.xml classes/ servlet classes (directory substructure according to Java package) lib/ JAR files (libraries and dependency classes) EJBModule/... ClientModule/... ResourceAdapterModule/...
This structure is reflected in the structure of a standard EAR file, used to deploy a J2EE application and the WAR and other archive files that it contains. The standard application.xml file, also specified in the Java 2 Enterprise Edition Specification, is where you configure a J2EE application and its modules, including Web modules. The EAR file contains any WAR files, EJB JAR files, application client JAR files, and resource adapter RAR files containing modules for the application. See "Summary of General Steps to Deploy an EAR File", which follows shortly, for additional information about EAR files and application.xml.
|
Note: For OC4J-specific J2EE application settings, it is permissible to include anorion-application.xml file under /META-INF along with the standard application.xml file. But it is more typical to let OC4J create the orion-application.xml file automatically and to use the Application Server Control Console for OC4J-specific settings (which are then reflected in orion-application.xml). See the Oracle Containers for J2EE Developer's Guide for information about the orion-application.xml file.
|
To deploy a Web application directly as a WAR file (as opposed to putting the WAR file into a J2EE EAR file), use the following general steps.
Create a standard web.xml file to configure the Web application. A web.xml file is required within a WAR file. Within the top-level <web-app> element, use <servlet> and <servlet-mapping> subelements to configure servlets and JSP pages.
Map a servlet class to a URL servlet path by using the <servlet-name> and <servlet-class> subelements of a <servlet> element, and the <servlet-name> and <url-pattern> subelements of a <servlet-mapping> element. The name is of your choosing but should be logical; its purpose is simply to map the servlet class to the servlet path.
<web-app>
...
<servlet>
<servlet-name>servletname</servlet-name>
<servlet-class>package.Classname</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>servletname</servlet-name>
<url-pattern>servletpath</url-pattern>
</servlet-mapping>
...
</web-app>
Create a WAR file to contain your Web application components and web.xml file, from the root directory of a directory structure that parallels the Web application structure shown in "Application Structure".
Deploy the WAR file to OC4J. If you use the Application Server Control Console "Deploy" feature (available from the Applications tab that is accessible from the OC4J Home page), this includes the opportunity to supply or create, and optionally edit, a standard JSR-88-compliant deployment plan.
Bind the Web application. This is the process that associates the Web application with an OC4J Web site, and associates a URL context path to use in accessing the Web application. When you use the Application Server Control Console to deploy a WAR file, binding is included in the deployment steps and you have the opportunity to specify the context path.
|
Note: You cannot configure parameters that would correspond to anorion-application.xml file when you deploy a standalone WAR file, because there can be no orion-application.xml file within a WAR file. You would have to package the WAR file in an EAR file to configure such parameters. See "Application Structure" for related information.
|
To deploy a Web application as a WAR file within an EAR file, as opposed to deploying the WAR file directly, use the following steps.
Create a web.xml file and WAR file for the Web application, as described in the preceding section, "Summary of General Steps to Deploy a WAR File".
Create a standard application.xml file, which configures a J2EE application. An application.xml file is required within an EAR file. In particular, map the Web application you are deploying to a URL context path—this is where Application Server Control obtains context path information, which is subsequently written to the Web site XML file.
Within a <web> element, use a <web-uri> subelement to specify the WAR file name, together with a <context-root> subelement to specify the context path.
<application>
...
<module>
<web>
<web-uri>warname.war</web-uri>
<context-root>contextpath</context-root>
</web>
</module>
...
</application>
Create an EAR file to contain your application components and application.xml file, from the root directory of a directory structure that parallels the J2EE application structure shown in "Application Structure".
Deploy the EAR file to OC4J. If you use the Application Server Control Console "Deploy" feature (available from the Applications tab that is accessible from the OC4J Home page), this includes the opportunity to supply or create, and optionally edit, a standard JSR-88-compliant deployment plan.
Bind any Web application to be invoked. This is the process that associates the Web application with an OC4J Web site, and associates a URL context path to use in accessing the Web application. When you use the Application Server Control Console to deploy an EAR file, binding of a Web application is included in the deployment steps, and the context path is according to the standard application.xml file that you provided in the EAR file, as noted in the preceding text.
This section discusses how to invoke a servlet in a standalone OC4J environment versus an Oracle Application Server environment, and covers special OC4J features for invoking a servlet by class name in a development or testing scenario:
In a standalone OC4J environment, a Web site uses HTTP protocol directly through the OC4J Web listener, without going through the Oracle HTTP Server, and is configured according to settings in the default-web-site.xml file. (This is the typical name, but Web site XML file names are according to settings in the server.xml file and can be changed as desired.)
When a servlet is requested, the OC4J servlet container interprets the URL as described in "Summary of URL Components", which also discusses considerations in how the context path and servlet path are determined. By default in standalone OC4J, the port is 8888, which is used for many examples in this document (given that it is a developer's guide).
If "/mypath" is the context path and "/myservlet" is the servlet path, for example, you will invoke the servlet with a URL such as the following:
http://www.example.com:8888/mypath/myservlet
For a development or testing scenario in standalone OC4J, there is a convenience mechanism for invoking a servlet by class name. For security reasons, use this mechanism only while developing or testing your application.
With a true setting of the OC4J system property http.webdir.enable (where false is the default), the servlet-webdir attribute in the <orion-web-app> element of the global-web-application.xml file or orion-web.xml file defines a special URL component used to invoke servlets by class name. This URL component follows the context path in the URL, and anything following this URL component is assumed to be a servlet class name, including applicable package information. The servlet class name appears instead of a servlet path in the URL. (Technically, the servlet-webdir value is the servlet path and acts as a servlet itself, and the class name of the servlet you wish to execute is taken as path information.)
OC4J will look for the class under the /WEB-INF/classes directory (in a subdirectory according to the package) or in a JAR file in the /WEB-INF/lib directory of the Web application associated with the context path.
|
Notes:
|
Generally speaking, for any given application in a scenario with the true setting of http.webdir.enable, OC4J behavior for invocation by class name is determined by the servlet-webdir setting in the orion-web.xml file for that application, if there is a setting. But note the following:
Any setting of servlet-webdir in the global-web-application.xml file acts as a default value (as is true with configuration settings in global-web-application.xml in general). If there is no servlet-webdir setting in global-web-application.xml, however, then the default value is "" (empty quotes). This setting disables invocation by class name. The default value is used in the event that orion-web.xml is not included with the application deployment, or does not have a servlet-webdir setting.
You can disable servlet invocation by class name in either of two ways:
Use the default false value of the system property http.webdir.enable. This results in any servlet-webdir setting being ignored. (See the Oracle Containers for J2EE Configuration and Administration Guide for general information about OC4J system properties.)
Set a servlet-webdir value of "" (empty quotes), either through global-web-application.xml or orion-web.xml.
The servlet-webdir attribute is also discussed in "<orion-web-app>".
Assuming a context path of "/mypath" and a setting of servlet-webdir="/servlet/", the following URL invokes the servlet foo.bar.SessionServlet by its class name:
http://www.example.com:8888/mypath/servlet/foo.bar.SessionServlet
|
Important: Allowing the invocation of servlets by class name presents a significant security risk. Do not configure OC4J to operate in this mode in a production environment. See "Best Practices for Security" for information. |
In an Oracle Application Server environment, OC4J is accessed through the Oracle HTTP Server, which uses AJP protocol to communicate to OC4J. (AJP is invisible to the end user.) A Web site is configured according to settings in the default-web-site.xml file. (This is the typical name, but Web site XML file names are according to settings in the server.xml file and can be changed as desired.)
When a servlet is requested, the OC4J servlet container interprets the URL as described in "Summary of URL Components", which also discusses considerations in how the port, context path, and servlet path are determined.
If "/mypath" is the context path and "/myservlet" is the servlet path, for example, you will invoke the servlet with a URL such as the following (with an appropriate port number):
http://www.example.com:port/mypath/myservlet
In this section, we deploy and invoke the servlet shown in "Simple Servlet Example". First we deploy it directly as a WAR file, then as a WAR file within an EAR file.
In this section, we use the following steps, first outlined in "Summary of General Steps to Deploy a WAR File", to deploy the simple servlet example directly as a WAR file:
See "Invoke the Servlet Example" for execution of the servlet, and for how some of the deployment specifications are reflected in the URL of the servlet.
Here is a web.xml file for the simple servlet example. The <servlet-class> element reflects the package name and class name specified in HelloWorld.java, shown in "Write the Sample Code". The <url-pattern> element specifies myhello as the servlet path portion of the URL to use in invoking the servlet. The servlet name maps the class name to the servlet path.
<?xml version="1.0"?>
<!DOCTYPE web-app (doctype...)>
<web-app>
<servlet>
<servlet-name>hello</servlet-name>
<servlet-class>mytest.HelloWorld</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>hello</servlet-name>
<url-pattern>myhello</url-pattern>
</servlet-mapping>
</web-app>
Here is the directory structure for the simple servlet example, according to the standard Web application structure:
root_directory/
WEB-INF/
web.xml
classes/
mytest/
HelloWorld.class
HelloWorld.java
The WAR file must reflect this structure. If you want to create the WAR file manually, you can use the JAR utility, with the following command, while your current directory is the root directory (assume % is the system prompt):
% jar cvf MyHelloWorld.war .
This generates the WAR file MyHelloWorld.war, with the following contents and structure (where the Manifest.mf file and META-INF directory are created automatically):
META-INF/Manifest.mf WEB-INF/web.xml WEB-INF/classes/mytest/HelloWorld.class WEB-INF/classes/mytest/HelloWorld.java
The WAR file name should reflect the key Web component name. In this case, it reflects the class name of the servlet example.
Deploy the WAR file, typically through Application Server Control "Deploy" feature (available from the Applications tab, which is accessible from the OC4J Home page).
In the Application Server Control Console:
Specify the WAR file.
Instruct Application Server Control to create a new deployment plan.
Specify an application (Web application) name, which should reflect the WAR file name.
Specify the parent application (the OC4J default application by default).
Specify the Web site for binding the Web application, such as default-web-site.
Specify the context path (or use the default, derived from the WAR file name). For this example, specify "/mycontext".
|
Note: If you useadmin_client.jar instead of the Application Server Control Console, deploying and binding are separate steps, and you specify the context path when you bind. See the Oracle Containers for J2EE Deployment Guide for information.
|
In this section, we use the following steps, first outlined in "Summary of General Steps to Deploy an EAR File", to deploy the simple servlet example as a WAR file within an EAR file:
See "Invoke the Servlet Example" for execution of the servlet, and for how some of the deployment specifications are reflected in the URL of the servlet.
First, create the web.xml file and WAR file, as you would if you were deploying the WAR file directly. This is described in "Create the web.xml File" and "Create the WAR File".
Here is an application.xml file for the simple servlet example, to use in deploying the servlet in a WAR file within an EAR file. When you use the Application Server Control Console to deploy, this is where the context path is determined; then it is subsequently written to the Web site XML file. The <web-uri> element indicates the name of the WAR file. The <context-root> element ties the Web application of the WAR file (in this case, the servlet example) to the desired URL context path, /mycontext.
<?xml version = '1.0' encoding = 'UTF-8'?>
<!DOCTYPE web-app (doctype...)>
<application>
<module>
<web>
<web-uri>MyHelloWorld.war</web-uri>
<context-root>/mycontext</context-root>
</web>
</module>
</application>
|
Note: When you useadmin_client.jar to deploy an EAR file and bind a contained Web application, you specify the context path directly when you bind the Web application.
|
Before creating the EAR file, follow these steps to prepare your directory structure:
From your desired root directory, create a META-INF subdirectory.
Place the application.xml file in META-INF, according to the standard J2EE application structure.
Place the WAR file in the root directory.
This results in the following directory structure:
root_directory/
META-INF/
application.xml
MyHelloWorld.war
If you want to create the EAR file manually, you can use the JAR utility, with the following command, while your current directory is the root directory (assume % is the system prompt):
% jar cvf MyHelloWorld.ear .
This generates the EAR file MyHelloWorld.ear, with the following contents and structure (where the Manifest.mf file is created automatically):
MyHelloWorld.war META-INF/application.xml META-INF/Manifest.mf
Deploy the EAR file, typically through the Application Server Control "Deploy" feature (available from the Applications tab, which is accessible from the OC4J Home page).
In the Application Server Control Console:
Specify the EAR file.
Instruct Application Server Control to create a new deployment plan.
Specify a J2EE application name, which should reflect the EAR file name.
Specify the parent application (the OC4J default application by default).
Specify the Web site for binding the Web application, such as default-web-site.
|
Note: If you useadmin_client.jar instead of the Application Server Control Console, deploying an EAR file and binding a contained Web application are separate steps. See the Oracle Containers for J2EE Deployment Guide for information.
|
Given the WAR file deployment or EAR file deployment shown previously (both of which specify the same servlet path and context path), invoke the servlet as follows, specifying the appropriate host name. The URL here assumes an OC4J port number of 8888, which is the default for OC4J in a standalone environment.
http://www.example.com:8888/mycontext/myhello
The servlet path, myhello, is according to the web.xml file you provided during deployment. The context path, /mycontext, is according to either the application.xml file or according to your specification in binding the Web application, as discussed earlier. ("Summary of URL Components" includes discussion of context paths.)
Here is the output of the servlet:
Typically, the servlet container instantiates and loads a servlet class when it is first requested, such as by direct request through the browser, or through an include or forward. However, if you want any servlets to start as soon as the server starts, you can arrange for them to be preloaded through settings in the server.xml file, the Web site XML file (such as default-web-site.xml), and the web.xml file. Preloaded servlets are loaded and initialized when the OC4J server starts up or when the Web application is deployed or redeployed.
Preloading requires the following steps:
Verify that the relevant <application> element in the server.xml file has the attribute setting auto-start="true". OC4J inserts this setting by default when you deploy an application.
Specify the attribute setting load-on-startup="true" in the relevant <web-app> subelement of the <web-site> element of the Web site XML file. (See the Oracle Containers for J2EE Configuration and Administration Guide for information about OC4J Web site XML files.)
For any servlet that you want to preload, there must be a <load-on-startup> subelement under the <servlet> element in the web.xml file for the Web module.
Table 3-2 explains the behavior of the <load-on-startup> element in web.xml.
Table 3-2 File web.xml <load-on-startup> Behavior
| Value Range | Behavior |
|---|---|
| Less than zero (<0)
For example: <load-on-startup>-1</load-on-startup> |
Servlet is not preloaded. |
| Greater than or equal to zero (>=0)
For example: <load-on-startup>1</load-on-startup> |
Servlet is preloaded. The order of its loading, with respect to other preloaded servlets in the same Web application, is according to the load-on-startup value, lowest number first. (For example, 0 is loaded before 1, which is loaded before 2.) |
| Empty element
For example: <load-on-startup/> |
The behavior is as if the load-on-startup value is Integer.MAX_VALUE, ensuring that the servlet is loaded after any servlets with load-on-startup values greater than or equal to zero.
|
|
Note: OC4J supports the specification of startup classes and shutdown classes, described in detail in the Oracle Containers for J2EE Developer's Guide. Startup classes are designated through the<startup-classes> element of the server.xml file and are called immediately after OC4J initializes. Shutdown classes are designated through the <shutdown-classes> element of server.xml and are called immediately before OC4J terminates.
Be aware that startup classes are called before any preloaded servlets. |
