web.xml 中的listener、 filter、servlet 加载顺序及其详解
一、概述
1、启动一个WEB项目的时候，WEB容器会去读取它的配置文件web.xml，读取
2、紧急着，容创建一个ServletContext（servlet上下文），这个web项目的所有部分都将共享这个上下文。
3、容器将
4、容器创建
二 、 load-on-startup
load-on-startup 元素在web应用启动的时候指定了servlet被加载的顺序，它的值必须是一个整数。如果它的值是一个负整数或是这个元素不存在，那么容器会在该 servlet被调用的时候，加载这个servlet 。如果值是正整数或零，容器在配置的时候就加载并初始化这个servlet，容器必须保证值小的先被加载。如果值相等，容器可以自动选择先加载谁。
在servlet的配置当中，
标记容器是否在启动的时候就加载这个servlet。
当值为0或者大于0时，表示容器在应用启动时就加载这个servlet；
当是一个负数时或者没有指定时，则指示容器在该servlet被选择时才加载。
正数的值越小，启动该servlet的优先级越高。
三 、加载顺序
首先可以肯定的是，加载顺序与它们在 web.xml 文件中的先后顺序无关。即不会因为 filter 写在 listener 的前面而会先加载 filter。最终得出的结论是：ServletContext -> listener -> filter -> servlet
同时还存在着这样一种配置节：context-param，它用于向 ServletContext 提供键值对，即应用程序上下文信息。我们的 listener, filter 等在初始化时会用到这些上下文中的信息，那么 context-param 配置节是不是应该写在 listener 配置节前呢？实际上 context-param 配置节可写在任意位置，因此真正的加载顺序为：context-param -> listener -> filter -> servlet
对于某类配置节而言，与它们出现的顺序是有关的。以 filter 为例，web.xml 中当然可以定义多个 filter，与 filter 相关的一个配置节是 filter-mapping，这里一定要注意，对于拥有相同 filter-name 的 filter 和 filter-mapping 配置节而言，filter-mapping 必须出现在 filter 之后，否则当解析到 filter-mapping 时，它所对应的 filter-name 还未定义。web 容器启动时初始化每个 filter 时，是按照 filter 配置节出现的顺序来初始化的，当请求资源匹配多个 filter-mapping 时，filter 拦截资源是按照 filter-mapping 配置节出现的顺序来依次调用 doFilter() 方法的。
servlet 同 filter 类似，此处不再赘述。
由此，可以看出，web.xml 的加载顺序是：ServletContext -> context-param -> listener -> filter -> servlet ，而同个类型之间的实际程序调用的时候的顺序是根据对应的 mapping 的顺序进行调用的。
四 、 web.xml文件详解
我将自己知道的web.xml的元素整理了一下：
1、web.xml首先是肯定要包含它的schema.
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
其它的元素都放在
比如：
在此设定的参数，可以在servlet中用 getServletContext().getInitParameter("my_param") 来取得
2、listener
比如：
3.1、filter
比如：
3.2、filter-mapping
与
比如：
4.1、servlet
4.2、servlet-mapping
与
比如：
5、session-config
6、mime-mapping
比如：
7、welcom-file-list
比如：
8、error-page
比如：
9、taglib
比如：
10、resource-ref
比如，配置数据库连接池就可在此配置：
11、jsp-config
其中
1).
2).
3).
4).
5).
6).
7).
8).
一个简单的
配置web.xml来限制对某些servlet的请求
有时我们只希望通过认证的用户才能请求某些servlet的话，就可以在web.xml中来进行相应的配置，来达到此目的。
这就要用到
对于tomcat，中web.xml使用security-constraint元素需要在位于
此XML片段包括一个tomcat-users根元素，它包含一个或多个role和user元素。
然后在Web应用程序的web.xml中创建security-constraint、login-config和security-role元素。
其中security-constraint元素包含一个或多个web-resource-collection元素，它是描述Web应用程序中的哪些 web资源受到指定安全限制的保护。http-method元素指定安全限制覆盖的HTTP方法。上面的例子中，当我们对/HelloServlet的 GET或POST请求时将触发配置的安全机制。
auth-constraint元素用于描述允许访问Web组件的安全角色。此例中安全角色的例子有tomcat、manager、admin。而只有当作为admin角色的用户才可以访问HelloServlet。
Web应用程序通过login-config元素来认证用户，并确认该用户是否为正确的角色。
longin-config包含的transport-guarantee子元素用来指定认证方法，BASIC是一种常见的Web认证方式，浏览器给用户 提示一个对话框，要求输入用户名和密码，随后Tomcat将给出的用户名和密码与tomcat-users.xml中的用户名和密码进行比较，然后使用前 面的security-constraint配置来确定用户是否可访问受保护的servlet。
（除BASIC外，还可以是FORM、CLIENT-CERT、DIGEST等）
其实这种认证方法实际上有两个步骤：
1、检查提供的用户名和密码是否正确。
2、判断用户是否映射到特定的安全角色。例如，用户可能提供了正确的用户名和密码，但没有映射到特定的安全角色，也将被禁止访问特定的Web资源。