|
|
|
|
| |
This section provides information about writing HTTP servlets in a WebLogic Server environment. The following topics are discussed:
When a servlet is initialized, WebLogic Server executes the init() method of the servlet. Once the servlet has been initialized, it is not initialized again until you restart WebLogic Server or the servlet code is recompiled and reloaded. By overriding the init() method, your servlet can perform certain tasks, such as establishing database connections, when the servlet is initialized.
Normally, WebLogic Server initializes a servlet when the first request is made for the servlet. Subsequently, if the servlet is modified, the destroy() method is called on the existing version of the servlet. Then, after a request is made for the modified servlet, the init() method of the modified servlet is executed. For more information, see Servlet Development Tips.
Initializing a Servlet when WebLogic Server Starts
You can also configure WebLogic Server to initialize a servlet when the server starts by specifying the servlet class in the <load-on-startup> element in the Web Application deployment descriptor. For more information see "Servlet element".
You can pass parameters to an HTTP servlet during initialization by defining these parameters in the Web Application containing the servlet. You can use these parameters to pass values to your servlet every time the servlet is initialized without having to rewrite the servlet. For more information see "Writing Web Application Deployment Descriptors".
For example, the following entries in the Web Application deployment descriptor define two initialization parameters: greeting, which has a value of Welcome and person, which has a value of WebLogic Developer.
<servlet>
...
<init-param>
<param-name>greeting</param-name>
<param-value>Welcome</param-value>
<description>The salutation</description>
</init-param>
<init-param>
<param-name>person</param-name>
<param-value>WebLogic Developer</param-value>
<description>name</description>
</init-param>
</servlet>
To retrieve initialization parameters by call the getInitParameter(String name) method from the parent javax.servlet.GenericServlet class. When passed the name of the parameter, this method returns the parameter's value as a String.
You can have your servlet execute tasks at initialization time by overriding the init() method. The following code fragment reads the <init-param> tags that define a greeting and a name in the Web Application deployment descriptor:
String defaultGreeting;
String defaultName;
public void init(ServletConfig config)
throws ServletException {
if ((defaultGreeting = getInitParameter("greeting")) == null)
defaultGreeting = "Hello";
if ((defaultName = getInitParameter("person")) == null)
defaultName = "World";
}
The values of each parameter are stored in the class instance variables defaultGreeting and defaultName. Note that the first code tests to see if the parameters have null values and, if null values are returned, provides appropriate default values.
You can then use the service() method to use these variables in the response. For example:
out.print("<body><h1>");
out.println(defaultGreeting + " " + defaultName + "!");
out.println("</h1></body></html>");
The full source code and instructions for compiling, installing, and trying out an example called HelloWorld2.java, which illustrates the use of the init() method, can be found in the samples/examples/servlets directory of your WebLogic Server distribution.
This section describes how to provide a response to the client in your HTTP servlet. All responses should be delivered using the HttpServletResponse object that is passed as a parameter to the service() method of your servlet.
Using the HttpServletResponse object, you can set several servlet properties that are translated into HTTP header information:
res.setContentType("text/html");
res.setContentType("text/html;ISO-88859-4");
res.setHeader("Pragma", "no-cache");
The response that your servlet sends back to the client must look like regular HTTP content. For the most part, this means you must send back a response that is formatted as an HTML page.Your servlet sends back an HTTP response via an output stream that you obtain using the response parameter of the service() method. To send an HTTP response:
You can use both PrintWriter and ServletOutputStream in the same servlet (or in another servlet that is included in a servlet). The output of both is written to the same buffer.
out.print("<html><head><title>My Servlet</title>");
out.print("</head><body><h1>");
out.print("Welcome");
out.print("</h1></body></html>");
Do not close the output stream using the close() method and avoid flushing the contents of the stream. If you do not close or flush the output stream, WebLogic Server can take advantage of persistent HTTP connections, as described in the next step.
By default, WebLogic Server attempts to use HTTP persistent connections whenever possible. A persistent connection attempts to reuse the same HTTP TCP/IP connection for a series of communications between client and server. Application performance improves because a new connection need not be opened for each request. Persistent connections are useful for HTML pages containing many in-line images, where each requested image would otherwise require a new TCP/IP connection.
You can configure the amount of time that WebLogic Server keeps an HTTP connection open using the WebLogic Server Administration Console. For more information, see "KeepAliveSecs".
WebLogic Server must know the length of the HTTP response in order to establish a persistent connection and automatically adds a Content-Length property to the HTTP response header. In order to determine the content length, WebLogic Server must buffer the response. However, if your servlet explicitly flushes the ServletOutputStream, WebLogic Server is unable to determine the length of the response and therefore cannot use persistent connections. For this reason, you should avoid explicitly flushing the HTTP response in your servlets.
You may decide that, in some cases, it is better to flush the response early to display information in the client before the page has completed, for example to display a banner advertisement while some time-consuming page content is calculated. Conversely, you may want to increase the size of the buffer used by the servlet engine to accommodate a larger response before flushing the response. You can manipulate the size of the response buffer by using the related methods of the javax.servlet.ServletResponse interface .
The HTTP servlet API provides a clean interface for retrieving user input from Web pages.
An HTTP request from a Web browser can be accompanied by information besides the URL, such as information about the client, the browser, cookies, and user query parameters. Query parameters are used to carry user input from the browser, and are either appended to the URL address (the GET method) or included in the HTTP request body (the POST method).
HTTP servlets need not deal with these details; all the information in a request is made available through the HttpServletRequest object and can be accessed using the request.getParameters() method, regardless of the send method.
You can send query parameters from the client in a number of ways:
<a href=
"http://localhost:7001/myWebApp/ColorServlet?color=purple">
Click Here For Purple!</a>
Query parameters are always sent in name=value pairs, and are accessed through the HttpServletRequest object. You can obtain an Enumeration of all parameter names in a query, and fetch each parameter value using its parameter name. A parameter usually has only one value, but it can also hold an array of values. Parameter values are always interpreted as Strings, so you may need to cast them to a more appropriate type.
The following sample from a service() method examines query parameter names and their values from a form. Note that request is the HttpServletRequest object.
Enumeration params = request.getParameterNames();
String paramName = null;
String[] paramValues = null;
while (params.hasMoreElements()) {
paramName = (String) params.nextElement();
paramValues = request.getParameterValues(paramName);
System.out.println("\nParameter name is " + paramName);
for (int i = 0; i < paramValues.length; i++) {
System.out.println(", value " + i + " is " +
paramValues[i].toString());
}
}
Other Methods for Using the HTTP Request
This section defines the methods of the javax.servlet.HttpServletRequest interface that you can use to get data from the request object. You should keep the following limitations in mind:
If you attempt either of these procedures, an illegalStateException is thrown.
Example: Retrieving Input by Using Query Parameters
In this example, the HelloWorld2.java servlet example is modified to accept a username as a query parameter, in order to display a more personal greeting. (For the complete code, see the HelloWorld3.java servlet example, located in the samples/examples/servlets directory of your WebLogic Server distribution.) The service() method is shown here:
Listing 3-1
public void service(HttpServletRequest req,
HttpServletResponse res)
throws IOException
{
String name, paramName[];
if ((paramName = req.getParameterValues("name"))
!= null) {
name = paramName[0];
}
else {
name = defaultName;
}
// Set the content type first
res.setContentType("text/html");
// Obtain a PrintWriter as an output stream
PrintWriter out = res.getWriter();
out.print("<html><head><title>" +
"Hello World!" + </title></head>");
out.print("<body><h1>");
out.print(defaultGreeting + " " + name + "!");
out.print("</h1></body></html>");
}
The getParameterValues() method retrieves the value of the name parameter from the HTTP query parameters. You retrieve these values in an array of type String. A single value for this parameter is returned and is assigned to the first element in the name array. If the parameter is not present in the query data, null is returned; in this case, name is assigned to the default name that was read from the <init-param> by the init() method.
Your servlet code should not presume that parameters are included in an HTTP request. Because the getParameter() method has been deprecated, you might be tempted to shorthand the getParameterValues() method by tagging an array subscript to the end. However, this method can return null if the specified parameter is not available, resulting in a NullPointerException.
For example, the following code will trigger a NullPointerException:
String myStr = req.getParameterValues("paramName")[0];
Instead, use the following code:
if ((String myStr[] =
req.getParameterValues("paramName"))!=null) {
// Now you can use the myStr[0];
}
else {
// paramName was not in the query parameters!
}
Using Session Tracking from a Servlet
Session tracking enables you to track a user's progress over multiple servlets or HTML pages, which, by nature, are stateless. A session is defined as a series of related browser requests that come from the same client during a certain time period. Session tracking ties together a series of browser requests-think of these requests as pages-that may have some meaning as a whole, such as a shopping cart application.
Before session tracking matured conceptually, developers tried to build state into their pages by stuffing information into hidden fields on a page or embedding user choices into URLs used in links with a long string of appended characters. You can see good examples of this at most search engine sites, many of which still depend on CGI. These sites track user choices with URL parameter name=value pairs that are appended to the URL, after the reserved HTTP character ?. This practice can result in a very long URL that the CGI script must carefully parse and manage. The problem with this approach is that you cannot pass this information from session to session. Once you lose control over the URL-that is, once the user leaves one of your pages-the user information is lost forever.
Later, Netscape introduced browser cookies, which enable you to store user-related information about the client for each server. However, some browsers still do not fully support cookies, and some users prefer to turn off the cookie option in their browsers. Another factor that should be considered is that most browsers limit the amount of data that can be stored with a cookie.
The HTTP servlet specification defines a solution that allows the server to store user details on the server, and protects your code from the complexities of tracking sessions. Your servlets can use an HttpSession object to track a user's input over the span of a single session and to share session details among multiple servlets.
Tracking a Session with an HttpSession Object
According to the Java Servlet API, which WebLogic Server implements and supports, each servlet can access a server-side session by using its HttpSession object. You can access an HttpSession object in the service() method of the servlet using the HttpServletRequest object, as shown in the following example using the variable request:
HttpSession session = request.getSession(true);
An HttpSession object is created if one does not already exist for that client when the request.getSession(true)method is called with the argument true. The session object lives on WebLogic Server for the lifetime of the session, during which the session object accumulates information related to that client. Your servlet adds or removes information from the session object as necessary. A session is associated with a particular client. Each time the client visits your servlet, the same associated HttpSession object is retrieved when the getSession() method is called.
For more details on the methods supported by the HttpSession, refer to the HttpServlet API.
In the following example, the service() method counts the number of times a user requests the servlet during a session.
public void service(HttpServletRequest request,
HttpServletResponse, response)
throws IOException
{
// Get the session and the counter param attribute
HttpSession session = request.getSession (true);
Integer ival = (Integer)
session.getAttribute("simplesession.counter");
if (ival == null) // Initialize the counter
ival = new Integer (1);
else // Increment the counter
ival = new Integer (ival.intValue () + 1);
// Set the new attribute value in the session
session.setAttribute("simplesession.counter", ival);
// Output the HTML page
out.print("<HTML><body>");
out.print("<center> You have hit this page ");
out.print(ival + " times!");
out.print("</body></html>");
}
A session tracks the selections of a user over a series of pages in a single transaction. A single transaction may consist of several tasks, such as searching for an item, adding it to a shopping cart, and then processing a payment. A session is transient, and its lifetime ends when one of the following occurs:
For more persistent, long-term storage of data your servlet should write details to a database using JDBC or EJB and associate the client with this data using a long-lived cookie and/or username and password. Although this document describes that sessions use cookies and persistence internally, you should not use sessions as a general mechanism for storing data about a user.
How does WebLogic Server know which session is associated with each client? When an HttpSession is created in a servlet, it is associated with a unique ID. The browser must provide this session ID with its request in order for the server to find the session data again. The server attempts to store this ID by setting a cookie on the client. Once the cookie is set, each time the browser sends a request to the server it includes the cookie containing the ID. The server automatically parses the cookie and supplies the session data when your servlet calls the getSession() method.
If the client does not accept cookies, the only alternative is to encode the ID into the URL links in the pages sent back to the client. For this reason, you should always use the encodeURL() method when you include URLs in your servlet response. WebLogic Server knows whether the browser accepts cookies and does not unnecessarily encode URLs. WebLogic automatically parses the session ID from an encoded URL and retrieves the correct session data when you call the getSession() method. Using the encodeURL() method ensures no disruption to your servlet code, regardless of the procedure used to track sessions. For more information, see Using URL Rewriting.
Detecting the Start of a Session
After you obtain a session using the getSession(true) method, you can tell whether the session has just been created by calling the HttpSession.isNew() method. If this method returns true, then the client does not already have a valid session, and at this point it is unaware of the new session. The client does not become aware of the new session until a reply is posted back from the server.
Design your application to accommodate new or existing sessions in a way that suits your business logic. For example, your application might redirect the client's URL to a login/password page if you determine that the session has not yet started, as shown in the following code example:
HttpSession session = request.getSession(true);
if (session.isNew()) {
response.sendRedirect(welcomeURL);
}
On the login page, provide an option to log in to the system or create a new account. You can also specify a login page in your Web Application. For more information, see login-config.
Setting and Getting Session Name/Value Attributes
You can store data in an HttpSession object using name=value pairs. Data stored in a session is available through the session. To store data in a session, use these methods from the HttpSession interface:
getAttribute()
getAttributeNames()
setAttribute()
removeAttribute()
The following code fragment shows how to get all the existing name=value pairs:
Enumeration sessionNames = session.getAttributeNames();
String sessionName = null;
Object sessionValue = null;
while (sessionNames.hasMoreElements()) {
sessionName = (String)sessionNames.nextElement();
sessionValue = session.getAttribute(sessionName);
System.out.println("Session name is " + sessionName +
", value is " + sessionValue);
}
To add or overwrite a named attribute, use the setAttribute() method. To remove a named attribute altogether, use the removeAttribute() method.
Note: You can add any Java descendant of Object as a session attribute and associate it with a name. However, if you are using session persistence, your attribute value objects must implement java.io.Serializable.
Logging Out and Ending a Session
If your application deals with sensitive information you might consider offering the ability to log out of the session. This is a common feature when using shopping carts and Internet email accounts. When the same browser returns to the service, the user must log back in to the system. To log a user out of a session, invalidate the current session by calling the following method:
session.invalidate()
Do not reference an invalidated session after calling this method. If you do, an IllegalStateException is thrown. The next time a user visits your servlet from the same browser, the session data will be missing, and a new session will be created when you call the getSession(true) method. At that time you can send the user to the login page again.
WebLogic Server provides many configurable attributes that determine how WebLogic Server handles session tracking. For details about configuring these session tracking attributes, see "Session descriptor".
In some situations, a browser may not accept cookies, which means that session tracking using cookies is not possible. URL rewriting is a workaround to this scenario that can be substituted automatically when WebLogic Server detects that the browser does not accept cookies. URL rewriting involves encoding the session ID into the hyperlinks on the Web pages that your servlet sends back to the browser. When the user subsequently clicks these links, WebLogic Server extracts the ID from the URL and finds the appropriate HttpSession. Then you use the getSession() method to access session data.
To enable URL rewriting in WebLogic Server, set the UrlRewritingEnabled attribute to true in the Session descriptor element of the WebLogic-specific deployment descriptor.
To make sure your code correctly handles URLs in order to support URL rewriting, consider the following guidelines:
out.println("<a href=\"/myshop/catalog.jsp\">catalog</a>");
Instead, use the HttpServletResponse.encodeURL() method. For example:
out.println("<a href=\""
+ response.encodeURL("myshop/catalog.jsp")
+ "\">catalog</a>");
if (session.isNew())
response.sendRedirect(response.encodeRedirectUrl(welcomeURL));
WebLogic Server uses URL rewriting when a session is new, even if the browser accepts cookies, because the server cannot determine, during the first visit of a session, whether the browser accepts cookies.
Your servlet may determine whether a given session was returned from a cookie by checking the Boolean returned from the HttpServletRequest.isRequestedSessionIdFromCookie() method. Your application may respond appropriately, or it may simply rely on URL rewriting by WebLogic Server.
URL Rewriting and Wireless Access Protocol (WAP)
If you are writing a WAP application, you must use URL rewriting because the WAP protocol does not support cookies. In addition, some WAP devices impose a 128-character limit (including parameters) on the length of a URL, which limits the amount of data that can be transmitted using URL rewriting. To allow more space for parameters, you can limit the size of the session ID that is randomly generated by WebLogic Server by specifying the number of bytes with the IDLength attribute in the session-descriptor element of the WebLogic-specific deployment descriptor, weblogic.xml.
The minimum value is 8 bytes; the default value is 52 bytes; the maximum value is Integer.MAX_VALUE.
You can set up WebLogic Server to record session data in a persistent store. If you are using session persistence, you can expect the following characteristics:
Scenarios to Avoid When Using Sessions
Do not use session persistence for storing long-term data between sessions. In other words, do not rely on a session still being active when a client returns to a site at some later date. Instead, your application should record long-term or important information in a database.
Sessions are not a convenience wrapper around cookies. Do not attempt to store long-term or limited-term client data in a session. Instead, your application should create and set its own cookies on the browser. Examples include an auto-login feature that allows a cookie to live for a long period, or an auto-logout feature that allows a cookie to expire after a short period of time. Here, you should not attempt to use HTTP sessions. Instead, you should write your own application-specific logic.
Use Serializable Attribute Values
When you use persistent sessions, all attribute value objects that you add to the session must implement java.io.Serializable. For more details on writing serializable classes, refer to the online java tutorial about serializable objects. If you add your own serializable classes to a persistent session, make sure that each instance variable of your class is also serializable. Otherwise, you can declare it as transient, and WebLogic Server does not attempt to save that variable to persistent storage. One common example of an instance variable that must be made transient is the HttpSession object. (See the notes on using serialized objects in sessions in the section Making Sessions Persistent .)
Configuring Session Persistence
For details about setting up persistent sessions, see "Configuring session persistence".
A cookie is a piece of information that the server asks the client browser to save locally on the user's disk. Each time the browser visits the same server, it sends all cookies relevant to that server with the HTTP request. Cookies are useful for identifying clients as they return to the server.
Each cookie has a name and a value. A browser that supports cookies generally allows each server domain to store up to 20 cookies with a size of up to 4k per cookie.
Setting Cookies in an HTTP servlet
To set a cookie on a browser, create the cookie, give it a value, and add it to the HttpServletResponse object that is the second parameter in your servlet's service method. For example:
Cookie myCookie = new Cookie("ChocolateChip", "100");
myCookie.setMaxAge(Integer.MAX_VALUE);
response.addCookie(myCookie);
This examples shows how to add a cookie called ChocolateChip with a value of 100 to the browser client when the response is sent. The expiration of the cookie is set to the largest possible value, which effectively makes the cookie last forever. Because cookies accept only string-type values, you should cast to and from the desired type that you want to store in the cookie. When using EJBs, a common practice is to use the home handle of an EJB instance for the cookie value and to store the user's details in the EJB for later reference.
Retrieving Cookies in an HTTP Servlet
You can retrieve a cookie object from the HttpServletRequest that is passed to your servlet as an argument to the service() method. The cookie itself is presented as a javax.servlet.http.Cookie object.
In your servlet code, you can retrieve all the cookies sent from the browser by calling the getCookies() method. For example:
Cookie[] cookies = request.getCookies();
This method returns an array of all cookies sent from the browser, or null if no cookies were sent by the browser. Your servlet must process the array in order to find the correct named cookie. You can get the name of a cookie using the Cookie.getName() method. It is possible to have more that one cookie with the same name, but different path attributes. If your servlets set multiple cookies with the same names, but different path attributes, you also need to compare the cookies using the Cookie.getPath() method. The following code illustrates how to access the details of a cookie sent from the browser. It assumes that all cookies sent to this server have unique names, and that you are looking for a cookie called ChocolateChip that may have been set previously in a browser client. For example:
Cookie[] cookies = request.getCookies();
boolean cookieFound = false;
for(int i=0; i < cookies.length; i++) {
thisCookie = cookies[i];
if (thisCookie.getName().equals("ChocolateChip")) {
cookieFound = true;
break;
}
}
if (cookieFound) {
// We found the cookie! Now get its value
int cookieOrder = String.parseInt(thisCookie.getValue());
}
For more details on cookies, see:
Using Cookies that Are Transmitted by Both HTTP and HTTPS
Because HTTP and HTTPS requests are sent to different ports, some browsers may not include the cookie sent in an HTTP request with a subsequent HTTPS request (or vice-versa). This may cause new sessions to be created when servlet requests alternate between HTTP and HTTPS. To ensure that all cookies set by a specific domain are sent to the server every time a request in a session is made, set the CookieDomain attribute to the name of the domain. Set the CookieDomain attribute with the <session-descriptor> element of the WebLogic-specific deployment descriptor (weblogic.xml) for the Web Application that contains your servlet. For example:
<session-descriptor>
<session-param>
<param-name>CookieDomain</param-name>
<param-value>mydomain.com</param-value>
</session-param>
</session-descriptor>
The CookieDomain attribute instructs the browser to include the proper cookie(s) for all requests to hosts in the domain specified by mydomain.com. For more information about this property or configuring session cookies, see "Setting Up Session Management.
Application Security and Cookies
Using cookies that enable automatic account access on a machine is convenient, but can be undesirable from a security perspective. When designing an application that uses cookies, follow these guidelines:
Automatically login from this computer?
Using WebLogic Services from an HTTP Servlet
When you write an HTTP servlet, you have access to many of the rich features of WebLogic Server, such as JNDI, EJB, JDBC, and JMS.
The following documents provide additional information about these features:
WebLogic Server supports the use of Java Database Connectivity (JDBC) from server-side Java classes, including servlets. JDBC allows you to execute SQL queries from a Java class and to process the results of those queries. For more information on JDBC and WebLogic Server, see Using WebLogic JDBC.
There three ways you can use JDBC in servlets, which are discussed in detail in the following sections:
Connecting to a Database Using a JDBC Connection Pool
A connection pool is a named group of identical JDBC connections to a database that are created when the connection pool is registered, usually when starting WebLogic Server. Your servlets "borrow" a connection from the pool, use it, and then return it to the pool by closing it. This process is far more efficient than creating a new connection for every client each time the client needs to access the database. Another advantage is that you do not need to include details about the database in your servlet code.
When connecting to a JDBC connection pool, use one of the following multitier JDBC drivers:
Using a Connection Pool in a Servlet
The following example demonstrates how to use a database connection pool from a servlet.
Driver myDriver = (Driver)
Class.forName("weblogic.jdbc.pool.Driver").newInstance();
You can identify the pool in either of two ways:
Properties props = new Properties();
props.put("connectionPoolID", "myConnectionPool");
Connection conn =
myDriver.connect("jdbc:weblogic:pool", props);
Connection conn =
myDriver.connect("jdbc:weblogic:pool:myConnectionPool", null);
Note that the Driver.connect() method is used in these examples instead of the DriverManger.getConnection() method. Although you may use DriverManger.getConnection() to obtain a database connection, we recommend that you use Driver.connect() because this method is not synchronized and provides better performance.
Note that the Connection returned by connect() is an instance of weblogic.jdbc.pool.Connection.
conn.close();
Connecting to a Database Using a DataSource Object
A DataSource is a server-side object that references a connection pool. The connection pool registration defines the JDBC driver, database, login, and other parameters associated with a database connection. DataSource objects and connection pools are created using the Administration Console. Using a DataSource object is recommended when creating J2EE-compliant applications.
Using a DataSource in a Servlet
Context ctx = null;
// Get a context for the JNDI look up
ctx = new InitialContext(ht);
// Look up the DataSource object
javax.sql.DataSource ds
= (javax.sql.DataSource) ctx.lookup ("myDataSource");
java.sql.Connection conn = ds.getConnection();
Statement stmt = conn.createStatement();
stmt.execute("select * from emp");
. . .
Connecting Directly to a Database Using a JDBC Driver
Connecting directly to a database is the least efficient way of making a database connection because a new database connection must be established for each request. You can use any JDBC driver to connect to your database. BEA provides JDBC drivers for Oracle, Microsoft SQL Server, and Informix. For more information, see Programming WebLogic JDBC
Threading Issues in HTTP Servlets
When you design a servlet, you should consider how the servlet is invoked by WebLogic Server under high load. It is inevitable that more than one client will hit your servlet simultaneously. Therefore, write your servlet code to guard against sharing violations on shared resources or instance variables. The following tips can help you to design around this issue.
An instance of a class that implements the SingleThreadModel is guaranteed not to be invoked by multiple threads simultaneously. Multiple instances of a SingleThreadModel servlet are used to service simultaneous requests, each running in a single thread.
To use the SingleThreadModel efficiently, WebLogic Server creates a pool of servlet instances for each servlet that implements SingleThreadModel. WebLogic Server creates the pool of servlet instances when the first request is made to the servlet and increments the number of servlet instances in the pool as needed.
The attribute "SingleThreadedModelPoolSize", set using the WebLogic Server Administration Console, specifies the initial number of servlet instances that are created when the servlet is first requested. Set this attribute to the average number of concurrent requests that you expect your SingleThreadModel servlets to handle.
When designing your servlet, consider how you use shared resources outside of the servlet class such as file and database access. Because there are multiple instances of servlets that are identical, and may use exactly the same resources, there are still synchronization and sharing issues that must be resolved, even if you do implement the SingleThreadModel.
We recommend that shared-resource issues be handled on an individual servlet basis. Consider the following guidelines:
Dispatching Requests to Another Resource
This section provides an overview of commonly used methods for dispatching requests.
A servlet can pass on a request to another resource, such as a servlet, JSP, or HTML page. This process is referred to as request dispatching. When you dispatch requests, you use either the include() or forward() method of the RequestDispatcher interface. There are limitations regarding when output can be written to the response object using the forward() or include() methods. These limitations are also discussed in this section.
For a complete discussion of request dispatching, see section 8.1 of the Servlet 2.2 specification (see http://java.sun.com/products/
servlet/download.html#specs) from Sun Microsystems.
By using the RequestDispatcher, you can avoid sending an HTTP-redirect response back to the client. The RequestDispatcher passes the HTTP request to the requested resource.
To dispatch a request to a particular resource:
ServletContext sc = getServletConfig().getServletContext();
path should be relative to the root of the Web Application.
Replace name with the name assigned to the servlet in a Web Application deployment descriptor with the <servlet-name> element. For details, see "Servlet element"
This method returns a RequestDispatcher object and is similar to the ServletContext.getRequestDispatcher(String path) method except that it allows the path specified to be relative to the current servlet. If the path begins with a / character it is interpreted to be relative to the Web Application.
You can obtain a RequestDispatcher for any HTTP resource within a Web Application, including HTTP Servlets, JSP pages, or plain HTML pages by requesting the appropriate URL for the resource in the getRequestDispatcher() method. Use the returned RequestDispatcher object to forward the request to another servlet.
Once you have the correct RequestDispatcher, your servlet forwards a request using the RequestDispatcher.forward() method, passing HTTPServletRequest and HTTPServletResponse as arguments. If you call this method when output has already been sent to the client an IllegalStateException is thrown. If the response buffer contains pending output that has not been committed, the buffer is reset.
The servlet must not attempt to write any previous output to the response. If the servlet retrieves the ServletOutputStream or the PrintWriter for the response before forwarding the request, an IllegalStateException is thrown.
All other output from the original servlet is ignored after the request has been forwarded.
Your servlet can include the output from another resource by using the RequestDispatcher.include() method, and passing HTTPServletRequest and HTTPServletResponse as arguments. When you include output from another resource, the included resource has access to the request object.
The included resource can write data back to the ServletOutputStream or Writer objects of the response object and then can either add data to the response buffer or call the flush() method on the response object. Any attempt to set the response status code or to set any HTTP header information from the included servlet response is ignored.
In effect, you can use the include() method to mimic a "server-side-include" of another HTTP resource from your servlet code.
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|