SSM

Spring、MyBatis和SpringMVC的整合

整合思路

关于SSM的架构可以简单看一下下面的草图。

 从上图可以看出，Spring在进行管理时，是很有条理的，每层都由Spring来管理，然后不同的层可以调用其它层，表现层调用业务层，业务层调用持久层等。根据这个架构，我来总结一下整合的思路，正是由于这个调用关系，所以我们可以从下往上一步步整合。

整合问题：

servlet的url-pattern匹配规则

 

　　首先需要明确几容易混淆的规则：

1. servlet容器中的匹配规则既不是简单的通配，也不是正则表达式，而是特定的规则。所以不要用通配符或者正则表达式的匹配规则来看待servlet的url-pattern。
2. Servlet 2.5开始，一个servlet可以使用多个url-pattern规则，<servlet-mapping>标签声明了与该servlet相应的匹配规则，每个<url-pattern>标签代表1个匹配规则；
3. 当servlet容器接收到浏览器发起的一个url请求后，容器会用url减去当前应用的上下文路径，以剩余的字符串作为servlet映射，假如url是http://localhost:8080/appDemo/index.html，其应用上下文是appDemo，容器会将http://localhost:8080/appDemo去掉，用剩下的/index.html部分拿来做servlet的映射匹配
4. url-pattern映射匹配过程是有优先顺序的
5. 而且当有一个servlet匹配成功以后，就不会去理会剩下的servlet了

1 精确匹配

　　<url-pattern>中配置的项必须与url完全精确匹配。

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/user/users.html</url-pattern>
    <url-pattern>/index.html</url-pattern>
    <url-pattern>/user/addUser.action</url-pattern>
</servlet-mapping>

　　当在浏览器中输入如下几种url时，都会被匹配到该servlet
　　http://localhost:8080/appDemo/user/users.html
　　http://localhost:8080/appDemo/index.html
　　http://localhost:8080/appDemo/user/addUser.action

　　

　　注意：

　　http://localhost:8080/appDemo/user/addUser/ 是非法的url，不会被当作http://localhost:8080/appDemo/user/addUser识别

　　另外上述url后面可以跟任意的查询条件，都会被匹配，如

　　http://localhost:8080/appDemo/user/addUser?username=Tom&age=23 会被匹配到MyServlet。

2 路径匹配

　　以“/”字符开头，并以“/*”结尾的字符串用于路径匹配

　　

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/user/*</url-pattern>
</servlet-mapping>

　　路径以/user/开始，后面的路径可以任意。比如下面的url都会被匹配。
　　http://localhost:8080/appDemo/user/users.html
　　http://localhost:8080/appDemo/user/addUser.action
　　http://localhost:8080/appDemo/user/updateUser.actionl

3 扩展名匹配

　　以“*.”开头的字符串被用于扩展名匹配

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>*.jsp</url-pattern>
    <url-pattern>*.action</url-pattern>
</servlet-mapping>

　　则任何扩展名为jsp或action的url请求都会匹配，比如下面的url都会被匹配
　　http://localhost:8080/appDemo/user/users.jsp
　　http://localhost:8080/appDemo/toHome.action

4 缺省匹配

　　

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/</url-pattern>
</servlet-mapping>

二、匹配顺序

1. 精确匹配，servlet-mapping1：<url-pattern>/user/users.html</url-pattern>，servlet-mapping2：<url-pattern>/*</url-pattern>。当一个请求http://localhost:8080/appDemo/user/users.html来的时候，servlet-mapping1匹配到，不再用servlet-mapping2匹配
2. 路径匹配，先最长路径匹配，再最短路径匹配servlet-mapping1：<url-pattern>/user/*</url-pattern>，servlet-mapping2：<url-pattern>/*</url-pattern>。当一个请求http://localhost:8080/appDemo/user/users.html来的时候，servlet-mapping1匹配到，不再用servlet-mapping2匹配
3. 扩展名匹配，servlet-mapping1：<url-pattern>/user/*</url-pattern>，servlet-mapping2：<url-pattern>*.action</url-pattern>。当一个请求http://localhost:8080/appDemo/user/addUser.action来的时候，servlet-mapping1匹配到，不再用servlet-mapping2匹配
4. 缺省匹配，以上都找不到servlet，就用默认的servlet，配置为<url-pattern>/</url-pattern>

三、需要注意的问题

1 路径匹配和扩展名匹配无法同时设置

　　匹配方法只有三种，要么是路径匹配（以“/”字符开头，并以“/*”结尾），要么是扩展名匹配（以“*.”开头），要么是精确匹配，三种匹配方法不能进行组合，不要想当然使用通配符或正则规则。

　　如<url-pattern>/user/*.action</url-pattern>是非法的

　　另外注意：<url-pattern>/aa/*/bb</url-pattern>是精确匹配，合法，这里的*不是通配的含义

2 "/*"和"/"含义并不相同

• “/*”属于路径匹配，并且可以匹配所有request，由于路径匹配的优先级仅次于精确匹配，所以“/*”会覆盖所有的扩展名匹配，很多404错误均由此引起，所以这是一种特别恶劣的匹配模式，一般只用于filter的url-pattern
• “/”是servlet中特殊的匹配模式，切该模式有且仅有一个实例，优先级最低，不会覆盖其他任何url-pattern，只是会替换servlet容器的内建default servlet ，该模式同样会匹配所有request。
• 配置“/”后，一种可能的现象是myServlet会拦截诸如http://localhost:8080/appDemo/user/addUser.action、http://localhost:8080/appDemo/user/updateUser的格式的请求，但是并不会拦截http://localhost:8080/appDemo/user/users.jsp、http://localhost:8080/appDemo/index.jsp，这是应为servlet容器有内置的“*.jsp”匹配器，而扩展名匹配的优先级高于缺省匹配，所以才会有上述现象。

　　Tomcat在%CATALINA_HOME%confweb.xml文件中配置了默认的Servlet，配置代码如下

<servlet>
        <servlet-name>default</servlet-name>
        <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
        <init-param>
            <param-name>debug</param-name>
            <param-value>0</param-value>
        </init-param>
        <init-param>
            <param-name>listings</param-name>
            <param-value>false</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
<servlet>
        <servlet-name>jsp</servlet-name>
        <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
        <init-param>
            <param-name>fork</param-name>
            <param-value>false</param-value>
        </init-param>
        <init-param>
            <param-name>xpoweredBy</param-name>
            <param-value>false</param-value>
        </init-param>
        <load-on-startup>3</load-on-startup>
 </servlet>
<servlet-mapping>
        <servlet-name>default</servlet-name>
        <url-pattern>/</url-pattern>
</servlet-mapping>

    <!-- The mappings for the JSP servlet -->
<servlet-mapping>
        <servlet-name>jsp</servlet-name>
        <url-pattern>*.jsp</url-pattern>
        <url-pattern>*.jspx</url-pattern>
</servlet-mapping>

• “/*”和“/”均会拦截静态资源的加载，需要特别注意

/bbs/*会匹配/bbs

DispatchServlet配置：

只配置/或/*会拦截所有请求，包括静态文件及jsp，springmvc无法处理会报错。

映射路径：/

【SpringMVC框架】<mvc:default-servlet-handler/>的作用

 

优雅REST风格的资源URL不希望带 .html 或 .do 等后缀.由于早期的Spring MVC不能很好地处理静态资源，所以在web.xml中配置DispatcherServlet的请求映射，往往使用 *.do 、 *.xhtml等方式。这就决定了请求URL必须是一个带后缀的URL，而无法采用真正的REST风格的URL。

如果将DispatcherServlet请求映射配置为"/"，则Spring MVC将捕获Web容器所有的请求，包括静态资源的请求，Spring MVC会将它们当成一个普通请求处理，因此找不到对应处理器将导致错误。

如何让Spring框架能够捕获所有URL的请求，同时又将静态资源的请求转由Web容器处理，是可将DispatcherServlet的请求映射配置为"/"的前提。由于REST是Spring3.0最重要的功能之一，所以Spring团队很看重静态资源处理这项任务，给出了堪称经典的两种解决方案。

先调整web.xml中的DispatcherServlet的配置，使其可以捕获所有的请求：

 

<servlet>
        <servlet-name>springMVC</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>springMVC</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>

通过上面url-pattern的配置，所有URL请求都将被Spring MVC的DispatcherServlet截获。

方法1.采用<mvc:default-servlet-handler />

<mvc:default-servlet-handler />

在springMVC-servlet.xml中配置<mvc:default-servlet-handler />后，会在Spring MVC上下文中定义一个org.springframework.web.servlet.resource.DefaultServletHttpRequestHandler，它会像一个检查员，对进入DispatcherServlet的URL进行筛查，如果发现是静态资源的请求，就将该请求转由Web应用服务器默认的Servlet处理，如果不是静态资源的请求，才由DispatcherServlet继续处理。

一般Web应用服务器默认的Servlet名称是"default"，因此DefaultServletHttpRequestHandler可以找到它。如果你所有的Web应用服务器的默认Servlet名称不是"default"，则需要通过default-servlet-name属性显示指定：

<mvc:default-servlet-handler default-servlet-name="所使用的Web服务器默认使用的Servlet名称" />

方法2.采用<mvc:resources />

<mvc:default-servlet-handler />将静态资源的处理经由Spring MVC框架交回Web应用服务器处理。而<mvc:resources />更进一步，由Spring MVC框架自己处理静态资源，并添加一些有用的附加值功能。

首先，<mvc:resources />允许静态资源放在任何地方，如WEB-INF目录下、类路径下等，你甚至可以将JavaScript等静态文件打到JAR包中。通过location属性指定静态资源的位置，由于location属性是Resources类型，因此可以使用诸如"classpath:"等的资源前缀指定资源位置。传统Web容器的静态资源只能放在Web容器的根路径下，<mvc:resources />完全打破了这个限制。

其次，<mvc:resources />依据当前著名的Page Speed、YSlow等浏览器优化原则对静态资源提供优化。你可以通过cacheSeconds属性指定静态资源在浏览器端的缓存时间，一般可将该时间设置为一年，以充分利用浏览器端的缓存。在输出静态资源时，会根据配置设置好响应报文头的Expires 和 Cache-Control值。

在接收到静态资源的获取请求时，会检查请求头的Last-Modified值，如果静态资源没有发生变化，则直接返回303相应状态码，提示客户端使用浏览器缓存的数据，而非将静态资源的内容输出到客户端，以充分节省带宽，提高程序性能。

在springMVC-servlet中添加如下配置：

<mvc:resources location="/static/" mapping="/static/**"/>

<mvc:resources location="/,classpath:/META-INF/publicResources/" mapping="/resources/**"/>

以上配置将Web根路径"/"及类路径下 /META-INF/publicResources/ 的目录映射为/resources路径。假设Web根路径下拥有images、js这两个资源目录,在images下面有bg.gif图片，在js下面有test.js文件，则可以通过 /resources/images/bg.gif 和 /resources/js/test.js 访问这二个静态资源。

假设WebRoot还拥有images/bg1.gif 及 js/test1.js，则也可以在网页中通过 /resources/images/bg1.gif 及 /resources/js/test1.js 进行引用。

<mvc:annotation-driven/>

关于这个标签，网上很多资料的信息都过时了，还是基于Spring3.1以前的版本（现在最新的是5.1.2），通过调试源码查看Log并查资料，总结如下：

其对应的实现类：org.springframework.web.servlet.config.AnnotationDrivenBeanDefinitionParser

它会向Spring容器中注册14个Bean，而其中主要的是下面几个：

1 RequestMappingHandlerMapping
2 BeanNameUrlHandlerMapping
3 RequestMappingHandlerAdapter
4 HttpRequestHandlerAdapter
5 SimpleControllerHandlerAdapter
6 ExceptionHandlerExceptionResolver
7 ResponseStatusExceptionResolver
8 DefaultHandlerExceptionResolver

上面几个Bean实例，都是用来做什么的呢？

关于它们的详细功能，在IDEA中将光标移动到AnnotationDrivenBeanDefinitionParser类名上，按Ctrl+q即可查看类文档。

前两个是HandlerMapping接口的实现类，用来处理请求映射的

• 其中第一个是处理@RequestMapping注解的
• 第二个会将controller类的名字映射为请求url

中间三个是用来处理请求的.具体点说就是确定调用哪个controller的哪个方法来处理当前请求

• 第一个处理@Controller注解的处理器，支持自定义方法参数和返回值（很酷）
• 第二个是处理继承HttpRequestHandler的处理器
• 第三个处理继承自Controller接口的处理器

后面三个是用来处理异常的解析器

另外还将提供以下支持：
① 支持使用ConversionService实例对表单参数进行类型转换； 
② 支持使用@NumberFormatannotation,@DateTimeFormat注解完成数据类型的格式化； 
③ 支持使用@Valid注解对Java bean实例进行JSR 303验证； 
④ 支持使用@RequestBody和@ResponseBody注解

综上，<mvc:annotation-driven/>标签主要是用来帮助我们处理请求映射，决定是哪个controller的哪个方法来处理当前请求，以及异常处理。

而在最新的spring项目中，如果不配置<mvc:annotation-driven/>，应用也可以正常处理请求。原因是什么呢？

经过debug DispatcherServlet的源码，发现如果不配置，spring将从DispatcherServlet.properties这个配置文件中加载默认配置，也是可以将上述的所有类注册到容器中的。

因此<mvc:annotation-driven/>这个标签其实是可以省略不写的。

<context:annotation-config/>

这是一条向Spring容器中注册

AutowiredAnnotationBeanPostProcessor

CommonAnnotationBeanPostProcessor

PersistenceAnnotationBeanPostProcessor

RequiredAnnotationBeanPostProcessor

这4个BeanPostProcessor.注册这4个BeanPostProcessor的作用，就是为了你的系统能够识别相应的注解。

那么哪些注释依赖这些Bean呢。

如果想使用 @Resource、@PostConstruct、@PreDestroy等注解就必须声明CommonAnnotationBeanPostProcessor。 
如果想使用 @PersistenceContext注解，就必须声明PersistenceAnnotationBeanPostProcessor的Bean。 
如果想使用 @Autowired注解，那么就必须事先在 Spring 容器中声明 AutowiredAnnotationBeanPostProcessor Bean。 
如果想使用 @Required的注解，就必须声明RequiredAnnotationBeanPostProcessor的Bean。

同样，传统的声明方式如下： 

<bean class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor "/> 

但是，就一般而言，这些注解我们是经常使用，比如Antowired,Resuource等注解，如果总是按照传统的方式一条一条的配置，感觉比较繁琐和机械。于是Spring给我们提供了<context:annotation-config/>的简化的配置方式。

注意：即使你使用了<context:annotation-config/>注解，以@Autowired为例，对于需要注入的Bean，仍然还要在xml中手动声明。这样很不方便，因此就引出了下面的<context:component-scan>注解。

1、使用@Autowired注解，那么就必须事先在 Spring 容器中声明 AutowiredAnnotationBeanPostProcessor Bean。

<bean class="org.springframework.beans.factory.annotation. AutowiredAnnotationBeanPostProcessor "/>

2、使用@ Resource 、@ PostConstruct、@ PreDestroy等注解就必须声明CommonAnnotationBeanPostProcessor

3、使用@PersistenceContext注解，就必须声明PersistenceAnnotationBeanPostProcessor

4、使用@Required的注解，就必须声明RequiredAnnotationBeanPostProcessor

<context:component-scan>

<context:component-scan>首先有和<context:annotation-config/>一样的作用，此外，它还可以扫描指定包下的类，将拥有注解的它们注册到Spring容器中。

综上，也就是说，如果用<context:annotation-config/>，我们还需要配置Xml注册Bean，而使用<context:component-scan />的话，注册的步骤都免了，当然前提是我们对需要扫描的类使用的注解（比如@Componet,@Service），而如果同时使用两个配置的话，<context:annotation-config/>会被忽略掉（如果配置了<context:component-scan>，就可以不配置<context:annotation-config/>了）。

Spring <context:property-placeholder/>的作用

1.有些参数在某些阶段中是常量

    比如 ：a、在开发阶段我们连接数据库时的连接url，username，password，driverClass等 

                b、分布式应用中client端访问server端所用的server地址，port，service等  

                 c、配置文件的位置

2.而这些参数在不同阶段之间又往往需要改变

   比如：在项目开发阶段和交付阶段数据库的连接信息往往是不同的，分布式应用也是同样的情况。

期望：能不能有一种解决方案可以方便我们在一个阶段内不需要频繁书写一个参数的值，而在不同阶段间又可以方便的切换参数配置信息

解决：spring3中提供了一种简便的方式就是context:property-placeholder/元素

只需要在spring的配置文件里添加一句：<context:property-placeholder location="classpath:jdbc.properties"/> 即可，这里location值为参数配置文件的位置，参数配置文件通常放在src目录下，而参数配置文件的格式跟java通用的参数配置文件相同，即键值对的形式，例如：

#jdbc配置

test.jdbc.driverClassName=com.mysql.jdbc.Driver
test.jdbc.url=jdbc:mysql://localhost:3306/test
test.jdbc.username=root
test.jdbc.password=root

行内#号后面部分为注释

应用：

1.这样一来就可以为spring配置的bean的属性设置值了，比如spring有一个jdbc数据源的类DriverManagerDataSource

在配置文件里这么定义bean：

<bean id="testDataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
   <property name="driverClassName" value="${test.jdbc.driverClassName}"/>
   <property name="url" value="${test.jdbc.url}"/>
   <property name="username" value="${test.jdbc.username}"/>
   <property name="password" value="${test.jdbc.password}"/>
</bean>

2.甚至可以将${ }这种形式的变量用在spring提供的注解当中，为注解的属性提供值

外在化应用参数的配置

在开发企业应用期间，或者在将企业应用部署到生产环境时，应用依赖的很多参数信息往往需要调整，比如LDAP连接、RDBMS JDBC连接信息。对这类信息进行外在化管理显得格外重要。PropertyPlaceholderConfigurer和PropertyOverrideConfigurer对象，它们正是担负着外在化配置应用参数的重任。

 <context:property-placeholder/>元素

PropertyPlaceholderConfigurer实现了BeanFactoryPostProcessor接口，它能够对<bean/>中的属性值进行外在化管理。开发者可以提供单独的属性文件来管理相关属性。比如，存在如下属性文件，摘自userinfo.properties。
db.username=scott
db.password=tiger

如下内容摘自propertyplaceholderconfigurer.xml。正常情况下，在userInfo的定义中不会出现${db.username}、${db.password}等类似信息，这里采用PropertyPlaceholderConfigurer管理username和password属性的取值。DI容器实例化userInfo前，PropertyPlaceholderConfigurer会修改userInfo的元数据信息（<bean/>定义），它会用userinfo.properties中db.username对应的scott值替换${db.username}、db.password对应的tiger值替换${db.password}。最终，DI容器在实例化userInfo时，UserInfo便会得到新的属性值，而不是${db.username}、${db.password}等类似信息。

<bean id="propertyPlaceholderConfigurer"  
        class="org.springframework.beans.factory.config.  
PropertyPlaceholderConfigurer">  
    <property name="locations">  
        <list>  
            <value>userinfo.properties</value>  
        </list>  
    </property>  
</bean>  
 
<bean name="userInfo" class="test.UserInfo">  
  <property name="username" value="${db.username}"/>  
  <property name="password" value="${db.password}"/>  
</bean> 

通过运行并分析PropertyPlaceholderConfigurerDemo示例应用，开发者能够深入理解PropertyPlaceholderConfigurer。为简化PropertyPlaceholderConfigurer的使用，Spring提供了<context:property-placeholder/>元素。下面给出了配置示例，启用它后，开发者便不用配置PropertyPlaceholderConfigurer对象了。

<context:property-placeholder location="userinfo.properties"/> 

PropertyPlaceholderConfigurer内置的功能非常丰富，如果它未找到${xxx}中定义的xxx键，它还会去JVM系统属性（System.getProperty()）和环境变量（System.getenv()）中寻找。通过启用systemPropertiesMode和searchSystemEnvironment属性，开发者能够控制这一行为。