Struts2简介
Struts2简介
从某种程度上来讲，Struts2没有继承Struts 1的血统，而是继承WebWork的血统。或者说，WebWork衍生出了Struts2，而不是Struts 1衍生了Struts2。因为Struts2是WebWork的升级，而不是一个全新的框架，因此稳定性、性能等各方面都有很好的保证：而且吸收了Struts 1和WebWork两者的优势，因此，是一个非常值得期待的框架。
Apache Struts2是一个优雅的，可扩展的JAVA EE web框架。框架设计的目标贯穿整个开发周期，从开发到发布，包括维护的整个过程。
Apache Struts 2即是之前大家所熟知的WebWork 2。在经历了几年的各自发展后，WebWork和Struts社区决定合二为一，也即是Struts 2
Struts 2 英文学习网站：http://struts./2.0.6/docs/guides.html
Struts2和Struts1的不同
Action 类
◆Struts1要求Action类继承一个抽象基类。Struts1的一个普遍问题是使用抽象类编程而不是接口。
◆Struts 2 Action类可以实现一个Action接口，也可实现其他接口，使可选和定制的服务成为可能。Struts2提供一个ActionSupport基类去实现 常用的接口。Action接口不是必须的，任何有execute标识的POJO对象都可以用作Struts2的Action对象。
线程模式
◆Struts1 Action是单例模式并且必须是线程安全的，因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts1 Action能做的事，并且要在开发时特别小心。Action资源必须是线程安全的或同步的。
◆Struts2 Action对象为每一个请求产生一个实例，因此没有线程安全问题。（实际上，servlet容器给每个请求产生许多可丢弃的对象，并且不会导致性能和垃圾回收问题）
Servlet 依赖
◆Struts1 Action 依赖于Servlet API ,因为当一个Action被调用时HttpServletRequest 和 HttpServletResponse 被传递给execute方法。
◆Struts 2 Action不依赖于容器，允许Action脱离容器单独被测试。如果需要，Struts2 Action仍然可以访问初始的request和response。但是，其他的元素减少或者消除了直接访问HttpServetRequest 和 HttpServletResponse的必要性。
可测性
◆测试Struts1 Action的一个主要问题是execute方法暴露了servlet API（这使得测试要依赖于容器）。一个第三方扩展－－Struts TestCase－－提供了一套Struts1的模拟对象（来进行测试）。
◆Struts 2 Action可以通过初始化、设置属性、调用方法来测试，“依赖注入”支持也使测试更容易。
捕获输入
◆Struts1 使用ActionForm对象捕获输入。所有的ActionForm必须继承一个基类。因为其他JavaBean不能用作ActionForm，开发者经常创建多余的类捕获输入。动态Bean（DynaBeans）可以作为创建传统ActionForm的选择，但是，开发者可能是在重新描述(创建)已经存在的JavaBean（仍然会导致有冗余的javabean）。
◆ Struts 2直接使用Action属性作为输入属性，消除了对第二个输入对象的需求。输入属性可能是有自己(子)属性的rich对象类型。Action属性能够通过web页面上的taglibs访问。Struts2也支持ActionForm模式。rich对象类型，包括业务对象，能够用作输入/输出对象。这种ModelDriven 特性简化了taglib对POJO输入对象的引用。
表达式语言
◆Struts1 整合了JSTL，因此使用JSTL EL。这种EL有基本对象图遍历，但是对集合和索引属性的支持很弱。
◆Struts2可以使用JSTL，但是也支持一个更强大和灵活的表达式语言－－"Object-Graph Navigation Language" (OGNL对象图导航语言).
绑定值到页面（view）:
◆ Struts 1使用标准JSP机制把对象绑定到页面中来访问。
◆Struts 2 使用 "ValueStack"技术，使taglib能够访问值而不需要把你的页面（view）和对象绑定起来。ValueStack策略允许通过一系列名称相同但类型不同的属性重用页面（view）。
类型转换
◆Struts 1 ActionForm 属性通常都是String类型。Struts1使用Commons-Beanutils进行类型转换。每个类一个转换器，对每一个实例来说是不可配置的。
◆Struts2 使用OGNL进行类型转换。提供基本和常用对象的转换器。
校验
◆Struts 1支持在ActionForm的validate方法中手动校验，或者通过Commons Validator的扩展来校验。同一个类可以有不同的校验内容，但不能校验子对象。
◆Struts2支持通过validate方法和XWork校验框架来进行校验。XWork校验框架使用为属性类类型定义的校验和内容校验，来支持chain校验子属性
Action执行的控制
◆Struts1支持每一个模块有单独的Request Processors（生命周期），但是模块中的所有Action必须共享相同的生命周期。
◆Struts2支持通过拦截器堆栈（Interceptor Stacks）为每一个Action创建不同的生命周期。堆栈能够根据需要和不同的Action一起使用。
Struts2的工作流程图
工作流程
当接收到一个httprequest
Interceptor做一些拦截或者初始的工作
当外部的httpservletrequest到来时
初始到了servlet容器 传递给一个标准的过滤器链
ActionContextCleanUp这个在集成插件方面非常有用
Other filters(SitMesh,etc)
调用FilterDispatecher会去查找相应的ActionMapper
如果找到了相应的ActionMapper它将会将控制权限交给ActionProxy
ActionProxy将会通过ConfigurationManager来查找配置struts.xml
下一步将会 通过ActionInvocation来负责命令模式的实现（包括调用一些拦截Interceptor框架在调用action之前）
一旦action返回，会查找相应的Result
Result类型可以是 jsp或者freeMark 等
这些组件和ActionMapper一起返回给请求的url（注意拦截器的执行顺序）
响应的返回是通过我们在web.xml中配置的过滤器
如果ActionContextCleanUp是当前使用的，则FilterDispatecher将不会清理
sreadlocal ActionContext
如果ActionContextCleanUp不使用，则将会去清理sreadlocals
详细介绍
一种java-web的MVC框架技术，和传统的struts1有很大的改进。
1．Struts2页面开发中常用标签使用说明
1.1．往action里传值的使用方式：
a.userName属性需要在访问的action中提供相应的属性，并有SET/GET方法。
b.可以不在访问的action中提供相应的属性，用request.getParameter(“userName”);1.2．显示标签property用于输出指定值：
当action返回到指定页面是，可以通过该标签显示action中的属性信息。（注userName必须在action中存在，并有GET方法）。
1.3．往对象中传值用于从页面往action中的对象内传值：
该标签可以在页面中向action中的实体对象内直接传值。（注：在action中要存在user对象，并有SET/GET方法。）
1.4．判断用于在页面中判断指定数据
….
….
该标签用于对指定的数据进行判断，但指定的数据必须在action中存在。
1.5．迭代用于将List、Map、ArrayList等集合进行循环遍历该标签用于将userList集合中的元素进行循环，用过property进行显示集合中的指定元素值。
1.6．URL地址标签，用于生成一个URL地址，可以通过URL标签指定的子元素向URL地址发送请求参数
其中action为请求地址，param子元素为地址后面所带的参数。
1.7．超链接一般和标签一起使用，用于带多个参数。
1.8．set标签，用于将某个值放入指定的范围内。例如application,session等。
将user值放入request范围内。
2．Struts2页面开发中常用标签使用规范：
1.1．通过
往action中传值，action中要有相应的属性，并提供SET/GET方法。
（在数量少时可以使用request.getParameter(“userName”);）
1.2．在页面显示action传来的数据，使用property标签。需要显示的数据从action中获得。
1.3．往action中的实体对象内传值，使用textfield标签。
1.4．在页面中判断指定值使用标签。判断数据从action中获得。
1.5．在页面中需要循环列表显示的数据使用标签，列表数据从action中获得。
1.6．URL地址和超链接可以使用和，在传多值时建议和一起使用。
自从2000年ApacheStruts出现以来，它在大多数的标准下都运行良好，帮助开发出了许许多多基于Java的Web应用程序。Struts是利用服务器端生成的HTML和客户端验证的Javascript的完美结合，使开发和维护变得更加容易。随着时间的推移，用户对Web应用程序的要求不断增加，Struts1.0几乎还滞留于原地，给Web开发者留下了越来越多无趣的“衔接”代码，如何才能建立一个完美的框架结合体呢？
Struts的前世今生
在JavaOne2005大会上，一些Struts的开发者们与RichFeit（Apache蜂巢计划的提交者）还有一些Struts的用户共聚一堂，讨论Struts的未来。与会者提出了StrutsTi的项目，它描述了这样一个框架，能够集众家所长，重新组合成一个堪称完美的框架。可是Struts本身的问题出现了，Struts1.0的代码库不适合大幅度的改进，而它本身的特性设置也相当有限，缺乏了像Ajax的快速和可扩展性。
同样在JavaOne会上，笔者还与Webwork的核心架构师JasonCarreira讨论了关于OpenSymphonyWebWork2的项目，探讨我们如何能更好地协同工作。对于在XWork上进行开发，笔者还是十分感兴趣的，特别是它们核心的命令模式框架，但JasonCarreira建议笔者直接在WebWork2上进行开发。当我和Rich使用了最初几个StrutsTi的版本后，我们决定采纳Jason的建议。
我们认为，Struts应该满足高级应用程序的需求，并且在WebWork2框架中的开发经历也证明了这点，Rich和笔者大多数时间都与一位WebWork2的高级开发者PatrickLightbody一起工作，在这段时期内，Patrick和SpringWebFlow项目的创建者KeithDonald从各个角度考虑了关于一个全新的Web框架的构想，希望能将它们结合在一起，也就是将Keith的SpringWebFlow和TedHusted与笔者的Struts以及Patrick和Jason的WebWork与Rich的Beehive结合在一起，探讨了将这些平台结合到一个框架中的可能性。
不幸的是，细节方面的困难出现了，Beehive和WebFlow无法将其压缩和转换方面的特性进一步融合，同时还有项目的所有者、商标以及身份等问题，不久，这个团队就解散了。
我们不想就这样解散，笔者和Ted（Apache软件基金会的成员）开始与Patrick（WebWork2的高级开发者）和Jason（Webwork核心架构师）探讨如何能让我们更好地合作，Ted产生了Struts与WebWork合并的想法。
由于StrutsTi还是基于WebWork设计的，那么将WebWork的代码转向Struts项目并不是件难事。我们在一月开始了关于WebWork2的ApacheIncubator进程，并完成了WebWork2代码。
Struts2的由来
同时，Struts本身也在为项目的核心识别，进行了激烈的竞争，到底它是不是多重Web框架，Struts包括了ApacheShale，它是一个包含了JSF的Web框架。作为一个Struts的子项目，有着StrutsAction1（现在称之为Struts1）与StrutsAction2（完成了的WebWork2代码）的一些特征。不幸的是，这些子项目让开发者们有些混淆不清，他们都用一个单一框架表示“Struts”。
在尝试将StrutsAction2与Shale的子项目结合到一个单独的Struts2之后，Shale的开发者意识到，如果这些能成为他们以后工程中的开发框架，也是不错的选择。StrutsAction2很快就更名为简洁的Struts2。
如今，ApacheStruts项目已经有它的框架的两个主要版本，但它仍是一个基于Action的框架项目。并且WebWork仍然在定期发布程序补丁，直到Struts2达到GA或是最终稳定，但所有新的开发却都是使用Struts2代码。
由此看来，想要在Struts与WebWork的合并中寻找什么奇迹是不可能的，还是另寻途径更好。但是我们不会放弃当初StrutsTi的构想，为将来做出一个集众家所长的完美框架而努力。
编后：作者在其BLOG中声称，写作本文的目的是为了说清楚Struts2.0项目的由来，以及为什么它包含了WebWork2代码。合并的本身就是一件难处理的事，甚至在开源社区也能看到端倪，两个项目之间构成一个好的合并，是非常罕见的，且还需要经过争辩，同时也希望合并的热潮能遍布开源的世界。
