Career J

在Tomcat的每一个web application（Tomcat管他叫Context）中，都有一个名为web.xml文件，它专门用来告诉服务器，该web application都有哪些类可以拿来运行，或是其它类型的文件，比如图片或者音乐。这个文件还包含了一些用来运行servlet的初始参数。这个web.xml文件就是所谓的“部署描述符（deployment descriptor）”。

“部署描述符”最重要的功能之一，就是告诉服务器，当用户输入或者点击了某个URL，进而把请求发送到服务器之后，服务器应该用哪个类来向用户的请求作出响应呢？

举个例子。我们在Tomcat服务器中部署了一个叫做 cinema 的应用程序。在这个程序中有两个类，一个Tickets类，一个FilmInfo类。我们希望当用户输入http://.../cinema/buyticket 这个网址的时候，调用Tickets类来响应用户的请求；而当用户点击http://.../cinema/todaysfilm 的时候，调用FilmInfo类。

那么Tomcat服务器如何知道URL和具体的类之间的对应关系呢？这种对应关系以一种非常直截了当的方式记录在web.xml文件中了。具体的方法就像这样：

<servlet-mapping>
  <servlet-name>Tickets</servlet-name>
  <url-pattern>/buyticket</url-pattern>
</servlet-mapping>

（事实上Tickets不是类的文件名，而是注册在服务器中的注册名）

为了提高网站的灵活性，在web.xml中也可以使用通配符，使得用户输入的某一类域名都由一个servlet来处理。比如上面的代码段中，可以把第三行这样写：

<url-pattern>/buy*</url-pattern>

然后我们可以在广告中发布许多个链接给用户，比如.../buyticket, .../buydrink, .../buyfood等等。这样一来，Tickets类事实上就可以处理所有的购买请求。只需在类的内部，使用getRequestURI()方法获得用户输入的实际网址，然后分别处理即可。

类似的，我们可以像在操作系统中输入“*.exe”那样，输入一个“*.html”。这种方式的url-pattern使得用一个servlet处理所有“看似”html的网页请求成为可能。

假如我们既不指定具体的url-pattern名称，也不使用通配符，而是仅仅使用一个“/”，那么这和输入“/*”是没什么区别的。如果在web.xml中，某个servlet被映射到“/”上，那么它就惨透了！因为这个servlet要负责处理所有其他url-pattern所不能匹配的请求。

现在的问题是，下面这种情况有可能出现：

<servlet-mapping>
  <servlet-name>Tickets</servlet-name>
  <url-pattern>/buy*</url-pattern>
</servlet-mapping>

<servlet-mapping>
  <servlet-name>FilmInfo</servlet-name>
  <url-pattern>/*.ifo</url-pattern>
</servlet-mapping>

当上面的两个mapping同时存在的时候，如果用户请求了..../cinema/buyticket.ifo 这样一个地址，Tomcat会不会敢到挠头呢？

不会的。Tomcat对web.xml中定义的url-pattern分为四类，这四类按照优先级从高到底分别是：

explicit mapping: 映射中不包含任何通配符，这是一种准确的映射。就像/buyticket。

path prefix mapping: 例如/buysomething/*。这种映射以/开头，以/*结尾，可以处理所有以相同前缀开头的请求。比如/buysomething/tea和/buysomething/pig将指向同一个servlet。

extension mapping: 就是上面所说的/*.ifo或/*.html那样的映射。

default mapping: 传说中最强大、最万能的映射，使用“/”处理所有别人管不了的请求。