Struts自从1.0版本以后已经逐步发展成为一种标准的在java平台上开发基于Web的大中型应用程序的MVC框架，
象IBM以及Oracle这样的巨头公司已经开始在他们的产品中支持struts。
struts1.1的第一个beta版在今年的三月份推出并在2002JavaOne大会上展示，同时最近的一个版本beta2也在
两周前发布，紧接着一些问题就被提了出来：“我是否考虑把先有应用程序整合到1.1上以及考虑开发在1.1的版本
上开发新的应用程序”
现在struts1.1正式版本都发布了，你是否想到过这些问题？
为了回答这个问题，我们需要从两方面来分析：1.都有哪些重要的新特性在1.1版本里？；2.如果我们整合现有
的应用程序到新版本中会出现那些问题？
1。新特性
在这里我不会把所有的新特性一一罗列，我只是把一些重要的特性在此进行阐述。
A.多模块应用（Multiple Sub-applications ）
在struts1.0中一个比较明显的缺点就是：当一个非常大的团队进行开发的时候对于配置文件（通常是struts-config.xml）
的维护是一件麻烦的事情.当系统比较小开发人远不多的时候，这种问题通常不会很明显；然而一旦涉及到大团队的开发，可想
而知，维护所有的mapping请求信息到一个单个的配置文件中将是一件多么痛苦的事情。
在struts1.1中通过引入多模块（multiple sub-applications）来解决这种问题,其中没一个子模块都有自己的struts-config.xml.
这样的话就可以达到“以大化小”的目的，把一个大的应用程序分割成N个模块，每个模块可以独立的维护自己的struts-config.xml。
模块之间的访问也比较清晰：如：
假设我们的系统myApp,其中有一个模块module2，那么访问module2的action mapping,如下：
http://localhost:8080/myApp/module2/***.do
这种写法感觉上好象很清晰，也很符合逻辑。
[前一段时间我写过一篇关于多模块应用的帖子，看来那里的方法现在看来已经过时了]
B.DynaBean and BeanUtils
在struts1.0中你是否有这样的烦恼：不得不为了每一个页面表单配备一个单独的Formbean（当然有些时候多个页面跳转的时候可以共用一
个Formbean），你是否也为写N个枯燥的get set 方法而苦恼？
从struts1.1开始，有一种替代的方法：基于DynaBeans的Dynamic ActionForms，他允许你在struts-config.xml中为每一个页面表单书写必
要的formbean元素，其他的事情你自不必理会（那些枯燥乏味的get set方法现在可以终于可以置之不理了）。
如果你目前的项目已经使用到它，你就会发现它确实给我们省了许多力气。
C.Declarative Exception Handling
如果你有很长的开发基于web应用程序的经验，你就会想为这样的想法，或许你就是这样的做的：为每一个exception配备相应的error页，
通过Hashmap等等可以达到这样一种效果。
在struts1.1中提供了相似但更强大的机制来解决这样的问题：exception handling，它允许你在struts-config.xml中声明不同的exception
就象你在先前的版本中声明frombean、forward一样。
一旦你在struts-config.xml中配置完成，那么在action中可以根据抛出不同exception而forward到相应的error页。
而且你自己可以定制个性化的excetpion来满足个性化的需求。
D.Validator
validate并不是在新版本中才有的，在struta1.0版本的发布包中就已经存在，不过从那时以后，validate转移到Jakarta的另一个项目
Jakarta-Commons中并且更名为：Commons-Validator ，不过struts特有的一部分称为：Struts-Validator。
Struts-Validator提供一种可扩展的机制来为不同页面表单定制校验规则，不过它最吸引人的地方是它可以根据xml配置文件中的校验规
则在client端和server端生成校验代码。
2。影响
以上对一些struts1.1中新特性进行了说明，那么看一下如果我们把这些新特性整合到现有的应用程序中会带来那些影响。毫无疑问struts开发
者无时无刻不在考虑着怎样才能最大限度的和先前的版本兼容，在这一点他们做的很好，在此向他们致敬。
但是仍有一写问题需要各位注意：
A.Default Sub-application
为了和先前的版本兼容{不支持多模块}，struts⒈1允许默认到先前的单模块状态，如：上边1.A,如果我们这样访问：
http://localhost:8080/myApp/***.do 那么请求的是缺省模块的action mapping
B.Direct Requests to JSPs
为了更好的应用多模块，struts1.1中约定所有的请求都必须经过actionservlet，也就是说所有的jsp都应该通过action来forward访问而
不是直接在浏览器访问。
如果你在编程中没有遵守这一约定的话，那么这可能是在系统迁移到1.1上时最大的影响了。
这个约定是必须的，因为如果你没有通过action forward访问，那么jsp页面中Struts navigation taglibs (例如：<html:form> and <html:link>)
将无法知道请求哪个模块。
C.ActionServlet Configurations
通过引入多模块，一个更灵活的维护配置文件的方法就是为每个模块配置独立的xml文件，现在有许多原来是在web.xml中配置的信息（如：
resource bundle location,maximum upload file size等等）转移到struts-config.xml中，当然和以前版本兼容把这些信息写在web.xml
中仍然有效。
D.Path-mapped Actions
在struts先前的版本中extension-mapped（如：*.do）和path-mapped （如：/do/*）都是支持的。但是自从多模块引入以后，很明显第二
种写法将不再有效。
E.Action.execute() and Action.getResources()
在struts先前的版本中所有请求最终都是调用Action.perform()，但是Action.perform() 只抛出两种异常：IOException and SevletException
这将和新特性“declarative exception handling ”向背道。为了兼容先前版本以及使“declarative exception handling”能正常工作，struts采用
Action.execute()来替代Action.perform()，Action.execute()单单笼统的抛出Exception，显然这样可以捕获所有异常。
同时你要注意DispatchAction{它的使用在我的一篇帖子中有说明}，因为在Struts 1.1 beta 还没有更新到使用
execute()(A bug report has been filed in Struts' bug database),因此如果没有更新DispatchAction class，那么declarative exception handling
也将不会起作用。
此外，Action.getResources() 现在已经不用，替代它的是Action.getResources(HttpServletRequest) ，这样就可以返回各个模块的message resources，否则
将使用默认模块的message resources。
F.Library Dependency
//略
H.Resources under WEB-INF
通常把所有的显示页面放在web-inf下将是一个很好的保护方法，这样client端无法通过特定的页面名称来访问。这样同时也达到另外一种编程习惯：所有的请求
都要通过controller来返回。
但是随着多模块的引入，在web-inf下mapping resources变的异常复杂。特别的你要struts-config.xml的<<controller>>中配置pagePattern forwardPattern 来
告诉struts其构造的路径是否正确，你需要这样构造这两个属性："/WEB-INF/$A$P".
I.Miscellenous issues for advanced users
ActionFormBeans ActionForwards ActionMappings 已经不同，被ApplicationConfig 取代。
ActionServlet的核心功能已经转移到RequestProcessor 中去。{详细见我另外一贴}
3。结论
所以对"Should I consider upgrading to Struts 1.1?" 这个问题，我有以下建议：
A。For Existing Small Projects
如果你的系统是基于1.0的并且能很好的运作，建议保留。
B。For Existing Medium-to-Large Projects
如果你的系统足够大的话，那么1.1中的多模块将是最吸引的升级的原因，先别忙，在心里面你最好先自己一个简单的问题：
“在你的系统中struts-config.xml是否随着系统的开发而变的极难维护？”，如果是，那么应该考虑着把struts升级到1.1
此时你先不要忙着把系统分割成多个模块。
因为struts1.1支持单个模块的运做，所以你最好在升级struts以后做一些测试工作，那就是按照先前的运做方式看看系统
是否能够想以前那样正常运做。
在具体的分割模块以前，你要确信的你的开发员已经清楚我在上边提到一些影响方面，特别的就是所有的请求都要同过
controller返回（这个地方也许就是不适合原来编程习惯的地方），你要征求他们的意见来看看是否合适这样升级。
一旦所有的准备工作都符合以后，你就要着手进行模块的划分，这通常要和自己的开发员结构和系统结构放在一起同时考虑。
C。For New Projects
//略
现在struts1.1正式版本已经发布，你没有道理不用，呵呵。。。
原文作者：
John Yu is the co-founder and chief scientist at Scioworks Technologies,
an enterprise software consulting and products company based in Singapore.
He is the primary designer of Scioworks Camino,
a visual modelling tool for developing Struts applications.
John's J2EE/EJB experience dates back to a pilot project he led implemented on Tengah,
what Weblogic AppServer was called before Weblogic was acquired by BEA,
when he was a designer/architect working in Australia. John holds a Masters degree of Computing from Monash University,
Australia and a Postgraduate Diploma in Management from Melbourne Business School,
Australia. He was awarded the Telstra Research Fellowship and the Australia Postgraduate Award.
连接原文：http://www.theserverside.com/resources/article.jsp?l=Struts1_1
不能算是翻译，英文好的就去看看原文，原文跟贴中也有不少高论。。。。
