项目中采用J2EE体系架构分析 - zs4916548的专栏
- 博客频道 - CSDN.NET
1078人阅读
     从刚开始知道Java的时候，是从Applet开始的，看到它在客户端作出了很在丰富的动态效果，觉得它是我使用JS之外的另一种选择，觉得很新奇，但是没有投入太多精力去研究它，也以为Java语言的本事也就是如此，后来形式的发展，证明我错了，当我第一次看到J2EE规范的时候，很震惊，原来Java语言也可以进行服务器端企业级开发，情不自尽的投入到对它的专研中，用它作过很多企业级项目，从当初的糟蒙无知到现在的渐入佳境，再回首时，除了感到的在技术上的获得的欣慰时，也感觉到很多遗憾，
    其中之一的遗憾是在很多企业级项目中设计时，由于对需求分析的不足，还有主观上的对技术时髦的不切实际的追求，造成了很多失误的地方，有的“小脚穿大鞋”，项目需求不是很复杂，但被那些新技术的宣传所迷惑，采用它们来开发，结果大多数，既浪费了时间，又浪费了金钱，后期很难维护，客户也有一种被忽悠的感觉。有的“大脚穿小鞋”，低估了项目设计实施的复杂性，以盲目乐观的态度投入开放，开放的过程中，感觉到项目在结构上设计的不合理之处，但那时也晚了，只能硬着头皮，采用添油战术，结果开发出来的项目不但超出工时也超出预算，整的客户和程序员都怨声载道。得不偿失。这些遗憾的产生，都是没有处理好项目需求和J2EE开发模式选择上的关系，没有把握其中的原则：“J2EE开发模式的选择要根据实际项目的需要，技术以项目需求为中心”，采用什么J2EE开发模式本身对项目而言没有优劣之分，区分的只是合试还是不合试。
   下面就结合实际的项目来谈一下J2EE各种开发模式的选择，既讲优点，也讲缺点，让开发设计者根据实际的项目需求选择合适的J2EE开发模式。
     首先对什么是J2EE作一下简单回顾.J2EE就是Java2的企业版，是SUN公司为了开发安全、可靠、可扩展、高效可用的企业级应用系统所开发的一套技术规范，它定义了开发企业级应用的各种服务，而实现这些服务的平台，叫J2EE开发平台，一般由第三方厂商提供，开发厂商同时也要提供应用并且开发能够部署和运行J2EE兼容的应用程序的服务器，我们叫应用级服务器，如Weblogic、WebSphere、JBoss等
二、J2EE体系结构
J2EE体系结构主要分三层：client、Business、EIS 3个主要层 
Client层：即用户的使用界面，它负责与Business层通信，客户端最常用的是Web浏览器，也可以是Java语言或者其他语言（C#,dephi）编
                   写的传统的UI层
  Bussiness层：即逻辑处理层，主要由J2EE应用服务器组成，里面包含Web容器和EJB
Web容器处理表示层逻辑，响应客户端的请求，和EJB容器通信，来构建用户界  面。主要技术有：Servlet和JSP和HTML
EJB容器负责处理业务逻辑，与EIS层的数据源通信，完成数据的存储，主要技术有：EJB(Session Bean Entity Bean Message driver Bean) 其他
                技术，JTA，JMS，JDBC，JNDI
  EIS企业信息系统层 ：
   由J2EE完成业务逻辑所必须访问的企业资源所组成，所以称作数据源，这些资源主要包括 数据库管理系统(DBMS)，文件数据、邮件服务和企业原有遗留下的应用资源等等，虽然EIS不受J2EE服务器的控制，但是J2EE提供了强有力的访问 EIS层的接口，
比如JDBC，JNDI,连接其他EIS的JCA。J2EE应用服务负责建立访问EIS资源的连接池事务管理以及保证J2EE应用不会危及EIS系统的安全等等。
J2EE体系结构可分为非分布式和分布式两大体系结构
一、非分布式体系结构
非分布式体系结构比较适合于Web应用，它们在一个容器处理所有
的页面逻辑和业务逻辑，所有的应用组件都只运行在同一个JVM里面，
这样系统将变得简单而有效
1.数据库构建业务逻辑的Web应用
简介：在这个开发模式中，企业的业务逻辑主要在数据库服务器端， 通过使用存储过程，触发器等数据库所特有的技术来完成，Web容
            器 利用JDBC调用数据库的存储过程获取数据，利用Servlet，JSP,HTML 等处理表示层的逻辑
(1)简单性，结构简单清晰，页面只需要显示数据，代码简单，业务主要交给数据库来
管理，如果对某个数据库语言熟悉的 话，比采用其他的模式开发周期
(2)速度：由于业务逻辑在数据库服务器端计算，Web容器只是负责显示数据，系统开销很小，速度响应很快
(3)测试容易：业务逻辑用数据库存储过程编写，容易开发和调试，无须Web层，就可以对业务接口进行测试。
(4)系统部署简单，Web容器只有表示层逻辑，很容易按要求来部署。
(1)整个应用对数据库的功能和容量要求高，需要支持存储过程，触发器等技术，数 据库配置要求大，适合Oracle，SQLServer,DB2和Sybase等大型商用数据库，而对于某些不支持存储过程的数据库，如Mysql3.*，根本就不能这种开发模式。
(2)维护不易：业务用数据库特有技术实现，表示层用Java实现对开发人员的技术要 求很高维护两套不同的技术（因为数据库是面向过程的）实现是很不容易的。
(3)数据库的程序代码可能会很复杂，由于一般数据库编程语言都不是面向对象的，而是过程化的语言，而且，一般存储过程在重用的时候，（如：在一个存储过程中调用另外一个存储过程），数据的一致性和完整性就没有保证，容易出现并发同步的问题，当然，有些数据库编程语言支持面向对象，比如：Oracle8i以的的版本支持Java，可以用Java语言编写存储过程等，给我们多提供了一个选择。
(4)系统扩展性差，数据库性能要求高，性能调整代价大，在这个开发模式中，数据库不单单负责存储数据，而且还负责处理大量的业务                                   逻辑，这样对数据库性能会急速下降，业务逻辑不能从数据库抽离出来，自由部署，系统变得很难扩展，这
时候就只能考虑增加系统的物理的硬件或使用数据库系统集群解决方案 了，代价大。
我在以前开发的很多项目都是用的这种开发模式，可能这种模式现在让很多的技术经理不屑一顾，认为这根本就不属于J2EE开发，没有技术含量可言，但是我认为早期传统行业，如银行、证券、电信、保险等，应用这种模式开发的系统比比皆是。这种模式的优点和缺点在上面已经讨论过了，由于它用了J2EE的JDBC、Servlet、JSP等技术，所以依然认为这是属于J2EE开发的范畴。在很多时候，这种模式是快速而高效的，不能因为“纯”技术的原因而否定。技术应以项目为中心，根据其需求和容量等特点来决定应用什么样的开发模式，而不是反其道而行之。
2.处理业务逻辑组件的Web应用
    在这个开发模式中，Web容器不仅负责表示层，还要处理业务逻辑，利用变通的Java Bean调用J2EE提供各种服务的API 来访问企业数据源，完成各种业务逻辑的开发，虽然整个应用的Web表示层和中间业务层都运行同一个JVM中，但是，设计开发中在逻辑上使两层保持分离是很重要的，尽量不要在表示层的UI组件与中间层的业务组件之间的责任归属问题上模糊不清。这也是构建一个简单，可缩放的系统基础，
1.结构简单。开发模式一目了然，不需要EJB容器的支持的J2EE应用服务器（如Tomca
t,Resin）就可以很好的完成工作，但是代码开发不一定就变得简单，如
果事务管理和线程化问题要求高的话，代码就会变得很复杂，这时候,使用
EJB反而更简单。
2.响应速度快。整个应用运行在同一个JVM内，没有远程调用，系统开销小，速度快。
3.调试和测试容易，没有使用EJB容器，代码本地化，无须部署就可调试，同时，如果
设 计合理的话，不需要Web接口就很容易进行业务组件的调试和测试。
4.系统部署容易灵活，整个应用在同一个JVM中，部署在一台物理机器上，当系统用户
量增大的时候，也很容易利用Web应用服务器的负载均衡技术，在多台物理
机器上布署同一个应用满足系统容量扩大的需求。
1.对外只有一个Web接口，除非增加一个Web Service，否则很难支持其他独立的GUI
    客户端
2.因为整个应用只能运行在一个JVM,虽然提高了组件之间的访问性能，但是当一台物
    理的JVM不能满足并发访问的时候，我们无法将这些组件自由的部署到其他物理机
3由于该开发模式没有应用到EJB容器的事务支持，我们需要自己在代码里创建和管理
    事务，增加了开发难度，
4。应用服务器不支持EJB容器，意味着丢失了EJB容器带来的各种方便好用的服务，
对于开发复杂的企业应用往往显得力不从心，对项目的工发速度也存在影响。
5.由于中间层不能剥离出来，部署在内部网络中，这样对业务层数据
安全要求高的应用，就不是很适合了，入侵了Web 层就等于入侵
了中间业务层，因为它们绑定在同一JVM中。
这也可能是J2EE中最常用，结构最简单的开发模式了，也就是现在很多人推崇的所谓“轻量级”企业的开发模式了，现在所流行的SSH(Struts+Spring+Hibernate)框架组合的开发模式，应用很广泛，网上很多著名的开源软件都是这个模式开发的，比如Jlive论坛、OpenCMS等等，我认为，对于系统投资和容量都不大，系统部署和安全性要求都不高的企业应用，使用这个模式还是比较适合的。
3.使用本地接口EJB的Web应用
    在这个开发模式中，也分为Web层和中间业务层基本上和上面讨论的“具有处理业务逻辑组件的Web应用”相同，而与其不同之处在于：本模式的中间业务层的业务接口使用本地EJB实现，而不是采用普通JavaBean与地，与远程调用EJB不同，本地EJB无须暴露一个远程接口，而仅仅是业务实现的一个选择罢了，这样既能利用EJB容器现在的各种服务，而又不至于代码复杂化或者把应用变成了分布式。
1,基本上具备了“具有处理业务逻辑组件的Web应用”模式的所有优点。
2.充分利用了EJB容器的各种服务，而又没有分布式EJB那样复杂。
3.本地EJB的使用只是业务接口实现一个选择，不会引起基本设计的更改。
4.本地EJB不用远程调用，不需要串行化，系统性能开销相当小。
1.开发相对复杂
2.对外也只是一个Web接口，很难支持其他客户端，除非多加一层Web Service。
3.整个应用运行在同一个JVM,所有组件必须部署在同一台物理机器上，同样，如果
业务层数据安全高的应用，就不适合该模式了。
4.调试不容易，本地EJB调试需要运行J2EE应用服务器
5.值得注意的是，即使本地调用，仍然慢于普通方法调用。
这个开发模式，可以看作是在非分布式开发中“具有处理业务逻辑组件的Web应用”模式和使用EJB容器的一个有效的折中模式，这个模式最吸引人的地方是可以利用EJB容器的事务与线程管理带来的各种好处，如果我们采用WebLogic、Websphere、或JBoss等高效EJB应用服务器的话，没有理由不优先考虑采取该模式的
二、分布式体系结构
J2EE多层系统结构，可以说天生是为了企业多层分布式应用的，
使用远程EJB的分布式应用
   在该开发模式中，通过EJB及其调用EJB组件（如Web组件和客户机组件）部署在不同的JVM的方式对应用进行物理的以及逻辑的划分，实现分布式。Web容器和EJB容器各自独立运行在不同JVM,Web容器通过RMI调用EJB远程接口业务方法获取业务数据来实现表示层的逻辑，当然其他客户端也可以直接调用EJB容器的远程接口进行交互，如果系统需要的话，甚至EJB容器的业务逻辑层和数据访问存储层都可以物理分开，运行在不同的JVM,通过RMI通信，可以说这个开模式在开发分布式应用方面很灵活，所以经常被看做J2EE体系结构中经典的开发的模式。
1.它是分布式系统经典开发模式，可以很容易使用J2EE应用服务器的各种现成的服
    务，减低开发分布式系统的难度。
2.可以通过标准的RMI远程接口来支持所有的J2EE客户类型。
3.提供了最为灵活的部署方式，它允许应用组件在不同物理机器上的部署，合理使用
    无状态的SessionBean，会给J2EE应用带来极大的可缩放性，
1.复杂，开发难度。这种难度不光表现在技术上，而且很多时候反映在业务逻辑和表
     示逻辑的合理划分和设计上。
2.影响性能。因为使用了RMI远程调用，而远程调用往往会比本地调用慢许多倍。每
    网络传输对象必须序列化，而太多的序列化也是影响性能的一个重要因素。
3.所有业务层组件必须运行EJB容器内，对J2EE应用服务器要求高
4.分布式应用的调试和测试都是最难的。
5.分布式系统使系统异常的处理变得复杂
6.还必须考虑网络故障引起的传输故障问题。
我罗列了这个模式的不少缺点，但并不是说我就否定了个模式，远程接口带来的性能问题、也没有想像中那么严重、其性能影响大小取决于远程调用的数量、而这些我们可以通过合理的设计把调用次数减到最低，同时，如果把远程EJB和调用EJB组件放在一起，大多数J2EE应用服务器会进行优化，把远程调用替代为本地调用，还有，随着服务器物理硬件的性能提升和网络速度的提高（基本都是100M以上），这种远程调用基本上都是毫秒级的，故此，如果你的应用有明确的分布式要求的话，可以使用本模式来开发，但同是也要注意，不要因为你的应用使用了有远程的EJB,就把整个应用变成分布式的。
2.具有Web Service接口的分布式应用
这个分布式应用模式可以看作是上述非分布式开发体系结构中各种开发模式为了实现分布式开发的一个扩展模式。它在原有的各种模式上增加了一个Web Service服务层，它不需要RMI和EJB来支持远程客户，而是采取Web Service标准技术来实现分布式应用，任何支持Web Service技术的客户端都可以通过标准的协议（SOAP）与中间业务服务器通信，在J2EE开发分布式应用中，提供了不使用EJB远程接口的另一种选择。
1.Web Service是标准技术，通信协议SOAP比RMI//IIOP更开放，可以支持Java外其他语
  言的客户端
2.对企业来说，提供标准的Web服务接口比提供远程EJB接口更有好处。
3.Web Service基于http协议，与RMI相比，防火墙更友好。
1.性能差，通过SOAP和XML协议传递对象的性能比RMI传递对象的性能更差。
2.如果所有客户端都是基于J2EE客户端都是基于J2EE技术，那么就没有必要采取这样一
  个技术来实现分布式。
3.传输对象编码复杂，可能需要在Java对象与XML之间转换，对复杂的Java对象支持效
把一个EJB转化成一个Web Service是很容易的一件事情
我回顾了J2EE体系结构，并讨论了J2EE体系结构下非分布式和分布式开发的种种开发模式，但这些开发模式不是独立的，而是我根据经验划分的往往一个具体的J2EE项目都是一种或几种开发模式的组合。与非分布式结构相比，分布式结构更加复杂，更难实现、测试和维护，如果设计不合理的话，分布式的性能往往令人失望，不过，分布式应用在某些情况下会很坚固可靠，更具体可缩放性，而分布式也可能是实现某些业务需要的唯一方法。故此，还是那句话，技术以项目为本，决定是否使用分布式结构开发，要根据项目的具体要求决定，如果项目没有分布式业务的需求，最好避免使用分布式结构，除非它真的给项目带来真正的好处。
   值得一提的是，很多开发人员认为“J2EE=EJB”认为J2EE应用服务器已经处理了复杂的事务管理，数据存取和线程问题，并提供数据缓存功能，其J2EE“设计模式”是得到公认的方法、因而无须太多地关心效率的问题=这种把EJB当成万能药的偏激思想，是危险而盲目的，是又落入一个“纯”技术陷阱，这观点将导致一个幼稚而低劣的设计，总体而言，EJB是一项复杂的技术，能很好的解决问题，但是很多时候也给应用增加了比实用价值更大的复杂性，它具有双面性，不加思考滥用必将是灾难，合理使用才会产生良好的效果，同时让应用具备灵活的缩放性。
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：6053次
排名：千里之外
原创：15篇Spring MVC 教程,快速入门,深入分析 - 赵磊的博客 - ITeye技术网站
博客分类：
资源下载：
作者：赵磊
二、spring mvc 核心类与接口
三、spring mvc 核心流程图
四、spring mvc DispatcherServlet说明
五、spring mvc 父子上下文的说明
六、springMVC-mvc.xml 配置文件片段讲解
七、spring mvc 如何访问到静态的文件，如jpg,js,css
八、spring mvc 请求如何映射到具体的Action中的方法
spring mvc 中的拦截器：
spring mvc 如何使用拦截器
spring mvc 如何实现全局的异常处理
spring mvc 如何把全局异常记录到日志中
如何给spring3 MVC中的Action做JUnit单元测试
spring mvc 转发与重定向 （带参数重定向）
spring mvc 处理ajax请求
spring mvc 关于写几个配置文件的说明
spring mvc 如何取得Spring管理的bean
spring mvc 多视图控制器
十九、 &mvc:annotation-driven /& 到底做了什么工作
二十、 本文中springMVC.xml配置文件是核心，这里给一个下载地址
说明：本作者是文章的原创作者，转载请注明出处：本文地址：
一、前言：
为开发团队选择一款优秀的MVC框架是件难事儿，在众多可行的方案中决择需要很高的经验和水平。你的一个决定会影响团队未来的几年。要考虑方面太多：
1、简单易用，以提高开发效率。使小部分的精力在框架上，大部分的精力放在业务上。
2、性能优秀，这是一个最能吸引眼球的话题。
3、尽量使用大众的框架（避免使用小众的、私有的框架），新招聘来的开发人员有一些这方面技术积累，减低人员流动再适应的影响。
如果你还在为这件事件发愁，本文最适合你了。选择Spring MVC吧。
Spring MVC是当前最优秀的MVC框架，自从Spring 2.5版本发布后，由于支持注解配置，易用性有了大幅度的提高。Spring 3.0更加完善，实现了对Struts 2的超越。现在越来越多的开发团队选择了Spring MVC。
Struts2也是非常优秀的MVC构架，优点非常多比如良好的结构，拦截器的思想，丰富的功能。但这里想说的是缺点，Struts2由于采用了值栈、OGNL表达式、struts2标签库等，会导致应用的性能下降，应避免使用这些功能。而Struts2的多层拦截器、多实例action性能都很好。可以参考我写的一篇关于Spring MVC与Struts2与Servlet比较的文章
Spring3 MVC的优点：
1、Spring3 MVC使用简单，学习成本低。学习难度小于Struts2，Struts2用不上的多余功能太多。呵呵，当然这不是决定因素。
2、Spring3 MVC很容易就可以写出性能优秀的程序，Struts2要处处小心才可以写出性能优秀的程序（指MVC部分）
3、Spring3 MVC的灵活是你无法想像的，Spring框架的扩展性有口皆碑，Spring3 MVC当然也不会落后，不会因使用了MVC框架而感到有任何的限制。
Struts2的众多优点：
1、老牌的知名框架，从Struts1起积累了大量用户群体。技术文档丰富。
2、其它方面略...
(呵呵，是不是不公平？)
Spring的官方下载网址是：
（本文使用是的Spring 3.0.5版本）
转载请注明出处：原文地址：
二、核心类与接口：
先来了解一下，几个重要的接口与类。现在不知道他们是干什么的没关系，先混个脸熟，为以后认识他们打个基础。
DispatcherServlet
-- 前置控制器
HandlerMapping接口 -- 处理请求的映射
HandlerMapping接口的实现类：
SimpleUrlHandlerMapping
通过配置文件，把一个URL映射到Controller
DefaultAnnotationHandlerMapping
通过注解，把一个URL映射到Controller类上
HandlerAdapter接口 -- 处理请求的映射
AnnotationMethodHandlerAdapter类，通过注解，把一个URL映射到Controller类的方法上
Controller接口 -- 控制器
由于我们使用了@Controller注解，添加了@Controller注解注解的类就可以担任控制器（Action）的职责,
所以我们并没有用到这个接口。
HandlerInterceptor 接口--拦截器
无图，我们自己实现这个接口，来完成拦截的器的工作。
ViewResolver接口的实现类
UrlBasedViewResolver类 通过配置文件，把一个视图名交给到一个View来处理
InternalResourceViewResolver类，比上面的类，加入了JSTL的支持
JstlView类
LocalResolver接口
HandlerExceptionResolver接口 --异常处理
SimpleMappingExceptionResolver实现类
ModelAndView类
三、核心流程图
本图是我个人画的，有不严谨的地方，大家对付看吧。总比没的看强。
转载请注明出处：本文地址：
四、DispatcherServlet说明
使用Spring MVC,配置DispatcherServlet是第一步。
DispatcherServlet是一个Servlet,所以可以配置多个DispatcherServlet。
DispatcherServlet是前置控制器，配置在web.xml文件中的。拦截匹配的请求，Servlet拦截匹配规则要自已定义，把拦截下来的请求，依据某某规则分发到目标Controller(我们写的Action)来处理。
“某某规则”：是根据你使用了哪个HandlerMapping接口的实现类的不同而不同。
先来看第一个例子：
&servlet-name&example&/servlet-name&
&servlet-class&org.springframework.web.servlet.DispatcherServlet&/servlet-class&
&load-on-startup&1&/load-on-startup&
&/servlet&
&servlet-mapping&
&servlet-name&example&/servlet-name&
&url-pattern&*.form&/url-pattern&
&/servlet-mapping&
&/web-app&
&load-on-startup&1&/load-on-startup&是启动顺序，让这个Servlet随Servletp容器一起启动。
&url-pattern&*.form&/url-pattern& 会拦截*.form结尾的请求。
&servlet-name&example&/servlet-name&这个Servlet的名字是example，可以有多个DispatcherServlet，是通过名字来区分的。每一个DispatcherServlet有自己的WebApplicationContext上下文对象。同时保存的ServletContext中和Request对象中，关于key，以后说明。
在DispatcherServlet的初始化过程中，框架会在web应用的 WEB-INF文件夹下寻找名为[servlet-name]-servlet.xml 的配置文件，生成文件中定义的bean。
第二个例子：
&servlet-name&springMVC&/servlet-name&
&servlet-class&org.springframework.web.servlet.DispatcherServlet&/servlet-class&
&init-param&
&param-name&contextConfigLocation&/param-name&
&param-value&classpath*:/springMVC.xml&/param-value&
&/init-param&
&load-on-startup&1&/load-on-startup&
&/servlet&
&servlet-mapping&
&servlet-name&springMVC&/servlet-name&
&url-pattern&/&/url-pattern&
&/servlet-mapping&
指明了配置文件的文件名，不使用默认配置文件名，而使用springMVC.xml配置文件。
其中&param-value&**.xml&/param-value& 这里可以使用多种写法
1、不写,使用默认值:/WEB-INF/&servlet-name&-servlet.xml
2、&param-value&/WEB-INF/classes/springMVC.xml&/param-value&
3、&param-value&classpath*:springMVC-mvc.xml&/param-value&
4、多个值用逗号分隔
Servlet拦截匹配规则可以自已定义，拦截哪种URL合适？
当映射为@RequestMapping("/user/add")时，为例：
1、拦截*.do、*.htm， 例如：/user/add.do
这是最传统的方式，最简单也最实用。不会导致静态文件（jpg,js,css）被拦截。
2、拦截/，例如：/user/add
可以实现现在很流行的REST风格。很多互联网类型的应用很喜欢这种风格的URL。
弊端：会导致静态文件（jpg,js,css）被拦截后不能正常显示。想实现REST风格，事情就是麻烦一些。后面有解决办法还算简单。
3、拦截/*，这是一个错误的方式，请求可以走到Action中，但转到jsp时再次被拦截，不能访问到jsp。
转载请注明出处：本文地址：
五、父子上下文(WebApplicationContext)
如果你使用了listener监听器来加载配置，一般在Struts+Spring+Hibernate的项目中都是使用listener监听器的。如下
&listener&
&listener-class&org.springframework.web.context.ContextLoaderListener&/listener-class&
&/listener&
Spring会创建一个WebApplicationContext上下文，称为父上下文（父容器） ，保存在 ServletContext中，key是WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE的值。
可以使用Spring提供的工具类取出上下文对象：WebApplicationContextUtils.getWebApplicationContext(ServletContext);
DispatcherServlet是一个Servlet,可以同时配置多个，每个 DispatcherServlet有一个自己的上下文对象（WebApplicationContext），称为子上下文（子容器），子上下文可以访问父上下文中的内容，但父上下文不能访问子上下文中的内容。 它也保存在 ServletContext中，key是"org.springframework.web.servlet.FrameworkServlet.CONTEXT"+Servlet名称。当一个Request对象产生时，会把这个子上下文对象（WebApplicationContext）保存在Request对象中，key是DispatcherServlet.class.getName() + ".CONTEXT"。
可以使用工具类取出上下文对象：RequestContextUtils.getWebApplicationContext(request);
说明 ：Spring 并没有限制我们，必须使用父子上下文。我们可以自己决定如何使用。
方案一，传统型：
父上下文容器中保存数据源、服务层、DAO层、事务的Bean。
子上下文容器中保存Mvc相关的Action的Bean.
事务控制在服务层。
由于父上下文容器不能访问子上下文容器中内容，事务的Bean在父上下文容器中，无法访问子上下文容器中内容，就无法对子上下文容器中Action进行AOP（事务）。
当然，做为“传统型”方案，也没有必要这要做。
方案二，激进型：
Java世界的“面向接口编程”的思想是正确的，但在增删改查为主业务的系统里，Dao层接口，Dao层实现类，Service层接口，Service层实现类，Action父类，Action。再加上众多的O(vo\po\bo)和jsp页面。写一个小功能 7、8个类就写出来了。 开发者说我就是想接点私活儿，和PHP，ASP抢抢饭碗，但我又是Java程序员。最好的结果是大项目能做好，小项目能做快。所以“激进型”方案就出现了-----没有接口、没有Service层、还可以没有众多的O(vo\po\bo)。那没有Service层事务控制在哪一层？只好上升的Action层。
本文不想说这是不是正确的思想，我想说的是Spring不会限制你这样做。
由于有了父子上下文，你将无法实现这一目标。解决方案是只使用子上下文容器，不要父上下文容器
。所以数据源、服务层、DAO层、事务的Bean、Action的Bean都放在子上下文容器中。就可以实现了，事务（注解事务）就正常工作了。这样才够激进。
总结：不使用listener监听器来加载spring的配置文件，只使用DispatcherServlet来加载spring的配置，不要父子上下文，只使用一个DispatcherServlet，事情就简单了，什么麻烦事儿也没有了。
Java--大项目能做好--按传统方式做，规规矩矩的做，好扩展，好维护。
Java--小项目能做快--按激进方式做，一周时间就可以出一个版本，先上线接受市场(用户)的反馈，再改进，再反馈，时间就是生命(成本)。
转载请注明出处：原文地址：
六、springMVC-mvc.xml 配置文件片段讲解
（未使用默认配置文件名）
&?xml version="1.0" encoding="UTF-8"?&
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:mvc="http://www.springframework.org/schema/mvc"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-3.0.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://www.springframework.org/schema/mvc
http://www.springframework.org/schema/mvc/spring-mvc-3.0.xsd"&
&!-- 自动扫描的包名 --&
&context:component-scan base-package="com.app,com.core,JUnit4" &&/context:component-scan&
&!-- 默认的注解映射的支持 --&
&mvc:annotation-driven /&
&!-- 视图解释类 --&
&bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"&
&property name="prefix" value="/WEB-INF/jsp/"/&
&property name="suffix" value=".jsp"/&&!--可为空,方便实现自已的依据扩展名来选择视图解释类的逻辑
&property name="viewClass" value="org.springframework.web.servlet.view.JstlView" /&
&!-- 拦截器 --&
&mvc:interceptors&
&bean class="com.core.mvc.MyInteceptor" /&
&/mvc:interceptors&
&!-- 对静态资源文件的访问
方案一 （二选一） --&
&mvc:default-servlet-handler/&
&!-- 对静态资源文件的访问
方案二 （二选一）--&
&mvc:resources mapping="/images/**" location="/images/" cache-period=""/&
&mvc:resources mapping="/js/**" location="/js/" cache-period=""/&
&mvc:resources mapping="/css/**" location="/css/" cache-period=""/&
&context:component-scan/& 扫描指定的包中的类上的注解，常用的注解有：
@Controller 声明Action组件
声明Service组件
@Service("myMovieLister")
@Repository 声明Dao组件
@Component
泛指组件, 当不好归类时.
@RequestMapping("/menu")
用于注入，( j2ee提供的 ) 默认按名称装配，@Resource(name="beanName")
@Autowired 用于注入，(srping提供的) 默认按类型装配
@Transactional( rollbackFor={Exception.class}) 事务管理
@ResponseBody
@Scope("prototype")
设定bean的作用域
&mvc:annotation-driven /& 是一种简写形式，完全可以手动配置替代这种简写形式，简写形式可以让初学都快速应用默认配置方案。&mvc:annotation-driven /& 会自动注册DefaultAnnotationHandlerMapping与AnnotationMethodHandlerAdapter 两个bean,是spring MVC为@Controllers分发请求所必须的。
并提供了：数据绑定支持，@NumberFormatannotation支持，@DateTimeFormat支持，@Valid支持，读写XML的支持（JAXB），读写JSON的支持（Jackson）。
后面，我们处理响应ajax请求时，就使用到了对json的支持。
后面，对action写JUnit单元测试时，要从spring IOC容器中取DefaultAnnotationHandlerMapping与AnnotationMethodHandlerAdapter 两个bean，来完成测试，取的时候要知道是&mvc:annotation-driven /&这一句注册的这两个bean。
&mvc:annotation-driven /&？他到底做了什么工作，请看，最后面的 十九节
&mvc:annotation-driven /&
到底做了什么工作。
&mvc:interceptors/& 是一种简写形式。通过看前面的大图，知道，我们可以配置多个HandlerMapping。&mvc:interceptors/&会为每一个HandlerMapping，注入一个拦截器。其实我们也可以手动配置为每个HandlerMapping注入一个拦截器。
&mvc:default-servlet-handler/& 使用默认的Servlet来响应静态文件。
&mvc:resources mapping="/images/**" location="/images/" cache-period=""/& 匹配URL
/images/**
的URL被当做静态资源，由Spring读出到内存中再响应http。
转载请注明出处：本文地址：
七、如何访问到静态的文件，如jpg,js,css？
如何你的DispatcherServlet拦截"*.do"这样的有后缀的URL，就不存在访问不到静态资源的问题。
如果你的DispatcherServlet拦截"/"，为了实现REST风格，拦截了所有的请求，那么同时对*.js,*.jpg等静态文件的访问也就被拦截了。
我们要解决这个问题。
目的：可以正常访问静态文件，不可以找不到静态文件报404。
方案一：激活Tomcat的defaultServlet来处理静态文件
&servlet-mapping&
&servlet-name&default&/servlet-name&
&url-pattern&*.jpg&/url-pattern&
&/servlet-mapping&
&servlet-mapping&
&servlet-name&default&/servlet-name&
&url-pattern&*.js&/url-pattern&
&/servlet-mapping&
&servlet-mapping&
&servlet-name&default&/servlet-name&
&url-pattern&*.css&/url-pattern&
&/servlet-mapping&
要配置多个，每种文件配置一个
要写在DispatcherServlet的前面， 让
defaultServlet先拦截请求，这样请求就不会进入Spring了，我想性能是最好的吧。
Tomcat, Jetty, JBoss, and GlassFish 自带的默认Servlet的名字 -- "default"
Google App Engine
默认Servlet的名字 -- "_ah_default"
默认Servlet的名字 -- "resin-file"
默认Servlet的名字
-- "FileServlet"
默认Servlet的名字 -- "SimpleFileServlet"
方案二： 在spring3.0.4以后版本提供了mvc:resources ，
使用方法：
&!-- 对静态资源文件的访问 --&
&mvc:resources mapping="/images/**" location="/images/" /&
/images/**映射到ResourceHttpRequestHandler进行处理，location指定静态资源的位置.可以是web application根目录下、jar包里面，这样可以把静态资源压缩到jar包中。cache-period 可以使得静态资源进行web cache
如果出现下面的错误，可能是没有配置&mvc:annotation-driven /&的原因。
报错WARNING: No mapping found for HTTP request with URI [/mvc/user/findUser/lisi/770] in DispatcherServlet with name 'springMVC'
使用&mvc:resources/&元素,把mapping的URI注册到SimpleUrlHandlerMapping的urlMap中,
key为mapping的URI pattern值,而value为ResourceHttpRequestHandler,
这样就巧妙的把对静态资源的访问由HandlerMapping转到ResourceHttpRequestHandler处理并返回,所以就支持classpath目录,jar包内静态资源的访问.
另外需要注意的一点是,不要对SimpleUrlHandlerMapping设置defaultHandler.因为对static uri的defaultHandler就是ResourceHttpRequestHandler,
否则无法处理static resources request.
方案三 ，使用&mvc:default-servlet-handler/&
&mvc:default-servlet-handler/&
会把"/**" url,注册到SimpleUrlHandlerMapping的urlMap中,把对静态资源的访问由HandlerMapping转到org.springframework.web.servlet.resource.DefaultServletHttpRequestHandler处理并返回.
DefaultServletHttpRequestHandler使用就是各个Servlet容器自己的默认Servlet.
补充说明：多个HandlerMapping的执行顺序问题：
DefaultAnnotationHandlerMapping的order属性值是：0
&mvc:resources/
&自动注册的
SimpleUrlHandlerMapping的order属性值是：
&mvc:default-servlet-handler/&自动注册
的SimpleUrlHandlerMapping
的order属性值是：
spring会先执行order值比较小的。当访问一个a.jpg图片文件时，先通过 DefaultAnnotationHandlerMapping 来找处理器，一定是找不到的，因为我们没有叫a.jpg的Action。然后再按order值升序找，由于最后一个 SimpleUrlHandlerMapping 是匹配 "/**"的，所以一定会匹配上，就可以响应图片。
访问一个图片，还要走层层匹配。不知性能如何？
最后再说明一下，方案二、方案三 在访问静态资源时，如果有匹配的(近似)总拦截器，就会走拦截器。如果你在拦截中实现权限检查，要注意过滤这些对静态文件的请求。
如何你的DispatcherServlet拦截 *.do这样的URL后缀，就不存上述问题了。还是有后缀方便。
转载请注明出处：原文地址：
八、请求如何映射到具体的Action中的方法？
方案一：基于xml配置映射，可以利用SimpleUrlHandlerMapping、BeanNameUrlHandlerMapping进行Url映射和拦截请求。
配置方法略。
方案二：基于注解映射，可以使用DefaultAnnotationHandlerMapping。
&bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping"&
但前面我们配置了&mvc:annotation-driven /&，他会自动注册这个bean,就不须要我们显示的注册这个bean了。
&mvc:annotation-driven /&？他到底做了什么工作，请看，最后面的 十九节
&mvc:annotation-driven /&
到底做了什么工作。
以上都可以注入interceptors，实现权限控制等前置工作。
我们使用第2种，基于注解来使用spring MVC
并在action类上使用：
@Controller
@RequestMapping("/user")
转载请注明出处：原文地址：
九、Spring中的拦截器：
Spring为我们提供了：
org.springframework.web.servlet.HandlerInterceptor接口，
org.springframework.web.servlet.handler.HandlerInterceptorAdapter适配器，
实现这个接口或继承此类，可以非常方便的实现自己的拦截器。
有以下三个方法：
Action之前执行:
public boolean preHandle(HttpServletRequest request,
HttpServletResponse response, Object handler);
生成视图之前执行
public void postHandle(HttpServletRequest request,
HttpServletResponse response, Object handler,
ModelAndView modelAndView);
最后执行，可用于释放资源
public void afterCompletion(HttpServletRequest request,
HttpServletResponse response, Object handler, Exception ex)
分别实现预处理、后处理（调用了Service并返回ModelAndView，但未进行页面渲染）、返回处理（已经渲染了页面）
在preHandle中，可以进行编码、安全控制等处理；
在postHandle中，有机会修改ModelAndView；
在afterCompletion中，可以根据ex是否为null判断是否发生了异常，进行日志记录。
参数中的Object handler是下一个拦截器。转载请注明出处：原文地址：
十、如何使用拦截器？
自定义一个拦截器，要实现HandlerInterceptor接口：
public class MyInteceptor implements HandlerInterceptor {
Spring MVC并没有总的拦截器，不能对所有的请求进行前后拦截。
Spring MVC的拦截器，是属于HandlerMapping级别的，可以有多个HandlerMapping ，每个HandlerMapping可以有自己的拦截器。
当一个请求按Order值从小到大，顺序执行HandlerMapping接口的实现类时，哪一个先有返回，那就可以结束了，后面的HandlerMapping就不走了，本道工序就完成了。就转到下一道工序了。
拦截器会在什么时候执行呢？ 一个请求交给一个HandlerMapping时，这个HandlerMapping先找有没有处理器来处理这个请求，如何找到了，就执行拦截器，执行完拦截后，交给目标处理器。
如果没有找到处理器，那么这个拦截器就不会被执行。
在spring MVC的配置文件中配置有三种方法：
方案一，（近似）总拦截器，拦截所有url
&mvc:interceptors&
&bean class="com.app.mvc.MyInteceptor" /&
&/mvc:interceptors&
为什么叫“近似”，前面说了，Spring没有总的拦截器。
&mvc:interceptors/&会为每一个HandlerMapping，注入一个拦截器。总有一个HandlerMapping是可以找到处理器的，最多也只找到一个处理器，所以这个拦截器总会被执行的。起到了总拦截器的作用。
如果是REST风格的URL，静态资源也会被拦截。
总拦截器，
拦截匹配的URL。
&mvc:interceptors &
&mvc:interceptor&
&mvc:mapping path="/user/*" /& &!-- /user/*
&bean class="com.mvc.MyInteceptor"&&/bean&
&/mvc:interceptor&
&/mvc:interceptors&
方案一多了一个URL匹配。
如果是REST风格的URL，静态资源也会被拦截。
方案三,HandlerMappint上的拦截器。
如果是REST风格的URL，静态资源就不会被拦截。因为我们精准的注入了拦截器。
&bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping"&
&property name="interceptors"&
&bean class="com.mvc.MyInteceptor"&&/bean&
&/property&
如果使用了&mvc:annotation-driven /&， 它会自动注册DefaultAnnotationHandlerMapping 与AnnotationMethodHandlerAdapter 这两个bean,所以就没有机会再给它注入interceptors属性，就无法指定拦截器。
当然我们可以通过人工配置上面的两个Bean，不使用
&mvc:annotation-driven /&，就可以
给interceptors属性
注入拦截器了。
其实我也不建议使用
&mvc:annotation-driven /&，而建议手动写详细的配置文件，来替代
&mvc:annotation-driven /&，这就控制力就强了。
&mvc:annotation-driven /&？他到底做了什么工作，请看，最后面的 十九节
&mvc:annotation-driven /&
到底做了什么工作。
转载请注明出处：原文地址：
十一、如何实现全局的异常处理？
在spring MVC的配置文件中：
&!-- 总错误处理--&
&bean id="exceptionResolver" class="org.springframework.web.servlet.handler.SimpleMappingExceptionResolver"&
&property name="defaultErrorView"&
&value&/error/error&/value&
&/property&
&property name="defaultStatusCode"&
&value&500&/value&
&/property&
&property name="warnLogCategory"&
&value&org.springframework.web.servlet.handler.SimpleMappingExceptionResolver&/value&
&/property&
这里主要的类是SimpleMappingExceptionResolver类，和他的父类AbstractHandlerExceptionResolver类。
具体可以配置哪些属性，我是通过查看源码知道的。
你也可以实现HandlerExceptionResolver接口，写一个自己的异常处理程序。spring的扩展性是很好的。
通过SimpleMappingExceptionResolver我们可以将不同的异常映射到不同的jsp页面（通过exceptionMappings属性的配置）。
同时我们也可以为所有的异常指定一个默认的异常提示页面（通过defaultErrorView属性的配置），如果所抛出的异常在exceptionMappings中没有对应的映射，则Spring将用此默认配置显示异常信息。
注意这里配置的异常显示界面均仅包括主文件名，至于文件路径和后缀已经在viewResolver中指定。如/error/error表示/error/error.jsp
显示错误的jsp页面：
&%@ page language="java" contentType="text/ charset=GBK"
pageEncoding="GBK"%&
&%@ page import="java.lang.Exception"%&
&!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"&
&meta http-equiv="Content-Type" content="text/ charset=GBK"&
&title&错误页面&/title&
&h1&出错了&/h1&
Exception e = (Exception)request.getAttribute("exception");
out.print(e.getMessage());
其中一句：request.getAttribute("exception")，key是exception，也是在SimpleMappingExceptionResolver类默认指定的，是可能通过配置文件修改这个值的，大家可以去看源码。
十二、如何把全局异常记录到日志中？
在前的配置中，其中有一个属性warnLogCategory，值是“SimpleMappingExceptionResolver类的全限定名”。我是在SimpleMappingExceptionResolver类父类AbstractHandlerExceptionResolver类中找到这个属性的。查看源码后得知：如果warnLogCategory不为空，spring就会使用apache的mons.logging.Log日志工具，记录这个异常，级别是warn。
值：“org.springframework.web.servlet.handler.SimpleMappingExceptionResolver”，是“SimpleMappingExceptionResolver类的全限定名”。这个值不是随便写的。
因为我在log4j的配置文件中还要加入log4j.logger.org.springframework.web.servlet.handler.SimpleMappingExceptionResolver=WARN，保证这个级别是warn的日志一定会被记录，即使log4j的根日志级别是ERROR。
转载请注明出处：原文地址：
十三、如何给spring3 MVC中的Action做JUnit单元测试？
使用了spring3 MVC后，给action做单元测试变得很方便，我以前从来不给action写单元测试的，现在可以根据情况写一些了。
不用给每个Action都写单元测试吧，自己把握吧。
JUnitActionBase类是所有JUnit的测试类的父类
import javax.servlet.http.HttpServletR
import javax.servlet.http.HttpServletR
import org.junit.BeforeC
import org.springframework.mock.web.MockServletC
import org.springframework.web.context.WebApplicationC
import org.springframework.web.context.support.XmlWebApplicationC
import org.springframework.web.servlet.HandlerA
import org.springframework.web.servlet.HandlerExecutionC
import org.springframework.web.servlet.HandlerM
import org.springframework.web.servlet.ModelAndV
import org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerA
import org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerM
* 说明： JUnit测试action时使用的基类
* @version 创建时间： 下午10:27:03
public class JUnitActionBase {
private static HandlerMapping handlerM
private static HandlerAdapter handlerA
* 读取spring3 MVC配置文件
@BeforeClass
public static void setUp() {
if (handlerMapping == null) {
String[] configs = { "file:src/springConfig/springMVC.xml" };
XmlWebApplicationContext context = new XmlWebApplicationContext();
context.setConfigLocations(configs);
MockServletContext msc = new MockServletContext();
context.setServletContext(msc);
context.refresh();
msc.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, context);
handlerMapping = (HandlerMapping) context
.getBean(DefaultAnnotationHandlerMapping.class);
handlerAdapter = (HandlerAdapter) context.getBean(context.getBeanNamesForType(AnnotationMethodHandlerAdapter.class)[0]);
* 执行request对象请求的action
* @param request
* @param response
* @throws Exception
public ModelAndView excuteAction(HttpServletRequest request, HttpServletResponse response)
throws Exception {
HandlerExecutionChain chain = handlerMapping.getHandler(request);
final ModelAndView model = handlerAdapter.handle(request, response,
chain.getHandler());
这是个JUnit测试类，我们可以new Request对象，来参与测试，太方便了。给request指定访问的URL，就可以请求目标Action了。
import org.junit.A
import org.junit.T
import org.springframework.mock.web.MockHttpServletR
import org.springframework.mock.web.MockHttpServletR
import org.springframework.web.servlet.ModelAndV
import test.JUnitActionB
* 说明： 测试OrderAction的例子
* @version 创建时间： 下午10:26:55
public class TestOrderAction extends JUnitActionBase {
public void testAdd() throws Exception {
MockHttpServletRequest request = new MockHttpServletRequest();
MockHttpServletResponse response = new MockHttpServletResponse();
request.setServletPath("/order/add");
request.addParameter("id", "1002");
request.addParameter("date", "");
request.setMethod("POST");
// 执行URI对应的action
final ModelAndView mav = this.excuteAction(request, response);
// Assert logic
Assert.assertEquals("order/add", mav.getViewName());
String msg=(String)request.getAttribute("msg");
System.out.println(msg);
需要说明一下
：由于当前最想版本的Spring(Test) 3.0.5还不支持@ContextConfiguration的注解式context file注入，所以还需要写个setUp处理下，否则类似于Tiles的加载过程会有错误，因为没有ServletContext。3.1的版本应该有更好的解决方案，
十四、转发与重定向
可以通过redirect/forward:url方式转到另一个Action进行连续的处理。
可以通过redirect:url 防止表单重复提交
写法如下：
return "forward:/order/add";
return "redirect:/index.jsp";
转载请注明出处：原文地址：
带参数重定向--RedirectAttributes
用户保存或修改后，为了防止用户刷新浏览器(F5)导致表单重复提交，一般在保存或修改操作之后会redirect到一个结果页面（不是forward），同时携带参数，如操作成功的提示信息。因为是Redirect，Request里的attribute不会传递过去。Spring在3.1才提供了这个能力--RedirectAttributes。 反复按F5，操作成功的提示信息也不会再次出来（总共只出现一次），效果很理想。
public String save(@ModelAttribute("group") Group group, RedirectAttributes redirectAttributes) {
accountManager.saveGroup(group);
redirectAttributes.addFlashAttribute("message", "操作成功");
return "redirect:/account/group/";
十五、处理ajax请求
1、引入下面两个jar包，我用的是1.7.2，好像1.4.2版本以上都可以，下载地址：
jackson-core-asl-1.7.2.jar
jackson-mapper-asl-1.7.2.jar
2、spring的配置文件中要有这一行，才能使用到spring内置支持的json转换。如果你手工把POJO转成json就可以不须要使用spring内置支持的json转换。
&mvc:annotation-driven /&
3、使用@ResponseBody注解
* ajax测试
* http://127.0.0.1/mvc/order/ajax
@RequestMapping("/ajax")
@ResponseBody
public Object ajax(HttpServletRequest request){
List&String& list=new ArrayList&String&();
list.add("电视");
list.add("洗衣机");
list.add("冰箱");
list.add("电脑");
list.add("汽车");
list.add("空调");
list.add("自行车");
list.add("饮水机");
list.add("热水器");
转载请注明出处：原文地址：
十六、关于写几个配置文件的说明
我看到有的人把配置文件写两份：
一个是原有的applicationContext.xml，这个文件从spring2.0-2.5时一直在使用。
别一个是新加的spring MVC的配置文件。
其实这两个文件是可以写成一个文件的，springMVC相关的配置，数据源，事务相关配置可以都写再一个配置文件中。
本例子中只使用了一个spring配置文件叫“springMVC.xml”。
就不要再多配置一个applicationContext.xml文件了。
web.xml文件中也不要再配置org.springframework.web.context.ContextLoaderListener的listener了。
写两个配置文件一般就会导致扫描两次，一定要精确控制扫描的包名，做到不重复扫描。
写两个配置文件还出现事务不好使的现象，是当把@Transactional写有Action层时出现的。
是因为父子上下文的原因，请参看前的 第五节 父子上下文，里面有说明 。原因是父上下文不能访问子上下文。
十七、如何取得Spring管理的bean
（请用第3种方法）
1、servlet方式加载时，
【web.xml】
&servlet-name&springMVC&/servlet-name&
&servlet-class&org.springframework.web.servlet.DispatcherServlet&/servlet-class&
&init-param&
&param-name&contextConfigLocation&/param-name&
&param-value&classpath*:/springMVC.xml&/param-value&
&/init-param&
&load-on-startup&1&/load-on-startup&
&/servlet&
spring容器放在ServletContext中的key是org.springframework.web.servlet.FrameworkServlet.CONTEXT.springMVC
注意后面的springMVC，是你的servlet-name配置的值，注意适时修改。
ServletContext sc=略
WebApplicationContext attr = (WebApplicationContext)sc.getAttribute("org.springframework.web.servlet.FrameworkServlet.CONTEXT.springMVC");
2、listener方式加载时：
【web.xml】
&context-param&
&param-name&contextConfigLocation&/param-name&
&param-value&/WEB-INF/applicationContext&/param-value&
&/context-param&
&listener&
&listener-class&org.springframework.web.context.ContextLoaderListener&/listener-class&
&/listener&
【jsp/servlet】可以这样取得
ServletContext context = getServletContext();
WebApplicationContext applicationContext
= WebApplicationContextUtils .getWebApplicationContext(context);
3、通用的方法来了，神器啊，前的
1、2两种方法并不通用，可以抛弃了。
在配置文件中加入：
&!-- 用于持有ApplicationContext,可以使用SpringContextHolder.getBean('xxxx')的静态方法得到spring bean对象 --&
&bean class="com.xxxxx.SpringContextHolder" lazy-init="false" /&
import org.springframework.context.ApplicationC
import org.springframework.context.ApplicationContextA
* 以静态变量保存Spring ApplicationContext, 可在任何代码任何地方任何时候中取出ApplicaitonContext.
public class SpringContextHolder implements ApplicationContextAware {
private static ApplicationContext applicationC
* 实现ApplicationContextAware接口的context注入函数, 将其存入静态变量.
public void setApplicationContext(ApplicationContext applicationContext) {
SpringContextHolder.applicationContext = applicationC // NOSONAR
* 取得存储在静态变量中的ApplicationContext.
public static ApplicationContext getApplicationContext() {
checkApplicationContext();
return applicationC
* 从静态变量ApplicationContext中取得Bean, 自动转型为所赋值对象的类型.
@SuppressWarnings("unchecked")
public static &T& T getBean(String name) {
checkApplicationContext();
return (T) applicationContext.getBean(name);
* 从静态变量ApplicationContext中取得Bean, 自动转型为所赋值对象的类型.
@SuppressWarnings("unchecked")
public static &T& T getBean(Class&T& clazz) {
checkApplicationContext();
return (T) applicationContext.getBeansOfType(clazz);
* 清除applicationContext静态变量.
public static void cleanApplicationContext() {
applicationContext =
private static void checkApplicationContext() {
if (applicationContext == null) {
throw new IllegalStateException("applicaitonContext未注入,请在applicationContext.xml中定义SpringContextHolder");
转载请注明出处：原文地址：
十八、多视图控制器
当有jsp,flt (模板)等多种页面生成展示方式时，spring默认使用的是“视图解析器链”。 真是一个链，所以性能不好，spring会在“视图解析器链”中顺序的查找，直到找到对应的 “视图解析器” 。jsp视图解析器一定要写在最后面，因为一旦调用jsp，就向浏览器发出数据了，Spring就没有机会再尝试下一个了。
所以自己写一个"多视图解析器"，依靠扩展名来区分，可一次准确的选中一个 视图解析器,提高性能（会有多少提高呢？没测试过）.
下面的例子支持jsp,flt (模板)两种页面生成展示方式，你中以自己添加，支持更多。
&!-- 多视图处理器 --&
&bean class="com.xxx.core.web.MixedViewResolver"&
&property name="resolvers"&
&entry key="jsp"&
&bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"&
&property name="prefix" value="/WEB-INF/jsp/"/&
&property name="viewClass" value="org.springframework.web.servlet.view.JstlView"&&/property&
&entry key="ftl"&
&bean class="org.springframework.web.servlet.view.freemarker.FreeMarkerViewResolver"&
&property name="cache" value="true"/&
&property name="contentType" value="text/charset=UTF-8"&&/property&
&!-- 宏命令的支持
&property name="exposeSpringMacroHelpers" value="true"/&
&property name="viewClass" value="org.springframework.web.servlet.view.freemarker.FreeMarkerView"/&
&property name="requestContextAttribute" value="rc"&&/property&
&/property&
&!-- freemarker config --&
&bean id="freeMarkerConfigurer" class="org.springframework.web.servlet.view.freemarker.FreeMarkerConfigurer"&
&property name="templateLoaderPath" value="/WEB-INF/ftl/" /&
&property name="freemarkerSettings"&
&prop key="template_update_delay"&5&/prop&
&prop key="default_encoding"&UTF-8&/prop&
&prop key="locale"&zh_CN&/prop&
&/property&
import java.util.L
import java.util.M
import org.springframework.web.servlet.V
import org.springframework.web.servlet.ViewR
* 说明： 多视图处理器
* @version 创建时间： 上午09:41:09
public class MixedViewResolver implements ViewResolver{
private Map&String,ViewResolver&
public void setResolvers(Map&String, ViewResolver& resolvers) {
this.resolvers =
public View resolveViewName(String viewName,Locale locale) throws Exception{
int n=viewName.lastIndexOf(".");
if(n!=-1){
//取出扩展名
String suffix=viewName.substring(n+1);
//取出对应的ViewResolver
ViewResolver resolver=resolvers.get(suffix);
if(resolver==null){
throw new RuntimeException("No ViewResolver for "+suffix);
resolver.resolveViewName(viewName, locale);
ViewResolver resolver=resolvers.get("jsp");
resolver.resolveViewName(viewName, locale);
转载请注明出处：原文地址：
&mvc:annotation-driven /&
到底做了什么工作
&mvc:annotation-driven /&实际做了以下工作：（不包括添加自己定义的拦截器）
我们了解这些之后，对Spring3 MVC的控制力就更强大了，想改哪就改哪里。
&!-- 注解请求映射
&bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping"&
&property name="interceptors"&
&ref bean="logNDCInteceptor"/&
&!-- 日志拦截器，这是你自定义的拦截器 --&
&ref bean="myRequestHelperInteceptor"/&
&!-- RequestHelper拦截器，这是你自定义的拦截器--&
&ref bean="myPermissionsInteceptor"/&
&!-- 权限拦截器，这是你自定义的拦截器--&
&ref bean="myUserInfoInteceptor"/&
&!-- 用户信息拦截器，这是你自定义的拦截器--&
&/property&
&bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter"&
&property name="messageConverters"&
&ref bean="byteArray_hmc" /&
&ref bean="string_hmc" /&
&ref bean="resource_hmc" /&
&ref bean="source_hmc" /&
&ref bean="xmlAwareForm_hmc" /&
&ref bean="jaxb2RootElement_hmc" /&
&ref bean="jackson_hmc" /&
&/property&
&bean id="byteArray_hmc" class="org.springframework.http.converter.ByteArrayHttpMessageConverter" /&&!-- 处理.. --&
&bean id="string_hmc" class="org.springframework.http.converter.StringHttpMessageConverter" /&&!-- 处理.. --&
&bean id="resource_hmc" class="org.springframework.http.converter.ResourceHttpMessageConverter" /&&!-- 处理.. --&
&bean id="source_hmc" class="org.springframework.http.converter.xml.SourceHttpMessageConverter" /&&!-- 处理.. --&
&bean id="xmlAwareForm_hmc" class="org.springframework.http.converter.xml.XmlAwareFormHttpMessageConverter" /&&!-- 处理.. --&
&bean id="jaxb2RootElement_hmc" class="org.springframework.http.converter.xml.Jaxb2RootElementHttpMessageConverter" /&&!-- 处理.. --&
&bean id="jackson_hmc" class="org.springframework.http.converter.json.MappingJacksonHttpMessageConverter" /&&!-- 处理json--&
转载请注明出处：原文地址：
二十、 本文中springMVC.xml配置文件是核心，这里给一个下载地址
要在/网站有注册帐号才能下载(这不能怪我)
(706.2 KB)
下载次数: 40877
下载次数: 23919
浏览 785732
不太明白，这个HandlerMapping到底是起到什么作用的这个是一个请求映射器，当一个请求过来的时候会根据这个映射到对应的处理器，然后转发到相应的拦截处理器
不太明白，这个HandlerMapping到底是起到什么作用的
& 上一页 1
浏览: 2606855 次
来自: 北京
正好需要使用，谢啦
谢谢！我再仔细看看
好贴！顶一个
[img][/img]
嘿嘿老赵这么忙还腾出精力写博客，搜Mac 配环境变量都搜到你的 ...