Servlet 3.0 新特性概述

Servlet 3.0 作为 Java EE 6 规范体系中一员，随着 Java EE 6 规范一起发布。该版本在前一版本（Servlet 2.5）的基础上提供了若干新特性用于简化 Web 应用的开发和部署。其中有几项特性的引入让开发者感到非常兴奋，同时也获得了 Java 社区的一片赞誉之声：

1. 异步处理支持：有了该特性，Servlet 线程不再需要一直阻塞，直到业务处理完毕才能再输出响应，最后才结束该 Servlet 线程。在接收到请求之后，Servlet 线程可以将耗时的操作委派给另一个线程来完成，自己在不生成响应的情况下返回至容器。针对业务处理较耗时的情况，这将大大减少服务器资源的占用，并且提高并发处理速度。
2. 新增的注解支持：该版本新增了若干注解，用于简化 Servlet、过滤器（Filter）和监听器（Listener）的声明，这使得 web.xml 部署描述文件从该版本开始不再是必选的了。
3. 可插性支持：熟悉 Struts2 的开发者一定会对其通过插件的方式与包括 Spring 在内的各种常用框架的整合特性记忆犹新。将相应的插件封装成 JAR 包并放在类路径下，Struts2 运行时便能自动加载这些插件。现在 Servlet 3.0 提供了类似的特性，开发者可以通过插件的方式很方便的扩充已有 Web

1.简介

web.xml文件是Java web项目中的一个配置文件，主要用于配置欢迎页、Filter、Listener、Servlet等，但并不是必须的，一个java web项目没有web.xml文件照样能跑起来。Tomcat容器/conf目录下也有作用于全局web应用web.xml文件，当一个web项目要启动时，Tomcat会首先加载项目中的web.xml文件，然后通过其中的配置来启动项目，只有配置的各项没有错误时，项目才能正常启动。

那么web.xml文件中到底有些什么内容呢？我们要如何去配置它以适应我们的项目呢？
首先让我们从Tomcat加载资源的顺序开始，一步步分析web.xml文件的作用。

2.Tomcat加载资源顺序

Tomcat启动时加载资源主要有三个阶段：

• 第一阶段：JVM相关资源

  (1)$JAVA_HOME/jre/lib/ext/*.jar
  (2)系统classpath环境变量中的*.jar和*.class 

• 第二阶段：Tomcat自身相关资源

  (1)$CATALINA_HOME/common/classes/*.class  
  (2)$CATALINA_HOME/commons/endorsed/*.jar   
  (3)$CATALINA_HOME/commons/i18n/*.jar   
  (4)$CATALINA_HOME/common/lib/*.jar

代码：$(document).ready(function() {

很久都没时间写这个系列的东西了， 今天感觉还得继续下去，因此在继续继续一下， 今天要谈的是什么是同步， 什么是异步， 为了说明这个问题，先讲个故事，来说明一下 同步和异步的重要性！

一。 听对了，说对了， 不等于都对了！

先说一下， 甲对乙说了一句话， 甲说对了， 乙也听对了， 然后乙就去按照甲的意思去办理了， 那么乙一定能办对吗？当然假设乙在办理事情的过程中没有任何失误等等。

其实结果是大家 未必像大家想象的！

不啰嗦了，说故事。

本人现在在北京居住了很多年， 一天吃饭时， 家里发出了一个奇怪的声音， 于是我就去找一下， 别是什么电器什么坏了前兆， 若是发现了， 好及时修理。

找了几个地方， 都没找到， 于是我就说， 哪里来的声音？  一旁的老婆说了， 是南京大陆分吹过大陆架发出的声音。

我听后就特别奇怪， 我在北京怎么能听到 远在地球最南边的南极的声音？  我真要成为 顺风耳不成？ 奇怪呀奇怪！

我不解的说着， 怎么可能是南极的声音， … 阅读全文

在SpringSide 3的官方文档中，说安全框架使用的是Spring Security 2.0。乍一看，吓了我一跳，以为Acegi这么快就被淘汰了呢。上搜索引擎一搜，发现原来Spring Security 2.0就是Acegi 2.0。悬着的心放下来了。虽然SpringSide 3中关于Acegi的配置文件看起来很不熟悉，但是读了Acegi 2.0的官方文档后，一切都释然了。
先来谈一谈Acegi的基础知识，Acegi的架构比较复杂，但是我希望我下面的只言片语能够把它说清楚。大家都知道，如果要对Web资源进行保护，最好的办法莫过于Filter，要想对方法调用进行保护，最好的办法莫过于AOP。Acegi对Web资源的保护，就是靠Filter实现的。如下图：

一般来说，我们的Filter都是配置在web.xml中，但是Acegi不一样，它在web.xml中配置的只是一个代理，而真正起作用的Filter是作为Bean配置在Spring中的。web.xml中的代理依次调用这些Bean，就实现了对Web资源的保护，同时这些Filter作为Bean被Spring管理，所以实现AOP也很简单，真的是一举两得啊。
Acegi中提供的Filter不少，有十多个，一个一个学起来比较复杂。但是对于我们Web开发者来说，常用的就那么几个，如下图中的被红圈圈标记出来的：

从上到下，它们实现的功能依次是1、制定必须为https连接；2、从Session中提取用户的认证信息；3、退出登录；4、登录；5、记住用户；6、所有的应用必须配置这个Filter。
一般来说，我们写Web应用只需要熟悉这几个Filter就可以了，如果不需要https连接，连第一个也不用熟悉。但是有人肯定会想，这些Filter怎么和我的数据库联系起来呢？不用着急，这些Filter并不直接处理用户的认证，也不直接处理用户的授权，而是把它们交给了认证管理器和决策管理器。如下图：

对于这两种管理器，那也是不需要我们写代码的，Acegi也提供了现成的类。那么大家又奇怪了：又是现成的，那怎么和我的数据库关联起来呢？别着急，其实这两个管理器自己也不做事，认证管理器把任务交给了Provider，而决策管理器则把任务交给了Voter，如下图：

现在我要告诉你们，这里的Provider和Voter也是不需要我们写代码的。不要崩溃，快到目标了。Acegi提供了多个Provider的实现类，如果我们想用数据库来储存用户的认证数据，那么我们就选择DaoAuthenticationProvider。对于Voter，我们一般选择RoleVoter就够用了，它会根据我们配置文件中的设置来决定是否允许某一个用户访问制定的Web资源。
而DaoAuthenticationProvider也是不直接操作数据库的，它把任务委托给了UserDetailService，如下图：

而我们要做的，就是实现这个UserDetailService。图画得不好，大家不要见笑，但是说了这么多总算是引出了我们开发中的关键，那就是我们要实现自己的UserDetailService，它就是连接我们的数据库和Acegi的桥梁。UserDetailService的要求也很简单，只需要一个返回org.springframework.security.userdetails.User对象的loadUserByUsername(String userName)方法。因此，怎么设计数据库都可以，不管我们是用一个表还是两个表还是三个表，也不管我们是用户-授权，还是用户-角色-授权，还是用户-用户组-角色-授权，这些具体的东西Acegi统统不关心，它只关心返回的那个User对象，至于怎么从数据库中读取数据，那就是我们自己的事了。
反过来再看看上面的过程，我们发现，即使我们要做的只是实现自己的UserDetailService类，但是我们不得不在Spring中配置那一大堆的Bean，包括几个Filter，几个Manager，几个Provider和Voter，而这些配置往往都是重复的无谓的。好在Acegi 2.0也认识到了这个问题，所以，它设计了一个<http>标签，让Acegi的配置得到了简化。下面是SpringSide 3中的配置的截图，大家可以看看：

下图是官方文章中的传统Filter设置和<http>元素之间的对应关系：

下面的代码是SpringSide 3中实现UserDetailService的范例，在SpringSide 3的范例中，白衣使用了三个表User、Role、Authority。但是Acegi不关心你用了几个表，它只关心UserDetails对象。而决定用户能否访问指定Web资源的，是RoleVoter类，无需任何修改它可以工作得很好，唯一的缺点是它只认ROLE_前缀，所以搞得白衣的Authority看起来都象角色，不伦不类。

package personal.youxia.service.security;
import java.util.ArrayList;
import java.util.List;
import org.springframework.beans.factory.annotation.Required;
import org.springframework.dao.DataAccessException;
import org.springframework.security.GrantedAuthority;
import org.springframework.security.GrantedAuthorityImpl;

较为简单或者体量较小的技术，完全可以参考着demo直接上手，但系统的学习一门技术则不然。以我的认知，一般的文档大致有两种风格：Architecture First和Code First。前者致力于让读者先了解整体的架构，方便我们对自己的认知有一个宏观的把控，而后者以特定的demo配合讲解，可以让读者在解决问题的过程中顺便掌握一门技术。关注过我博客或者公众号的朋友会发现，我之前介绍技术的文章，大多数是Code First，提出一个需求，介绍一个思路，解决一个问题，分析一下源码，大多如此。而学习一个体系的技术，我推荐Architecture First，正如本文标题所言，这篇文章是我Spring Security系列的第一篇，主要是根据Spring Security文档选择性翻译整理而成的一个架构概览，配合自己的一些注释方便大家理解。写作本系列文章时，参考版本为Spring Security 4.2.3.RELEASE。

1 核心组件

这一节主要介绍一些在Spring Security中常见且核心的Java类，它们之间的依赖，构建起了整个框架。想要理解整个架构，最起码得对这些类眼熟。

1.1 SecurityContextHolder

SecurityContextHolder用于存储安全上下文（security context）的信息。当前操作的用户是谁，该用户是否已经被认证，他拥有哪些角色权限…这些都被保存在SecurityContextHolder中。SecurityContextHolder默认使用ThreadLocal 策略来存储认证信息。看到ThreadLocal 也就意味着，这是一种与线程绑定的策略。Spring Security在用户登录时自动绑定认证信息到当前线程，在用户退出时，自动清除当前线程的认证信息。但这一切的前提，是你在web场景下使用Spring Security，而如果是Swing界面，Spring也提供了支持，SecurityContextHolder的策略则需要被替换，鉴于我的初衷是基于web来介绍Spring Security，所以这里以及后续，非web的相关的内容都一笔带过。

获取当前用户的信息

因为身份信息是与线程绑定的，所以可以在程序的任何地方使用静态方法获取用户信息。一个典型的获取当前登录用户的姓名的例子如下所示：

Web.xml配置详解之context-param
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>contextConfigLocationValue></param-value>
</context-param>
作用：该元素用来声明应用范围(整个WEB项目)内的上下文初始化参数。

param-name 设定上下文的参数名称。必须是唯一名称

param-value 设定的参数名称的值

初始化过程：
在启动Web项目时，容器(比如Tomcat)会读web.xml配置文件中的两个节点<listener>和<contex-param>。
接着容器会创建一个ServletContext(上下文),应用范围内即整个WEB项目都能使用这个上下文。
接着容器会将读取到<context-param>转化为键值对,并交给ServletContext。
容器创建<listener></listener>中的类实例,即创建监听（备注：listener定义的类可以是自定义的类但必须需要继承ServletContextListener）。
在监听的类中会有一个contextInitialized(ServletContextEvent event)初始化方法，在这个方法中可以通过event.getServletContext().getInitParameter(“contextConfigLocation”) 来得到context-param 设定的值。在这个类中还必须有一个contextDestroyed(ServletContextEvent event) 销毁方法.用于关闭应用前释放资源，比如说数据库连接的关闭。
得到这个context-param的值之后,你就可以做一些操作了.注意,这个时候你的WEB项目还没有完全启动完成.这个动作会比所有的Servlet都要早。
由上面的初始化过程可知容器对于web.xml的加载过程是context-param >> listener >> fileter >> servlet

如何使用
页面中
${initParam.contextConfigLocation}

Servlet中
String paramValue=getServletContext().getInitParameter(“contextConfigLocation”)

web.xml文件中配置<context-param>和<init-param>的区别

web工程大多都需要配置web.xml文件，web.xml文件主要用来配置Listener、Filter、Servlet等。web.xml文件包括xml文件头，DOCTYPE声明，web-app元素。

web.xml的加载过程（引用）
在web-app元素内，元素的配置顺序与工程的加载顺序无关，web.xml的加载过程为：

启动一个web项目，web容器（如tomcat）读取web.xml文件，读取其中的配置信息… 阅读全文

在本章中，我们将会介绍访问控制列表这个复杂话题，它能够提供域对象实例层次授权的丰富模型。Spring Security提供了强大的访问控制列表，但是复杂且缺少文档，它能够很好的满足小到中型规模的实现。
在本章的内容中，我们将会：

理解访问控制列表的概念模型；

了解Spring Security ACL模型中的关于访问控制列表的术语和应用；

构建和了解支持Spring ACL的数据库模式；

配置JBCP Pets通过注解和Spring bean来使用ACL保护业务方法；

进行高级配置，包括自定义许可、使用ACL的JSP标签检查和方法安全，易变的ACL以及缓存；

了解架构要考虑的因素以及规划ACL部署的场景。

译者注：在本章中术语permission翻译为许可权限；entry翻译为条目；access control entry即为访问控制条目。

使用访问控制列表保护业务对象

最后一个非web层安全的问题是业务对象层次的安全，它在业务层或业务层以下。这个层次的安全实现使用了一项名为访问控制列表（access control list，或ACL）的技术。ACL中的对象可以进行权限判断——ACL允许基于唯一的组、业务对象以及逻辑操作进行特定的许可。

例如，在JBCP Pets中的一个ACL声明可能会是这样的：用户只能对自己的简介进行写操作。可能像下面展现的这样：

你会发现这个ACL对人工来说很易读——Amy对自己的简介（Profile123）能够进行读写；其它的注册用户能够读Amy的简介，而匿名用户不能。简单来说，这种类型的规则矩阵就是ACL所试图做的，即将代码、访问检查、安全系统和业务数据的元数据进行集成。大多数真正使用ACL的系统会有很复杂的ACL列表以及整个系统中百万级的条目。尽管这听起来有令人感到害怕的复杂性，但是预先适当的思考和使用良好的安全库能够使得ACL管理相当可行。

如果你使用Microsoft Windows或者基于Unix/Linux的电脑，那你每天都在体验ACL。大多数现代电脑的操作系统都使用ACL指令作为文件存储系统的一部分，这允许基于用户或组、文件或目录以及许可权限的组合进行许可授权。在Microsoft … 阅读全文

Acl的全称是Access Control List，俗称访问控制列表，是用以控制对象的访问权限的。其主要思想是将某个对象的某种权限授予给某个用户，或某种GrantedAuthority（可以简单的理解为某种角色），它们之间的关系都是多对多。如果某一个对象的某一操作是受保护的，那么在对该对象进行某种操作时就需要有对应的权限。

1.1     准备工作

使用Spring Security的Acl功能需要引入Acl相关的jar包。如果我们的应用是使用Maven构建的，则可以在应用的pom.xml文件中加入如下依赖。

<dependency>

<groupId>org.springframework.security</groupId>

<artifactId>spring-security-acl</artifactId>

<version>${spring.security.version}</version>

</dependency>

此外，使用Spring Security的Acl时需要在数据库中建立四张表。在其官方文档中给出了一个基于数据库HSQLDB的建表语句。其脚本如下：

各个表的简介如下：
users: 不属于ACL的表，用户表，userService会使用本表，users.USERNAME = acl_sid.SID，acl_sid有对应的记录表示同一个principal，所以大家可以看到ER图中没有外键关系
authorities:用于记录用户被授予的权限，authorities.AUTHORITY = acl_sid.SID，acl_sid即可以表示一个principal，也可以表示一个authority,通过acl_sid.PRINCIPAL字段来区分
contacts:是本例的实体表，对该表的记录进行CRWDA权限的控制，contacts.ID = acl_object_identity.OBJECT_ID_IDENTITY;
acl_class: 表示对哪个java entity进行权限控制，本例contacts表只有一条记录为’entity ‘sample.contact.Contact';
acl_sid :security identity，根据PRINCIPAL字段的不同分别表示principal或者authority;
acl_object_identity:acl_object_identity.OBJECT_ID_IDENTITY = contacts.ID，acl_object_identity.OBJECT_ID_CLASS=acl_class.ID
and acl_object_identity.OWNER_SID= acl_sid.ID;分别对对应字段的引用，也就是说id及该entity的类型唯一地确定一条acl_object_identity记录，acl_object_identity是对实体记录的抽象。
acl_entry: acl_entry.SID … 阅读全文

       Spring Security的权限鉴定是由AccessDecisionManager接口负责的。具体来说是由其中的decide()方法负责，其定义如下。

    void decide(Authentication authentication, Object object, Collection<ConfigAttribute> configAttributes)

        throws AccessDeniedException, InsufficientAuthenticationException;

       如你所见，该方法接收三个参数，第一个参数是包含当前用户信息的Authentication对象；第二个参数表示当前正在请求的受保护的对象，基本上来说是MethodInvocation（使用AOP）、JoinPoint（使用Aspectj）和FilterInvocation（Web请求）三种类型；第三个参数表示与当前正在访问的受保护对象的配置属性，如一个角色列表。

1.1     Spring Security的AOP Advice思想

       对于使用AOP而言，我们可以使用几种不同类型的advice：before、after、throws和around。其中around advice是非常实用的，通过它我们可以控制是否要执行方法、是否要修改方法的返回值，以及是否要抛出异常。Spring Security在对方法调用和Web请求时也是使用的around advice的思想。在方法调用时，可以使用标准的Spring AOP来达到around advice的效果，而在进行Web请求时是通过标准的Filter来达到around advice的效果。

       对于大部分人而言都比较喜欢对Service层的方法调用进行权限控制，因为我们的主要业务逻辑都是在Service层进行实现的。如果你只是想保护Service层的方法，那么使用Spring AOP就可以了。如果你需要直接保护领域对象，那么你可以考虑使用Aspectj。

       你可以选择使用Aspectj或Spring AOP对方法调用进行鉴权，或者选择使用Filter对Web请求进行鉴权。当然，你也可以选择使用这三种方式的任意组合进行鉴权。通常的做法是使用Filter对Web请求进行一个比较粗略的鉴权，辅以使用Spring AOP对Service层的方法进行较细粒度的鉴权。

1.2     AbstractSecurityInterceptor

       AbstractSecurityInterceptor是一个实现了对受保护对象的访问进行拦截的抽象类，其中有几个比较重要的方法。beforeInvocation()方法实现了对访问受保护对象的权限校验，内部用到了AccessDecisionManager和AuthenticationManager；finallyInvocation()方法用于实现受保护对象请求完毕后的一些清理工作，主要是如果在beforeInvocation()中改变了SecurityContext，则在finallyInvocation()中需要将其恢复为原来的SecurityContext，该方法的调用应当包含在子类请求受保护资源时的finally语句块中；afterInvocation()方法实现了对返回结果的处理，在注入了AfterInvocationManager的情况下默认会调用其decide()方法。AbstractSecurityInterceptor只是提供了这几种方法，并且包含了默认实现，具体怎么调用将由子类负责。每一种受保护对象都拥有继承自AbstractSecurityInterceptor的拦截器类， MethodSecurityInterceptor将用于调用受保护的方法，而FilterSecurityInterceptor将用于受保护的Web请求。它们在处理受保护对象的请求时都具有一致的逻辑，具体的逻辑如下。

       1、先将正在请求调用的受保护对象传递给beforeInvocation()方法进行权限鉴定。

       2、权限鉴定失败就直接抛出异常了。

       3、鉴定成功将尝试调用受保护对象，调用完成后，不管是成功调用，还是抛出异常，都将执行finallyInvocation()。

       4、如果在调用受保护对象后没有抛出异常，则调用afterInvocation()。

       以下是MethodSecurityInterceptor在进行方法调用的一段核心代码。

    public Object … 阅读全文