Wetts's blog

Spring的配置文件applicationcontext.xml是通过spring提供的加载机制，自动加载的容器中去，在web项目中，配置文件加载到web容器中进行解析，目前，spring提供了两种加载器，以供web容器的加载：一种是ContextLoaderListener，另一种是ContextLoaderServlet。这两种在功能上完全相同，只是一种是基于Servlet2.3版本中新引入的Listener接口实现，而另一种是基于Servlet接口实现，以下是这两种加载器在web.xml中的时机配置应用：

作用：在启动Web容器时，自动装配Spring applicationContext.xml的配置信息。

如果在web.xml中不写任何参数配置信息，默认的路径是”/WEB-INF/applicationContext.xml，在WEB-INF目录下创建的xml文件的名称必须是applicationContext.xml。

概念：

• JavaBean: 先说 JavaBean，JavaBean 更多的是一种规范，也即包含一组 set 和 get 方法的 Java 对象。
• POJO（Plain Ordinary Java Object）: 普通的 Java 对象，对于属性一般实现了 JavaBean 的标准，另外还可以包含一些简单的业务逻辑（方法）。
• VO（View Object）：视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。
• DTO（Data Transfer Object）：数据传输对象，这个概念来源于 J2EE 的设计模式，原来的目的是为了 EJB 的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，我泛指用于展示层与服务层之间的数据传输对象。
• DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。
• PO（Persistent Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。

VO与DTO的区别

大家可能会有个疑问（在笔者参与的项目中，很多程序员也有相同的疑惑）：既然DTO是展示层与服务层之间传递数据的对象，为什么还需要一个VO呢？对！对于绝大部分的应用场景来说，DTO和VO的属性值基本是一致的，而且他们通常都是POJO，因此没必要多此一举，但不要忘记这是实现层面的思维，对于设计层面来说，概念上还是应该存在VO和DTO，因为两者有着本质的区别，DTO代表服务层需要接收的数据和返回的数据，而VO代表展示层需要显示的数据。

用一个例子来说明可能会比较容易理解：例如服务层有一个getUser的方法返回一个系统用户，其中有一个属性是gender（性别），对于服务层来说，它只从语义上定义：1-男性，2-女性，0-未指定，而对于展示层来说，它可能需要用“帅哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。说到这里，可能你还会反驳，在服务层直接就返回“帅哥美女”不就行了吗？对于大部分应用来说，这不是问题，但设想一下，如果需求允许客户可以定制风格，而不同风格对于“性别”的表现方式不一样，又或者这个服务同时供多个客户端使用（不同门户），而不同的客户端对于表现层的要求有所不同，那么，问题就来了。再者，回到设计层面上分析，从职责单一原则来看，服务层只负责业务，与具体的表现形式无关，因此，它返回的DTO，不应该出现与表现形式的耦合。

理论归理论，这到底还是分析设计层面的思维，是否在实现层面必须这样做呢？一刀切的做法往往会得不偿失，下面我马上会分析应用中如何做出正确的选择。

VO与DTO的应用

上面只是用了一个简单的例子来说明VO与DTO在概念上的区别，本节将会告诉你如何在应用中做出正确的选择。

在以下才场景中，我们可以考虑把VO与DTO二合为一（注意：是实现层面）：

当需求非常清晰稳定，而且客户端很明确只有一个的时候，没有必要把VO和DTO区分开来，这时候VO可以退隐，用一个DTO即可，为什么是VO退隐而不是DTO？回到设计层面，服务层的职责依然不应该与展示层耦合，所以，对于前面的例子，你很容易理解，DTO对于“性别”来说，依然不能用“帅哥美女”，这个转换应该依赖于页面的脚本（如JavaScript）或其他机制（JSTL、EL、CSS）

即使客户端可以进行定制，或者存在多个不同的客户端，如果客户端能够用某种技术（脚本或其他机制）实现转换，同样可以让VO退隐

以下场景需要优先考虑VO、DTO并存：

上述场景的反面场景

因为某种技术原因，比如某个框架（如 Flex）提供自动把 POJO 转换为 UI 中某些 Field 时，可以考虑在实现层面定义出 VO，这个权衡完全取决于使用框架的自动转换能力带来的开发和维护效率提升与设计多一个VO所多做的事情带来的开发和维护效率的下降之间的比对。

如果页面出现一个“大视图”，而组成这个大视图的所有数据需要调用多个服务，返回多个 DTO 来组装（当然，这同样可以通过服务层提供一次性返回一个大视图的 DTO 来取代，但在服务层提供一个这样的方法是否合适，需要在设计层面进行权衡）。

DTO与DO的区别

首先是概念上的区别，DTO 是展示层和服务层之间的数据传输对象（可以认为是两者之间的协议），而DO是对现实世界各种业务角色的抽象，这就引出了两者在数据上的区别，例如UserInfo和User（对于 DTO 和 DO 的命名规则，请参见笔者前面的一篇博文），对于一个 getUser 方法来说，本质上它永远不应该返回用户的密码，因此 UserInfo 至少比 User 少一个 password的数据。而在领域驱动设计中，正如第一篇系列文章所说，DO 不是简单的 POJO，它具有领域业务逻辑。

DTO与DO的应用

从上一节的例子中，细心的读者可能会发现问题：既然getUser方法返回的UserInfo不应该包含password，那么就不应该存在password这个属性定义，但如果同时有一个createUser的方法，传入的UserInfo需要包含用户的password，怎么办？在设计层面，展示层向服务层传递的DTO与服务层返回给展示层的DTO在概念上是不同的，但在实现层面，我们通常很少会这样做（定义两个UserInfo，甚至更多），因为这样做并不见得很明智，我们完全可以设计一个完全兼容的DTO，在服务层接收数据的时候，不该由展示层设置的属性（如订单的总价应该由其单价、数量、折扣等决定），无论展示层是否设置，服务层都一概忽略，而在服务层返回数据时，不该返回的数据（如用户密码），就不设置对应的属性。

对于DO来说，还有一点需要说明：为什么不在服务层中直接返回DO呢？这样可以省去DTO的编码和转换工作，原因如下：

两者在本质上的区别可能导致彼此并不一一对应，一个DTO可能对应多个DO，反之亦然，甚至两者存在多对多的关系。

DO具有一些不应该让展示层知道的数据

DO具有业务方法，如果直接把DO传递给展示层，展示层的代码就可以绕过服务层直接调用它不应该访问的操作，对于基于AOP拦截服务层来进行访问控制的机制来说，这问题尤为突出，而在展示层调用DO的业务方法也会因为事务的问题，让事务难以控制。

对于某些ORM框架（如Hibernate）来说，通常会使用“延迟加载”技术，如果直接把DO暴露给展示层，对于大部分情况，展示层不在事务范围之内（Open session in view在大部分情况下不是一种值得推崇的设计），如果其尝试在Session关闭的情况下获取一个未加载的关联对象，会出现运行时异常（对于Hibernate来说，就是 LazyInitiliaztionException）。

从设计层面来说，展示层依赖于服务层，服务层依赖于领域层，如果把DO暴露出去，就会导致展示层直接依赖于领域层，这虽然依然是单向依赖，但这种跨层依赖会导致不必要的耦合。

对于DTO来说，也有一点必须进行说明，就是DTO应该是一个“扁平的二维对象”，举个例子来说明：如果User会关联若干个其他实体（例如Address、Account、Region等），那么 getUser() 返回的 UserInfo，是否就需要把其关联的对象的DTO都一并返回呢？如果这样的话，必然导致数据传输量的大增，对于分布式应用来说，由于涉及数据在网络上的传输、序列化和反序列化，这种设计更不可接受。如果 getUser 除了要返回User的基本信息外，还需要返回一个 AccountId、AccountName、RegionId、RegionName，那么，请把这些属性定义到UserInfo中，把一个“立体”的对象树“压扁”成一个“扁平的二维对象”，笔者目前参与的项目是一个分布式系统，该系统不管三七二十一，把一个对象的所有关联对象都转换为相同结构的DTO对象树并返回，导致性能非常的慢。

DO 与 PO 的区别

DO 和 PO 在绝大部分情况下是一一对应的，PO 是只含有 get/set 方法的 POJO，但某些场景还是能反映出两者在概念上存在本质的区别：

DO在某些场景下不需要进行显式的持久化，例如利用策略模式设计的商品折扣策略，会衍生出折扣策略的接口和不同折扣策略实现类，这些折扣策略实现类可以算是DO，但它们只驻留在静态内存，不需要持久化到持久层，因此，这类DO是不存在对应的PO的。

同样的道理，某些场景下，PO也没有对应的DO，例如老师Teacher和学生Student存在多对多的关系，在关系数据库中，这种关系需要表现为一个中间表，也就对应有一个TeacherAndStudentPO的PO，但这个PO在业务领域没有任何现实的意义，它完全不能与任何DO对应上。这里要特别声明，并不是所有多对多关系都没有业务含义，这跟具体业务场景有关，例如：两个PO之间的关系会影响具体业务，并且这种关系存在多种类型，那么这种多对多关系也应该表现为一个DO，又如：“角色”与“资源”之间存在多对多关系，而这种关系很明显会表现为一个DO——“权限”。

某些情况下，为了某种持久化策略或者性能的考虑，一个PO可能对应多个DO，反之亦然。例如客户Customer有其联系信息Contacts，这里是两个一对一关系的DO，但可能出于性能的考虑（极端情况，权作举例），为了减少数据库的连接查询操作，把Customer和Contacts两个DO数据合并到一张数据表中。反过来，如果一本图书Book，有一个属性是封面cover，但该属性是一副图片的二进制数据，而某些查询操作不希望把cover一并加载，从而减轻磁盘IO开销，同时假设ORM框架不支持属性级别的延迟加载，那么就需要考虑把cover独立到一张数据表中去，这样就形成一个DO对应对个PO的情况。

PO的某些属性值对于DO没有任何意义，这些属性值可能是为了解决某些持久化策略而存在的数据，例如为了实现“乐观锁”，PO存在一个version的属性，这个version对于DO来说是没有任何业务意义的，它不应该在DO中存在。同理，DO中也可能存在不需要持久化的属性。

DO与PO的应用

由于ORM框架的功能非常强大而大行其道，而且JavaEE也推出了JPA规范，现在的业务应用开发，基本上不需要区分DO与PO，PO完全可以通过JPA，Hibernate Annotations/hbm隐藏在DO之中。虽然如此，但有些问题我们还必须注意：

对于DO中不需要持久化的属性，需要通过ORM显式的声明，如：在JPA中，可以利用@Transient声明。

对于PO中为了某种持久化策略而存在的属性，例如version，由于DO、PO合并了，必须在DO中声明，但由于这个属性对DO是没有任何业务意义的，需要让该属性对外隐藏起来，最常见的做法是把该属性的get/set方法私有化，甚至不提供get/set方法，但对于Hibernate来说，这需要特别注意，由于Hibernate从数据库读取数据转换为DO时，是利用反射机制先调用DO的空参数构造函数构造DO实例，然后再利用JavaBean的规范反射出set方法来为每个属性设值，如果不显式声明set方法，或把set方法设置为private，都会导致Hibernate无法初始化DO，从而出现运行时异常，可行的做法是把属性的set方法设置为protected。

对于一个DO对应多个PO，或者一个PO对应多个DO的场景，以及属性级别的延迟加载，Hibernate都提供了很好的支持，请参考Hibnate的相关资料。

在 Servlet API 中有一个 ServletContextListener 接口，它能够监听 ServletContext 对象的生命周期，实际上就是监听 Web 应用的生命周期。

当Servlet 容器启动或终止Web 应用时，会触发ServletContextEvent 事件，该事件由 ServletContextListener 来处理。在 ServletContextListener 接口中定义了处理ServletContextEvent 事件的两个方法。

1. contextInitialized(ServletContextEvent sce) ：当Servlet 容器启动Web 应用时调用该方法。在调用完该方法之后，容器再对Filter 初始化，并且对那些在Web 应用启动时就需要被初始化的Servlet 进行初始化。

内置对象特点:

1. 由JSP规范提供,不用编写者实例化。
2. 通过Web容器实现和管理
3. 所有JSP页面均可使用
4. 只有在脚本元素的表达式或代码段中才可使用(<%=使用内置对象%>或<%使用内置对象%>)

常用内置对象:

1. 输出输入对象:request对象、response对象、out对象
2. 通信控制对象:pageContext对象、session对象、application对象
3. Servlet对象:page对象、config对象
4. 错误处理对象:exception对象

out对象(数据流 javax.servlet.jsp.jspWriter)

request对象(请求信息 javax.servlet.http.HttpServletrequest)

response对象(响应 javax.servlet.http.HttpServletResponse)

session对象(会话 javax.servlet.http.HttpSession)

pageContext对象(页面上下文 javax.servlet.jsp.PageContext)

application对象(应用程序 javax.servlet.ServletContext)

config对象(Servlet的配置信息 javax.servlet.ServletConfig)

page对象(当前JSP的实例,java.lang.object)

它代表JSP被编译成Servlet,可以使用它来调用Servlet类中所定义的方法

exception对象(运行时的异常,java.lang.Throwable)

被调用的错误页面的结果,只有在错误页面中才可使用,即在页面指令中设置:<%@page isErrorPage=“true”%>  

• Request(Javax.servlet.ServletRequest)它包含了有关浏览器请求的信息.通过该对象可以获得请求中的头信息、Cookie和请求参数。
• Response(Javax.servlet.ServletResponse)作为JSP页面处理结果返回给用户的响应存储在该对象中。并提供了设置响应内容、响应头以及重定向的方法(如cookies,头信息等)
• Out(Javax.servlet.jsp.JspWriter)用于将内容写入JSP页面实例的输出流中,提供了几个方法使你能用于向浏览器回送输出结果。
• pageContext(Javax.servlet.jsp.PageContext)描述了当前JSP页面的运行环境。可以返回JSP页面的其他隐式对象及其属性的访问,另外,它还实现将控制权从当前页面传输至其他页面的方法。
• Session(javax.servlet.http.HttpSession)会话对象存储有关此会话的信息,也可以将属性赋给一个会话,每个属性都有名称和值。会话对象主要用于存储和检索属性值。
• Application(javax.servle.ServletContext)存储了运行JSP页面的servlet以及在同一应用程序中的任何Web组件的上下文信息。
• Page(Java.lang.Object)表示当前JSP页面的servlet实例
• Config(javax.servlet.ServletConfig)该对象用于存取servlet实例的初始化参数。
• Exception(Javax.lang.Throwable)在某个页面抛出异常时,将转发至JSP错误页面,提供此对象是为了在JSP中处理错误。只有在错误页面中才可使用<%@page isErrorPage=“true”%>

1. JAVA源文件的命名：JAVA源文件名必须和源文件中所定义的类的类名相同。

2. Package的命名：Package名的第一部分应是小写ASCII字符，并且是顶级域名之一，通常是com、edu、gov、mil、net、org或由ISO标准3166、1981定义的国家唯一标志码。Package名的后续部分由各组织内部命名规则决定，内部命名规则指定了各组件的目录名，所属部门名、项目名等。它们全都是 小写字母。

3. Class/Interface的命名：Class名应是首字母大写，通常以 名词 结尾。命名时应该使其简洁而又具有描述性。而且在类名中要体现它是以保存数据为主还是提供功能为主。例如 ConnectionBuilder 这个类我们都可以猜到它的主要功能是创建 Connection 对象。异常类的命名，应以Exception结尾。Interface的命名规则与Class相同。

• Interface：采用完整的英文描述符说明接口封装，所有单词的第一个字母大写。习惯上，名字后面加上后缀 able， ible 或者 er。例如：Contactable，Prompter。

• Component：使用完整的英文描述来说明组件的用途，末端应接上组件类型。例如：okButton，customerList，fileMenu。

• 以动词-er/or 结尾的类名，至少应该包含一个以该动词开头的方法。例如 ConnectionBuilder 这个类，它至少应该包含一个以 build- 开头的方法。有了这种默契，别人就能更方便的使用这个类。

4. 常量的命名：常量名的字母应全部大写，不同的单词之间通过 下划线 进行连接，并且名字组合应该赋予含义。

5. 变量的命名

• 普通变量：普通变量名的首字母小写，其它每个单词的首字母大写。命名时应该使其简短而又有特定含义，简洁明了的向使用者展示其使用意图。

• 约定变量：所谓约定变量，是指那些使用后即可抛弃（throwaway）的临时变量。通常i、j、k、m和n代表整型变量；c、d和e代表字符型变量。

6. 方法的命名：方法名的第一个单词应是 动词，并且首字母小写，其它每个单词首字母大写。

• 类的获取方法（一般具有返回值）：一般要求被方法名使用被访问字段名，前面加上前缀get，例如getFirstName(), getLastName()。

• 类的布尔型的判断方法：一般要求方法名使用单词 is 做前缀，如isPersistent(),isString()。或者使用具有逻辑意义的单词，例如equal 或equals。

  • 检查某个属性是否为空或者某条记录是否存在的方法，通常命名为 hasXXX()，例如 hasResult()。
  • 检查对象状态的方法通常以 is+形容词 命名。例如 isClosed()，isReady()

• 类的设置方法（一般返回类型为void）：被访问字段名的前面加上前缀 set，例如setFirstName(),setLastName()，setWarpSpeed()

• 类的普通方法：一般采用完整的英文描述说明成员方法功能，第一个单词尽可能采用一个生动的 动词，第一个字母小写，例如 openFile(), addAccount()。

• 增删改查方法的命名：

  以对 Person 类的增删改查为例：

  • 创建一个 Person对象的方法一般命名为 createPerson()/newPerson()，
  • 添加方法命名为 addPerson()，修改方法命名为 updatePerson()，
  • 删除方法命名为 deletePerson()/removePerson()，
  • 根据主键查询的方法命名为 getPerson()/queryPerson()。
  • 根据其他条件来查询，要指出具体的条件类型，例如 getPersonByName() 或 getPersonByAge()。

  方法的名称要统一。例如一开始用的是 deleteXXX 而不是 removeXXX，那么整个项目都应该这样用下去。

• 计数方法：通常命名为 getNumberOfXXX()/getXXXCount()。例如 getNumberOfRows()，getQuestionCount()。

7. 方法参数的命名：应该选择有意义的名称作为方法的参数名。如果可能的话，选择和需要赋值的字段一样的名字。

1. get是从服务器上获取数据，post是向服务器传送数据。
2. get是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单内各个字段一一对应，在URL中可以看到。post是通过HTTP post机制，将表单内各个字段与其内容放置在HTML HEADER内一起传送到ACTION属性所指的URL地址。用户看不到这个过程。
3. 对于get方式，服务器端用Request.QueryString获取变量的值，对于post方式，服务器端用Request.Form获取提交的数据。
4. get传送的数据量较小，不能大于2KB。post传送的数据量较大，一般被默认为不受限制。但理论上，IIS4中最大量为80KB，IIS5中为100KB。
5. get安全性非常低，post安全性较高。但是执行效率却比Post方法好。

建议：

1. get方式的安全性较Post方式要差些，包含机密信息的话，建议用Post数据提交方式；
2. 在做数据查询时，建议用Get方式；而在做数据添加、修改或删除时，建议用Post方式；

转自：http://www.cnblogs.com/cuiliang/archive/2011/10/21/2220671.html

Servlet生命周期

Servlet生命周期分为三个阶段：

1. 初始化阶段 调用init()方法
2. 响应客户请求阶段　　调用service()方法
3. 终止阶段　　调用destroy()方法

Servlet初始化阶段：

在下列时刻Servlet容器装载Servlet：

1. Servlet容器启动时自动装载某些Servlet，实现它只需要在web.XML文件中的之间添加如下代码：`1``
2. 在Servlet容器启动后，客户首次向Servlet发送请求
3. Servlet类文件被更新后，重新装载Servlet

Servlet被装载后，Servlet容器创建一个Servlet实例并且调用Servlet的init()方法进行初始化。在Servlet的整个生命周期内，init()方法只被调用一次。

Servlet工作原理：

首先简单解释一下Servlet接收和响应客户请求的过程，首先客户发送一个请求，Servlet是调用service()方法对请求进行响应的，通过源代码可见，service()方法中对请求的方式进行了匹配，选择调用doGet,doPost等这些方法，然后再进入对应的方法中调用逻辑层的方法，实现对客户的响应。在Servlet接口和GenericServlet中是没有doGet,doPost等等这些方法的，HttpServlet中定义了这些方法，但是都是返回error信息，所以，我们每次定义一个Servlet的时候，都必须实现doGet或doPost等这些方法。

每一个自定义的Servlet都必须实现Servlet的接口，Servlet接口中定义了五个方法，其中比较重要的三个方法涉及到Servlet的生命周期，分别是上文提到的init(),service(),destroy()方法。GenericServlet是一个通用的，不特定于任何协议的Servlet,它实现了Servlet接口。而HttpServlet继承于GenericServlet，因此HttpServlet也实现了Servlet接口。所以我们定义Servlet的时候只需要继承HttpServlet即可。

Servlet接口和GenericServlet是不特定于任何协议的，而HttpServlet是特定于HTTP协议的类，所以HttpServlet中实现了service()方法，并将请求ServletRequest,ServletResponse强转为HttpRequest和HttpResponse。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public void service(ServletRequest req,ServletResponse res) throws ServletException,IOException
{
  HttpRequest request;
  HttpResponse response;

  try
  {
     req = (HttpRequest)request;
     res = (HttpResponse)response;
  }catch(ClassCastException e)
  {
     throw new ServletException("non-HTTP request response");
  }
  service(request,response);
}

代码的最后调用了HTTPServlet自己的service(request,response)方法，然后根据请求去调用对应的doXXX方法，因为HttpServlet中的doXXX方法都是返回错误信息，

1
2
3
4
5
6
7
8
9
10
11
12
13

protected void doGet(HttpServletRequest res,HttpServletResponse resp) throws ServletException,IOException
{
  String protocol = req.getProtocol();
  String msg = IStrings.getString("http.method_get_not_supported");
  if(protocol.equals("1.1"))
  {
    resp.sendError(HttpServletResponse.SC.METHOD.NOT.ALLOWED,msg);
  }
  esle
  {
    resp.sendError(HttpServletResponse.SC_BAD_REQUEST,msg);
  }
}

所以需要我们在自定义的Servlet中override这些方法！

　　　　源码面前，了无秘密！

Servlet响应请求阶段：

对于用户到达Servlet的请求，Servlet容器会创建特定于这个请求的ServletRequest对象和ServletResponse对象，然后调用Servlet的service方法。service方法从ServletRequest对象获得客户请求信息，处理该请求，并通过ServletResponse对象向客户返回响应信息。

对于Tomcat来说，它会将传递过来的参数放在一个Hashtable中，该Hashtable的定义是：

1

private Hashtable<String String[]> paramHashStringArray = new Hashtable<String String[]>();

这是一个String–>String[]的键值映射。

HashMap线程不安全的，Hashtable线程安全。

Servlet终止阶段：

当WEB应用被终止，或Servlet容器终止运行，或Servlet容器重新装载Servlet新实例时，Servlet容器会先调用Servlet的destroy()方法，在destroy()方法中可以释放掉Servlet所占用的资源。

Servlet何时被创建：

1. 默认情况下，当WEB客户第一次请求访问某个Servlet的时候，WEB容器将创建这个Servlet的实例。
2. 当web.xml文件中如果<servlet>元素中指定了<load-on-startup>子元素时，Servlet容器在启动web服务器时，将按照顺序创建并初始化Servlet对象。

注意：在web.xml文件中，某些Servlet只有<serlvet>元素，没有<servlet-mapping>元素，这样我们无法通过url的方式访问这些Servlet，这种Servlet通常会在<servlet>元素中配置一个<load-on-startup>子元素，让容器在启动的时候自动加载这些Servlet并调用init()方法，完成一些全局性的初始化工作。

Web应用何时被启动：

1. 当Servlet容器启动的时候，所有的Web应用都会被启动
2. 控制器启动web应用

Servlet与JSP的比较：

有许多相似之处，都可以生成动态网页。

• JSP的优点是擅长于网页制作，生成动态页面比较直观，缺点是不容易跟踪与排错。
• Servlet是纯Java语言，擅长于处理流程和业务逻辑，缺点是生成动态网页不直观。

1. Listener的定义与作用

　　监听器Listener就是在application,session,request三个对象创建、销毁或者往其中添加修改删除属性时自动执行代码的功能组件。

　　Listener是Servlet的监听器，可以监听客户端的请求，服务端的操作等。

2. Listener的分类与使用

Filter简介

Filter也称之为过滤器，它是Servlet技术中最实用的技术，WEB开发人员通过Filter技术，对web服务器管理的所有web资源：例如Jsp, Servlet, 静态图片文件或静态 html 文件等进行拦截，从而实现一些特殊的功能。例如实现URL级别的权限访问控制、过滤敏感词汇、压缩响应信息等一些高级功能。