spring mvc拦截器详细配置

分享知识 传递快乐

处理器拦截器简介

Spring Web MVC的处理器拦截器类似于Servlet开发中的过滤器Filter,用于对处理器进行预处理和后处理。


常见应用场景

1、日志记录:记录请求信息的日志,以便进行信息监控、信息统计、计算PV(Page View)等。
2、权限检查:如登录检测,进入处理器检测检测是否登录,如果没有直接返回到登录页面;
3、性能监控:有时候系统在某段时间莫名其妙的慢,可以通过拦截器在进入处理器之前记录开始时间,在处理完后记录结束时间,从而得到该请求的处理时间(如果有反向代理,如apache可以自动记录);
4、通用行为:读取cookie得到用户信息并将用户对象放入请求,从而方便后续流程使用,还有如提取Locale、Theme信息等,只要是多个处理器都需要的即可使用拦截器实现。
5、OpenSessionInView:如Hibernate,在进入处理器打开Session,在完成后关闭Session。
本质也是AOP(面向切面编程),也就是说符合横切关注点的所有功能都可以放入拦截器实现。


拦截接口

package org.springframework.web.servlet;

public interface HandlerInterceptor {
	boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception;

	void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception;

	void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception;
}
preHandle:预处理回调方法,实现处理器的预处理(如登录检查),第三个参数为响应的处理器;返回值:
true表示继续流程(如调用下一个拦截器或处理器);
false表示流程中断(如登录检查失败),不会继续调用其他的拦截器或处理器,此时我们需要通过response来产生响应。

postHandle:后处理回调方法,实现处理器的后处理(但在渲染视图之前),此时我们可以通过modelAndView(模型和视图对象)对模型数据进行处理或对视图进行处理,modelAndView也可能为null。

afterCompletion:整个请求处理完毕回调方法,即在视图渲染完毕时回调,如性能监控中我们可以在此记录结束时间并输出消耗时间,还可以进行一些资源清理,类似于try-catch-finally中的finally,但仅调用处理器执行链中preHandle返回true的拦截器的afterCompletion。

或者继承HandlerInterceptorAdapter类:HandlerInterceptorAdapter类实现了AsyncHandlerInterceptor接口,同时间又继承了HandlerInterceptor接口。


Spring MVC并没有总的拦截器,不能对所有的请求进行前后拦截。
Spring MVC的拦截器,是属于HandlerMapping级别的,可以有多个HandlerMapping ,每个HandlerMapping可以有自己的拦截器。
当一个请求按Order值从小到大,顺序执行HandlerMapping接口的实现类时,哪一个先有返回,那就可以结束了,后面的HandlerMapping就不走了,本道工序就完成了。就转到下一道工序了。
拦截器会在什么时候执行呢?一个请求交给一个HandlerMapping时,这个HandlerMapping先找有没有处理器来处理这个请求,如何找到了,就执行拦截器,执行完拦截后,交给目标处理器。

如果没有找到处理器,那么这个拦截器就不会被执行。


静态资源:



在spring MVC的配置拦截器三种配置方式:

方案一:拦截所有url


	

Spring没有总的拦截器,会为每一个HandlerMapping,注入一个拦截器。总有一个HandlerMapping是可以找到处理器的,最多也只找到一个处理器,所以这个拦截器总会被执行的。起到了总拦截器的作用。如果是REST风格的URL,静态资源也会被拦截。

方案二: 拦截匹配的URL


	
		
		 
		
		
		
		
		
	

比方案一多了一个URL匹配。如果是REST风格的URL,静态资源也会被拦截。

方案三:HandlerMappint上的拦截器

如果是REST风格的URL,静态资源就不会被拦截,因为我们精准的注入了拦截器。


	
		
			
			
			
		
	


如果使用了,它会自动注册DefaultAnnotationHandlerMapping 与AnnotationMethodHandlerAdapter 这两个bean,所以就没有机会再给它注入interceptors属性,就无法指定拦截器。当然我们可以通过人工配置上面的两个Bean,不使用 ,就可以 给interceptors属性 注入拦截器了。

其实个人不建议使用 ,而建议手动写详细的配置文件,来替代 ,这就控制力就强了。


PS:

REST风格的四种请求方式:
1、GET:获 取资源
2、POST:新建资源
3、PUT:更新资源
4、DELETE:删除资源


SpringMVC 拦截器不拦截静态资源的三种处理方式

SpringMVC提供来设置静态资源,但是增加该设置如果采用通配符的方式增加拦截器的话仍然会被拦截器拦截,可采用如下方案进行解决。

方案一、拦截器中增加针对静态资源不进行过滤


  
  
 


    
		
        
		
        
        
        
        
    

方案二、使用默认的静态资源处理Servlet处理静态资源

在spring-mvc.xml中启用默认Servlet

在web.xml中增加对静态资源的处理

    
    default
    *.js
    *.css
    /static/*"

但是当前的设置必须在Spring的Dispatcher的前面。

方案三、修改Spring的全局拦截设置为*.do的拦截(涉及web.xml)


    SpringMVC
    org.springframework.web.servlet.DispatcherServlet
    
        contextConfigLocation
        classpath:spring-mvc.xml
    
    1
    true


    SpringMVC
    *.do
这样设置,Spring就会只针对以'.do'结尾的请求进行处理,不再维护静态资源

针对这三种方案的优劣分析:
第一种方案配置比较臃肿,多个拦截器时增加文件行数,不推荐使用;
第二种方案使用默认的Servlet进行资源文件的访问,Spring拦截所有请求,然后再将资源文件交由默认的Sevlet进行处理,性能上少有损耗;
第三种方案Spring只是处理以'.do'结尾的访问,性能上更加高效,但是再访问路径上必须都以'.do'结尾,URL不太文雅;

综上所述,推荐使用第二和第三中方案。









你可能感兴趣的:(spring,mvc拦截器,拦截静态资源,mvc配置)