| Programmer's Guide |
|
|
Servlet Programming Techniques |
|
| Programmer's Guide |
|
|
Servlet Programming Techniques |
|
The way you map your web application components to request URLs defines the entry point for your users. How you set up mappings affects what the users see in their browser's address bar and how JRun handles requests. This section describes the implicit JRun mappings and explains how to establish your own mappings to web applications and web components, such as servlets and JSPs.
When establishing your web application mappings, you must be aware of how the application is assembled and deployed. You should package modules in the appropriate archive files for deployment in a production environment. For more information, see JRun Assembly and Deployment Guide.
To get started quickly, use the information in the following table:
A client invokes a servlet by requesting a URL, as it would any web resource. A URL is composed of a protocol, host, port (optional), and request uniform resource indicator (URI), as the following figure shows:
To see a sample servlet that decomposes the request URL, start the samples JRun server and open a browser to http://localhost:8200/techniques.
JRun 4.0 fully implements the web application architecture described in the Servlet API Version 2.3 specification. This implementation includes mapping requests to servlets in a manner compliant with the specification.
Application and servlet mappings use different parts of the request URI, dividing it into the several components to determine the resource to invoke. The following table describes these components:
JRun uses the following types of mappings when determining what file to serve up in response to a request:
/servlet) or suffix (such as *.jsp).Each web application running in a JRun server can define one application mapping and multiple servlet mappings. To use web applications in an optimal manner, you must understand how JRun uses application mappings and servlet mappings to handle requests for HTML files, JSPs, and servlets.
The following table lists the mappings that the JRun configuration file define:
An application mapping relates a context path to the name and directory path of a web application. You maintain these mappings through the JRun Management Console (JMC). JRun maintains application mappings in the META-INF/application.xml file.
This mapping does not have to correspond to the physical location of the web application in the file system of the web server. For example, you can have a web application located on your server in the directory c:/apps/myapp where myapp is the document root directory for the web application. The directory structure of the web application is under myapp.
You can create an application URL mapping for /myapp so that the web application responds to a URL in the form http://www.mycomp.com/myapp. After you set up this mapping, all URLs containing the /myapp context path are mapped to the web application.
The application assembler defines the context roots of all web modules. The application assembler ensures that the context roots do not overlap with any other modules' context roots in the application.
When a request comes in, JRun attempts to map the request to the longest mapping available. This means that if a request URI includes /foo/bar, JRun first tries to find a mapping for /foo/bar. Failing that, JRun then tries to find a mapping for /foo. If JRun still does not find a match, then JRun maps the request to /. If a servlet is mapped to /, then JRun assigns foo/bar as the servlet path information.
You can map only one web module in a JRun server to the root, and all web modules must have unique mappings. Any requests that come in to the JRun server that do not have explicit mappings are sent to the web application that is mapped to the root.
If your web application does not have an application.xml file, then you should package the application as an EAR file and define this file. For more information, see JRun Assembly and Deployment Guide.
If you want one servlet to catch all requests to the root of your web application, you must set the URL pattern that this servlet matches to /. This is a common task when you are implementing a design pattern such as Model-View-Controller, which requires that one servlet act as the controller or dispatcher.
For example, the techniques-ear file contains the web module techniques-war. This module's context root is /techniques. If JRun receives a request such as http://www.yourhost.com/techniques, the request is mapped to the techniques-war module. JRun then checks the techniques module's web.xml file for servlet mappings.
If the application assembler does not supply a root (/) mapping for a context root and a request does not match any other mappings, JRun returns the index file from the web server's root directory to the user who requests it. If there is no index file available, then JRun returns a directory listing. If directory listings are turned off, then JRun returns an error to the user.
There are multiple ways to define the context roots of your web applications, depending on what type of application you are deploying. This section describes how you define the context root for EAR files and WAR files.
If you deploy an EAR file, you define the context root for each web module in the /META-INF/application.xml file, using the following syntax:
<module><web>
��<web-uri>module-name</web-uri> ��<context-root>mapping</context-root> </web></module>
The following example maps the techniques-war web module to /techniques:
<module><web>
��<web-uri>techniques-war</web-uri> ��<context-root>/techniques</context-root> </web></module>
You must set the context-root element in the application.xml file for each web module. If you do not specify a context root, the web module will not be accessible through the enterprise application.
If you hot deploy a web module as a WAR file, you can define the context root in the jrun-web.xml file or let JRun substitute one for you.
JRun determines the context root in the following order:
The following table describes several techniques for mapping servlets to request URIs:
A servlet mapping associates a servlet with a URL pattern, which can be a prefix (such as /MyServlet) or a suffix (such as *.jsp). When a request URI has a servlet path that matches a specified URL pattern, JRun invokes the associated servlet. If you do not explicitly define a servlet, you can use the /servlet implicit mapping to request a servlet that you store in the WEB-INF/classes directory. For more information, see "Implicit servlet mappings".
The following lines from the default-web.xml file map the *.jsp pattern to the JSPServlet and the AxisServlet to /services:
<servlet-mapping>
��<servlet-name>AxisServlet</servlet-name> ��<url-pattern>/services</url-pattern> </servlet-mapping> <servlet-mapping> ��<servlet-name>JSPServlet</servlet-name> ��<url-pattern>*.jsp</url-pattern> </servlet-mapping>
When the web server receives a request for a page or servlet, JRun first locates the web application by matching the request URI's context path with the application URL mapping defined to JRun. After the web application is located, JRun locates the specified resource using that web application's servlet mappings. If no application mapping matches the context path, JRun attempts to locate the resource using servlet mappings in the default application for that web server.
You define and manage explicit servlet mappings in the web.xml file. To maximize security, your production applications should define explicit servlet mappings for each servlet in your web application.
The url-pattern in servlet mappings do not require a leading forward slash.
In addition to the explicit servlet mappings in the web.xml file, JRun maintains a set of implicit servlet mappings in the default-web.xml file for each JRun server. These mappings are shared by all applications in the JRun server. The following table describes these mappings:
You can override an implicit servlet mapping for a web application by defining a new mapping in the web application's web.xml file, or you can change the mapping for all applications in the default-web.xml file. For example, you can change the default servlet mapping for the ServletInvoker servlet by associating /servlet with LoginServlet or 404Servlet.
JRun includes an implicit servlet mapping that associates /servlet with the ServletInvoker servlet, which causes a request URI containing a servlet path of /servlet to be handled by the ServletInvoker servlet. The ServletInvoker servlet provides a general-purpose invocation mechanism for servlets that did not explicitly define in the web.xml or default-web.xml files.
The following lines show the ServletInvoker mapping in the default-web.xml file:
<servlet-mapping>
��<servlet-name>ServletInvoker</servlet-name> ��<url-pattern>/servlet/</url-pattern> </servlet-mapping>
This mapping can be useful during the development and testing phase. It saves you from defining servlet mappings explicitly. The ServletInvoker servlet automatically creates a temporary servlet registration using the class name.
For security and performance reasons, you should define explicit mappings for all of your servlets and override the default ServletInvoker mapping in your production systems. In a production application, you might associate the /servlet mapping with a customized servlet that always returns an error; for example:
/servlet = 404servlet
JRun uses the ServletInvoker servlet in the following way:
/app1/servlet/SnoopServlet).
/app1).
/servlet).
/SnoopServlet).
ServletContext.getNamedDispatcher(servletname).JRun first looks in the web application's web.xml and default-web.xml files to determine if the servlet has been defined. If no match is found, JRun looks for the servlet in the directories listed in the application's classpath and creates an instance using the servlet's class name.
JRun supports welcome files that are specified in web.xml according to the servlet specification. You define welcome files in the web.xml file, as the following example shows:
<welcome-file-list>
��<welcome-file>index.html</welcome-file> ��<welcome-file>welcome.html</welcome-file> </welcome-file-list>
The welcome-file is a partial URI (with no leading or trailing slash). When a client makes a request to a directory, JRun appends the welcome-file entries to the requested directory and forwards the request if a match is found. If a matching welcome-file is not found, or cannot be served, the next welcome-file in the list is tried; if no welcome-file entries are found, then JRun returns a directory listing to the client. If directory listings are turned off, JRun returns an error.
To turn off the directory browsing, see JRun Administrator's Guide.
JRun divides the URI portion of a URL into context path, servlet path, and extra path information depending on the application and servlet mappings.
For example, assuming an application mapping for /hrapp in the application.xml file, a servlet mapping for /NewEmpServlet in the web.xml file, and a request URI of /hrapp/NewEmpServlet/login?empid=61355, JRun determines the following:
| URI component |
Definition |
|---|---|
/hrapp |
Context path |
| / NewAppServlet |
Servlet path |
/login |
Path information |
empid=61355 |
Query string parameter |
If there is no application mapping, the same URI results in the following:
| URL component |
Definition |
|---|---|
| (empty) |
Context path |
/hrapp/NewEmpServlet |
Servlet path |
| /login |
Path information |
| empid=6139 |
Query string parameter |
Note: Except for URL encoding differences between the request URI and the path parts, the following statement is always true:RequestURI = contextpath + servletpath + pathinfo
From within servlets, you can access context and path information. The following example shows using these methods to get ServletContext information from the request:
...
ServletContext context = getServletContext();
out.println("Context Path: " + req.getContextPath());
out.println("<BR>Servlet Path: " + req.getServletPath());
out.println("<BR>Path Info: " + req.getPathInfo());
out.println("<BR>Real Path: " + context.getRealPath(req.getServletPath()));
...
This example also uses the Referer HTTP header to build a Back link, as the following example shows:
String referer = req.getHeader("Referer");
out.println("<BR><A HREF=\"" + referer + "\">Back</A>");
To see a sample servlet, start the samples JRun server and open a browser to http://localhost:8200/techniques.
|
|
Send me an e-mail when comments are added to this page | Comment Report
Current page: http://livedocs.adobe.com/jrun/4/Programmers_Guide/techniques_servlet6.htm