Tenth Chapter WEB Application (JAVATM Servlet specification 3.1)

Web Apps

A Web application is a collection of servlets,html pages,classes and other resources that make up a complete application on a Web server. Web apps can be bundled and run in different containers from different vendors.

10.1 Web Apps in a Web server?

Web applications in Web servers are rooted in a specific path. For example, the catalog app might be anchored to Http://www.mycorp.com/catalog. All requests that begin with this prefix will be routed to the ServletContext representing the catalog application. The servlet container can create auto-generated rules for Web apps. For example, ~user/mapping can be used to map a/home/user/public_html-based Web application. By default, an instance of a Web app must be running on a VM at any one time. This behavior can be overridden if the app marks it as "distributable (distributed)" by its deployment descriptor. Apps labeled as distributed must adhere to stricter rules than normal web apps. These rules are set up in this specification.

10.2 The relationship with ServletContext ?

The Servelt container must enforce a one by one correspondence between the Web App and ServletContext. The ServletContext object is provided to the servlet for its application view.

10.3 Elements of a web App

Web apps can consist of the following items:

? Servlets?

? JSP Pages1?

? Tool class?

? static documents (HTML, pictures, sounds, etc.)?

? client Java Applets,beans, and class?

? Descriptive meta-information that binds the above elements together

10.4 Level of deployment?

For deployment and packaging purposes, this specification defines a hierarchy that can exist in an open file system, archive file, or other format. It is recommended that the Servlet container support this structure as a run-time representation, but not necessary.

10.5 directory Structure ?

WEB applications exist as a structured hierarchical directory. The root of this hierarchy is the document root of the file in the application. For example, an app in the Web container with/catalog as the context path, index.html in the Web application hierarchy root and/meta-inf/resources directory under the Web-inf/lib jar file index.html are satisfied with the request from/catalog/index.html. If index.html exists both in the root context and in the jar file/meta-inf/resources in the application Web-inf/lib directory, you must use the index.html in the context of the root. The rules that match the URLs to the context path are given in Chapter 12, "Mapping requests to Servlets". Because the context path of the app determines the URL namespace of the Web app content, the Web container must deny that the Web app defines a context path that might cause potential conflicts in this URL namespace. For example, if you try to deploy another Web application with the same context path, a conflict will occur. Because request matching resources are case-sensitive, the determination of potential conflicts must also be case-sensitive.

There is a special directory named "web-inf" in the application hierarchy. This directory contains all of the things that are relevant to your app that are not in the app root document. Most web-inf nodes are not part of the application public document tree. In addition to packaging static resources and JSPs meta-inf/resources in JAR files located in Web-inf/lib, other files contained in the Web-inf directory cannot be supplied to the client by the container. However, the contents of the Web-inf directory are visible to the servlet code that calls ServletContext's GetResource and getResourceAsStream methods, and can be exposed using a requestdispatcher call. Therefore, if the app developer needs to access the app's special configuration information from the servlet code that he doesn't want to expose directly to the Web client, you can put it in that directory. Because the request matching resource mapping uses case-sensitive methods, such as client requests, '/web-inf/foo ', '/web-inf/foo ', the content of the WEB app that is located under/web-inf should not be returned, including any form of directory listing.

Contents of the Web-inf directory:

? /web-inf/web.xml deployment Descriptor.

? Directory of/web-inf/classes/servlet and tool classes. The classes in this directory must be available to the application's class loader.

? /web-inf/lib/*.jar the Java archive file area. These files include Servlets,benas that are packaged in jar files, static resources and JSPs, and other tool classes that are useful for Web applications. The Web application class loader must be able to load classes from any of these archive files. The Web app must first load the class from the Web-inf/classes directory and then load it from the library jars in the Web-inf/lib directory. In addition, any request from the client to access resources in the web-inf/directory must return a sc_not_found (404) response, in addition to the case where the static resource is packaged into the jar file.

10.5.1 application Directory Structure example

The following is a list of all the files in a sample web app:

/index.html

/howto.jsp

/feedback.jsp

/images/banner.gif

/images/jumping.gif

/web-inf/web.xml

/web-inf/lib/jspbean.jar

/web-inf/lib/catalog.jar!/meta-inf/resources/catalog/moreoffers/books.html

/web-inf/classes/com/mycorp/servlets/myservlet.class

/web-inf/classes/com/mycorp/util/myutils.class

10.6 WEB Application Archive file

Using standard Java archiving tools, Web apps can be packaged and checked into a Web archive format (WAR) file. For example, an app for "issue tracking (tracking problem)" Can be published in an archive named Issuetrack.war.

When packaged in this format, a meta-inf directory containing useful information about the Java Archive tool is generated. This directory cannot be directly supplied as content by the container as a response to a Web client request, although its content is visible to the servlet code that calls ServletContext's GetResource and getResourceAsStream. In addition, any request to access resources under the Meta-inf directory must return a sc_not_found (404) Response.

10.7 Web App Deployment descriptor

The Web application descriptor (see Chapter 14: Deployment descriptor) includes the following configuration types and deployment information:

? ServletContext initialization parameters?

? Session configuration?

? servlet/jsp definition?

? servlet/jsp mapping?

? MIME Type mapping?

? Welcome File list?

? Error Pages

? Security?

10.7.1 extended dependency?

When a large number of applications use the same code or resources, they are usually installed as library files in the container. These files are often generic and standard APIs that can be used without sacrificing portability. Files that are used only by one or a few apps will be accessed as part of the Web App. Containers must provide a directory for these libraries. Files stored in this directory must be available across Web applications. The location of this directory is specified by the container. The class loader that the servlet container uses to load these library files must be the same as the ClassLoader for all Web apps in the same JVM. This ClassLoader instance must be in the parent loader chain of the Web App ClassLoader. To maintain portability, the app developer needs to know what extensions are installed on the Web container, and the container needs to know which libraries the servlets in the WAR depends on. Application developers who rely on these extensions must provide a meta-inf/manifest in the WAR file. The MF entry lists all the extensions required by the war. The format of this manifest entry must follow the standard JAR manifest format. In a Web application deployment, the Web container must make the correct version of the extension available to applications that adhere to the "mechanism definition rules of the optional package version recognition". The WEB container must be able to identify the dependencies declared in the manifest entry in any JAR library in the Web-inf/lib directory in the WAR package. If the Web container does not meet the dependency declared in this way, it should use a meaningful error message to reject the application.

10.7.2 Web application class loader?

The ClassLoader used by the container to load the servlet in the war must allow the developer to use GetResource to load any of the resources contained in the JAR library [following the normal Java SE lexical] war. In the Java EE License Agreement description, the servlet container is not part of the Java EE product and should not be allowed to overwrite Java SE platform classes, such as classes in Java.* and javax.*, where Java SE is not allowed to be modified. The container should not allow the application to overwrite or access the container's implementation class. The recommended class loader implementation is that loading classes and resources packaged into the war takes precedence over classes and resources in the jar library that are within the scope of the loading container. The implementation must ensure that each Web application that is deployed in the container calls Thread.currentThread.getContextClassLoader () must return a ClassLoader instance that implements the conventions specified in this section. In addition, the ClassLoader instance of each deployed Web app must be a separate instance. Before any callbacks (including listener callbacks) are allowed to enter the Web application, the container must set the thread context ClassLoader (?) as described above. ), once the callback returns, set it back to the original ClassLoader.

10.8 Replacing Web Apps

The server should be able to replace the app with the new version without restarting the container. When an application is replaced, the container should provide a robust method of preserving session data in the app.

10.9 Error Handling

10.9.1 Request Properties

When an error occurs, the Web app must be able to specify additional resources in the app that provide the body of the error response content. The specification of these resources is set in the deployment descriptor.

If the location of the error is handled (the site of the error handler) is a servlet or a JSP page:

? The initial unpackaged request and response objects created by the container are passed to the servlet or JSP page.

? The request path and property are set to: The Requestdispatcher.forward for the wrong resource has been executed. （？ ）

? The Request properties in table 10-1 must be set:

Table 10-1 Request properties and their type

Request Properties type

Javax.servlet.error.status_code Java.lang.Integer

Javax.servlet.error.exception_type Java.lang.Class

Javax.servlet.error.message java.lang.String

Javax.servlet.error.exception java.lang.Throwable

Javax.servlet.error.request_uri java.lang.String

Javax.servlet.error.servlet_name java.lang.String

These properties allow the servlet to generate specialized content based on status codes, exception types, error messages, propagation of exception objects, error generation in which the servlet handles the request URI (determined by the Getrequesturi call), and the logical name of the servlet generated by the error.

With the introduction of exception objects in the attribute list in version 2.3 of this specification, exception types and exception information properties become redundant. They are reserved for backward compatibility with earlier versions of the API.

10.9.2 error page

To allow developers to customize the appearance (rendering) of the content of the Web client when the servlet produces an error, the deployment descriptor defines a series of error page descriptions. This syntax allows the container to return the configuration of a resource when the servlet or filter calls Response Senderror for a particular status code or if the servlet produces an exception or an error that propagates to the container.

If the response Senderror method is called, the container queries the Web app for the error page declaration, uses the status code syntax, and tries to match. If there is a match, the container returns the resource indicated by this location (<location>) entry.

The container or filter may throw the following exception during the processing of the request:

? runtime exceptions or errors run-time exception or error?

? Servletexceptions or its subclasses?

? Ioexceptions or or its subclasses?

Web apps can use the Exception-type element to declare error pages. In this case, the container matches the exception type by comparing the thrown exception and defining the list with the error page (<error-page>) defined by the Exception-type element. The match causes the container to return the resource indicated in the location (<location>) entry. The closest match in the class inheritance hierarchy wins.

If you use class hierarchy to match a error-page declaration that does not contain an appropriate exception-type, and the exception that is thrown is servletexception or its subclass, the container uses Servletexception.getrootcause The method presents the wrapped exception. Using the wrapped exception (wrapped in servletexception or its subclasses), pass in the error page declaration again and try to match the error page declaration again.

The class name Exception-type in the error page (<error-page>) declaration that uses the Exception-type element in the deployment descriptor must be unique. Similarly, a error-page declaration using the Status-code element must be unique in the deployment descriptor status code.

If a error-page element in the deployment descriptor does not contain a exception-type or error-code element, this error page is the default error page.

The error page mechanism does not intervene when an error occurs using the RequestDispatcher or Filter.dofilter method call. In this way, the filter or servlet will have the opportunity to use RequestDispatcher to process the resulting error. (This part doesn't know right)

If the error generated by the servlet is not handled by the error page mechanism described above, the container must ensure that a response with status code 500 is sent.

The default servlet and container will use the Senderror method to send 4XX and 5XX State responses in order to invoke the error mechanism. The default servlet and container will use the Senderror method to send the 2XX and 3XX state responses without invoking the error mechanism.

If the application (program) uses the asynchronous operation described in section 2.3.3.3, the 2-10 page of "Asynchronous Processing", the application is responsible for handling errors on threads created by the application. The container "can" handle errors generated by threads created through Asynccontext.start. See the section on page 2-16 for errors generated during asynccontext.dispatch processing, "the container must capture and handle any errors and exceptions that may occur during the execution of the dispatch method as follows".

10.9.3 Error Filter

The error page mechanism acts on the original unpackaged/unfiltered request and response object produced by the container. This mechanism is described in section 6.2.5, "Filters and RequestDispatcher", which can be used to specify the filter of the application before the error response is generated.

10.10 Welcome Documents

Web App developers can define a [partial URI] sequence table called a welcome file in the Web App deployment descriptor. The deployment descriptor syntax for this list is described in the Web App deployment descriptor schema.

The purpose of this mechanism is to allow the developer to specify a part of the URIs sequence table for the container, which is appended to these URIs when there is a request for a URI that corresponds to a directory entry in the WAR that does not map to the Web component. This type of request is known as a valid partial request (a valid partial requests).

The benefit of this usage is clear from the following example: You can define a ' index.html ' welcome file so that a request like URL host:port/webapp/directory/, ' directory ' is a WAR in which one does not map to The entry for the servlet or JSP page, returned to the client is ' host:port/webapp/directory/index.html '.

If the Web container receives a valid partial request, the Web container must check the welcome file that is defined in the deployment descriptor. The Welcome file list is an ordered partial URL list without leading and trailing/. The WEB server must add the welcome file to the partial request individually, in the order specified in the deployment descriptor, and check if there is a static resource mapped to the requested URI in the war. If no match is found, the WEB server must re-add each welcome file to a partial request in the order specified in the deployment descriptor and check if there is a servlet mapped to the request URI. The Web container must send the request to the first resource that matches in the war. The container can use the mechanism specified by the Forward,redirect or container to send requests to the welcome resource, no different from the direct request.

In the way described above, if there is no matching welcome file, the container can handle the request in the appropriate way it can find it. For some configurations that might mean returning a directory listing, other configurations might return a 404 response.

Consider a WEB application such as:

The following welcome file is listed in the deployment descriptor.

<welcome-file-list>

<welcome-file>index.html</welcome-file>

<welcome-file>default.jsp</welcome-file>

</welcome-file-list>

The static files in the war are as follows:

/foo/index.html

/foo/default.jsp

/foo/orderform.html

/foo/home.gif

/catalog/default.jsp

/catalog/products/shop.jsp

/catalog/products/register.jsp

? Request Uri/foo will be redirected to uri/foo/.

? Request uri/foo/will return/foo/index.html.?

? Request Uri/catalog will be redirected to URI?/catalog/.

? Request uri/catalog/will return/catalog/default.jsp.?

? Requesting uri/catalog/index.html will result in 404 Not FOUND.

? Request Uri/catalog/products will be redirected to URI?/catalog/products/.

? The request to uri/catalog/products/will be passed to the "default" servlet, if any. If there is no "default" servlet mapping, this request may cause 404 Not found, which may result in a directory listing that includes shop.jsp and register.jsp, or other behavior that may result in container definition. See section 12.2, "default" servlet definition in "mapping specification".

? All of the static content listed above can also be packaged into the jar file along with the contents of the jar file in the Meta-inf/resources directory. This JAR file can be included in the Web-inf/lib directory of your Web app.

10.11 Web Application Environment

The Servlet container is not part of the Java EE Technical Standard and is encouraged to implement, but does not have to be, in the 15.2.2 section, "Web Application Environment and Java EE specification", which describes the implementation of the application environment functionality. Containers should provide a warning if they (containers) do not implement the required functionality to support an environment where application dependencies are deployed.

10.12 Web application Deployment

When a web app is deployed into a container, the Web app must follow the steps below before it starts processing the client's request:

? Instantiates an instance of each event identified by the <listener> element in the deployment descriptor listener.

? The Contextinitialized () method is called for each materialized listener instance that implements Servletcontextlistener.

? Instantiate an instance of each filter identified by the <filter> element in the deployment descriptor, and then invoke the Init () method of each filter instance.

? Servlet containing the <servlet> element identity of the <load-on-startup> element, in order from the Load-on-startup element value defined (by small to large), each servlet instantiates an instance, and invoke the Init () method for each servlet.

10.13 contains the Web. XML Deployment Descriptor

If your web app does not contain any servlet,filter or Listener components, or if you use annotations to declare the same (that is, you are using annotations), you do not need to include a. xml file. In other words, an app that includes only static files or JSP pages does not require a Web. xml to be introduced.

Tenth Chapter WEB Application (JAVATM Servlet specification 3.1)