First, the matching process of the servlet container to the url: When a request is sent to the servlet container, the container will first take the requested url minus the path of the current application context as the servlet mapping url, for example, I visit http://localhost /test/aaa.html , my application context is test, the container will remove http://localhost/test , and the remaining /aaa.html part will be used for servlet mapping matching. This mapping matching process is sequential, and when a servlet is successfully matched, the remaining servlets will not be ignored (the filter is different, which will be mentioned later).
The matching rules and order are as follows:
1. Exact path matching. Example: For example, the url-pattern of servletA is /test, and the url-pattern of servletB is /*. At this time, if the url I visit is http://localhost/test , the container will first match the exact path and find that /test is exactly matched by servletA, then call servletA and ignore other servlets.
2. The longest path matches. Example: The url-pattern of servletA is /test/*, and the url-pattern of servletB is /test/a/*. At this time, when accessing http://localhost/test/a , the container will select the servlet with the longest path. Match, which is servletB here.
3. Extension matching, if the last segment of the url contains an extension, the container will select the appropriate servlet according to the extension. Example: url-pattern of servletA: *.action
4. If none of the previous three rules find a servlet, the container will select the corresponding request resource according to the url. If the application defines a default servlet, the container will drop the request to the default servlet (what is a default servlet? I'll talk about it later). According to this rule table, the matching process of the servlet can be clearly known, so the url-pattern should also be considered when defining the servlet to avoid errors.
For filter, it will not match only one servlet like servlet, because the collection of filters is a chain, so only the order of processing is different, and only one filter will not be selected. Filters are processed in the same order as filter-mapping is defined in web.xml.
Second, the url-pattern is explained in detail in the web.xml file. The following syntax is used to define the mapping:
l Starting with "/' and ending with "/*" are used for path mapping.
l The prefix "*." is used for extended mapping.
l "/" is used to define the default servlet mapping.
l The rest are used to define detailed mappings. For example: /aa/bb/cc.action So why is it wrong to define "/*.action" for a seemingly normal match? Because this match belongs to both path mapping and extension mapping, the container cannot judge.
The article comes from http://www.360doc.cn/article/18995_552388.html, which is only used for learning and communication, and is deleted for infringement.