Spring-web Web Module Analysis of Spring source analysis

0 overview

Spring-web's web module is a higher level of abstraction that encapsulates the basic components needed for rapid development of Spring-web. The structure is as follows:

1. Initialize the initializer section

1.1 Servlet3.0 's Servletcontainerinitializer is used to support the code-based servlet container configuration, which uses the spring Webapplicationinitializer SPI instead (or mixed Use the traditional Web. XML-based approach.

1.2 Springservletcontainerinitializer triggers the Onstartup method to load and initialize the class when it is started with a SERVLT 3.0 compliant container. The container starts with the assumption that the jar of the Spring Web module is already stored in classpath. Use Serviceloader's Loader method when loading to find meta-inf/services/under the Spring-web module Javax.servlet.servletContainerInitializer The service provider configuration file.

The 1.3 Httprequesthandler interface is approximately equal to HttpServlet, and all methods focus on the HandleRequest method. The implementation classes are as follows:

2. Accept part of the request

Do you remember our HTTP request message?

get/tutorials/other/top-20-mysql-best-practices/http/1.1 (Request line) host:net.tutsplus.comuser-agent:mozilla/ 5.0 (Windows; U Windows NT 6.1; En-us; rv:1.9.1.5) gecko/20091102 firefox/3.5.5 (. NET CLR 3.5.30729)accept:text/html,application/xhtml+xml,application /xml;q=0.9,*/*;q=0.8Accept-language:en-us,en;q=0.5accept-encoding:gzip,deflateaccept-charset:iso-8859-1, Utf-8;q=0.7,*;q=0.7keep-alive:300connection:keep-alivecookie:phpsessid=r2t5uvjq435r4q7ib3vtdjq120pragma: No-cachecache-control:no-cache

Let's see how rfc-2616 is defined.

The Accept request-header field can be used to specify certain media types which is acceptable for the response. Accept headers can used to indicate, the request was specifically limited to a small set of desired types, as in the Case of a request for an in-line image.

       Accept         = "Accept" ":"                        # (Media-range [Accept-params])

       Media-range    = ("*/*"                        | (Type "/" "*")                        | (Type "/" subtype)                        ) * (";" parameter)       accept-params  = ";" "Q" "=" Qvalue * (accept-extension)       accept-extension = ";" token ["=" (token | quoted-string)]

The asterisk "*" character is used to group media types into ranges, with ' */* ' indicating all media types and ' type/* ' in Dicating all subtypes of this type. The media-range may include media type parameters that is applicable to that range.

Each media-range is followed by one or more accept-params, beginning with the ' Q ' parameter for indicating a relative Quality factor. The first "q" parameter (if any) separates the Media-range parameter (s) from the Accept-params. Quality factors allow the user or user agent to indicate the relative degree of preference for that Media-range, using the Qvalue scale from 0 through 1 (section 3.9). The default value is Q=1.

      Note:use of the "Q" parameter name to separate media type      parameters from Accept extension parameters are due to Histo Rical      Practice. Although this prevents any media type parameter named      "Q" from being used with a media range, such an event is believe D to is      unlikely given the lack of any ' Q ' parameters in the IANA      media type registry and the rare usage of any me Dia type      parameters in Accept. Future media types is discouraged from      registering any parameter named "Q".

The example

       accept:audio/*; q=0.2, Audio/basic

should be interpreted as "I prefer audio/basic, but send me any audio type if it's the best available after an 80% mark-d Own in quality. "

If No Accept header field is present, then it's assumed, the client accepts all media types. If the Accept header field is present, and if the server cannot send a response which are acceptable according to the Combin Ed Accept field value, then the server should send a 406 (not acceptable) response.

A More elaborate example is

       Accept:text/plain; q=0.5, text/html,               text/x-dvi q=0.8, text/x-c

Verbally, this would is interpreted as "text/html and TEXT/X-C is the preferred media types, but if they does not exist, th En send the TEXT/X-DVI entity, and if that does not exist, send the Text/plain entity.

Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies to a given type, the most specific reference have precedence. For example,

       accept:text/*, text/html, text/html;level=1, */*

The following precedence:

       1) text/html;level=1       2) text/html       3) text/*       4) */*

The media type quality factor associated with a given type are determined by finding the media range with the highest prece Dence which matches that type. For example,

       accept:text/*;q=0.3, text/html;q=0.7, text/html;level=1,               text/html;level=2;q=0.4, */*;q=0.5

Would cause the following values to be associated:

       Text/html;level=1         = 1       text/html                 = 0.7       Text/plain                = 0.3

       Image/jpeg                = 0.5       text/html;level=2         = 0.4       text/html;level=3         = 0.7

      NOTE:A User agent might is provided with A default set of quality      values for certain media ranges. However, unless the user agent is      a closed system which cannot interact with other rendering agents, this      default Set ought to being configurable by the user.

Let's look at the overall structure of the Accept section:

Is it a little sudden or a little bit clear? Yes, the Accept section is responsible for negotiating the HTTP content of the MIME type to meet the requirements.

3. Data-bound Bing section

Here, the binding means to set the data on different types of HTTP requests to specific objects on object such as JavaBean, and support multipart bindings. The structure is as follows:

Bindings are supported in two ways: programmatic and annotated.

The implementation of annotations is done by Handlermethodinvoker trigger handlermethodresolver.

4.web Client Part

5. Contextual Context Section

A ApplicationContext interface that contains a series of web apps and Contextloaderlistener to start the root Web ApplicationContext.

Various applicationcontext hierarchies such as: (Image source Network, the specific link has not been found, please forgive)

Spring-context related content Please refer to this aspect of the source parsing, here will not repeat.

6. Filter filters

Spring also encapsulates and implements the filter in some degree, with the following structure:

7. JSF section

Supports the integration of the JSF Web layer with spring's service and supports the El parsing of JSF, and the spring service layer resides in the spring root webapplicationcontext.

8. Method section

Provides the method handling classes used by spring MVC.

9. Multipart section

A multipart solution file uploads the schema framework, Multipartresolver inherits the implementation of Apache Commons FileUpload.

Util part

Provides a common tool class.

Summary

The Spring-web Web module is the basis for the spring framework to handle Web requests, and the Spring-web HTTP module (http://www.cnblogs.com/davidwang456/p/4421495.html) The request requests and response responses of the client end/server end of the encapsulated HTTP protocol are converted, such as json,rss,xml, etc. spring-web Remoting module includes Jaxws, Caucho, Httpinvoker and other remote calls; the Spring-web Web module further encapsulates Web applications based on the above-mentioned modules, providing the ability to develop the web quickly.

Note: The above content for my reading the source of experience and insight, not necessarily correct, please quote carefully, such as found the wrong place, hope to give me feedback, I will revise as soon as possible.

Spring-web Web Module Analysis of Spring source analysis