路径匹配原则(path matching) spring mvc中的路径匹配要比标准的web.xml要灵活的多。默认的策略实现了 org.springframework.util.antpathmatcher，就像名字提示的那样，路径模式是使用了apache ant的样式路径，apache ant样式的路径有三种通配符匹配方法（在下面的表格中列出)
这些可以组合出很多种灵活的路径模式
table ant wildcard characters
| wildcard |
description |
|
| ? |
匹配任何单字符 |
|
| * |
匹配0或者任意数量的字符 |
|
| ** |
匹配0或者更多的目录 |
|
table example ant-style path patterns
| path |
description |
|
| /app/*.x |
匹配(matches)所有在app路径下的.x文件 |
|
| /app/p?ttern |
匹配(matches) /app/pattern 和 /app/pxttern,但是不包括/app/pttern |
|
| /**/example |
匹配(matches) /app/example, /app/foo/example, 和 /example |
|
| /app/**/dir/file. |
匹配(matches) /app/dir/file.jsp, /app/foo/dir/file.html,/app/foo/bar/dir/file.pdf, 和 /app/dir/file.java |
|
| /**/*.jsp |
匹配(matches)任何的.jsp 文件 |
|
handlermapping
一 个web应用程序基本上都要依赖于url与请求处理器之间的映射，spring mvc也是一样，但spring mvc就像spring所作的一切一样(译者：灵活，可以配置各种东西，但是也造成了很多复杂性)，肯定不会只有一种方法来映射url和 controller之间的关系，并且在实际上，允许你自己创建映射规则和实现，而不仅仅依赖url映射。
spring提供了url的映射处理， 并且处理路径模式的顺序和方法并没有限定到任何的接口上。spring mvc的默认实现org.springframework.web.servlet.handler. abstracturlhandlermapping, 会以最长符合路径模式来匹配一个路径。
例如：给定一个请求是 /app/dir/file.jsp 并且现在存在两个路径匹配模式/**/*.jsp 和/app/dir/*.jsp, 那么，url会匹配那个模式呢？最后的那个模式/app/dir/*.jsp，会因为最长(has more characters)的原则被匹配,它比/**/*.jsp拥有更多的字符.注意的是，这个原则并没有在任何高级别的接口中指定，但却是一种实现细节。
!!下面看一下默认的两个handlermapping
beannameurlhandlermapping
默 认的映射策略实现是org.springframework.web. servlet.handler.beannameurlhandlermapping类. 这个类要求任何有可能处理请求的bean都要起一个以反斜杠(/)字符开头的名称或者别名，这个名称或者别名可以是符合中的任何名字。
listing a controller mapped by a bean name
xml 代码
- <bean name="/home"
- class="com.apress.expertspringmvc.flight.web.homecontroller">
- <property name="flightservice" ref="flightservice" />
- bean>
■注意：你不能使用id这个属性来指定任何的url路径，因为在xml规格定中禁止(/)字符来指定xml的id,不过你可以在一个bean定义中同时拥有id和name属性
beannameurlhandlermapping 的缺点
它 非常便于使用的同时，也拥有一些缺点。它不能影射一个prototype的bean.换句话说，当使用 beannameurlhandlermapping时， 所有的请求处理类只能是单例的(singletons) . 一般来说,controllers 都是按照单例建立的，所以这个并不是一个很严重的问题.还有，我会在后面的章节中介绍controller，只会有很少类型的controller需要是 prototypes.
■注释： prototype bean 是一种非单例(non-singleton)的bean. 任何一次调用applicationcontext的getbean()方法时都会返回一个新的bean实例更多的信息请参照<>.
beannameurlhandlermapping的另外一个问题存在于在你的应用程序中 应用拦截(interceptor). 因为请求的映射(handler mapping )和bean(beans imapping)的映射给绑定在一起了，没有分开,这样就不可能在controller和拦截之间创建复杂的关系。如果有复杂的请求映射需求，你可以用 simpleurlhandlermapping 来代替beannameurlhandlermapping. simpleurlhandlermapping作为beannameurlhandlermapping的另外一种选择, simpleurlhandlermapping直指beannameurlhandlermapping的两大软肋.它可以映射 prototype类型的请求处理器,并且它允许你为处理器(handlers)和拦截器(interceptors)之间创建复杂灵活的映射
路 径的映射算法与beannameurlhandlermapping是 使用相同的基础组件，所以这个模式依然是映射url到请求处理器的(request handler) ，你简单的在applicationcontext中声明一下，就可以使用simpleurlhandlermapping了. dispatcherservlet会根据类型找到的，并且不会创建默认的映射器了(beannameurlhandlermapping).意思就是， 如果你想两个都用，那么就要全部声明一下在applicationcontext里.
■提示 dispatcherservlet会链式处理请求的（译者：依次处理请求，可以参照过滤器和gof中的责任链模式)，这样允许按照你的要求处理映射，映射处理器(handler mappings )实现了orderedr接口.