`
ihuashao
  • 浏览: 4725413 次
  • 性别: Icon_minigender_1
  • 来自: 济南
社区版块
存档分类
最新评论

为什么应该升级到Struts 1.1?

阅读更多

Struts 1.1 final终于发布了。新特性包括对多个子应用程序的支持、DynaBean和BeanUtil、声明式异常处理、Validator等。熟悉Struts的人肯定早已在用Struts 1.1,下面这篇文章是给不熟悉的人看的。

——————————————————

Introduction

Since the release of Struts 1.0, Struts has gradually become a de facto standard for MVC (a.k.a. Model-2) implementation for developing medium-to-large scale web-based applications on the Java platform. Struts fits nicely in the J2EE technology stack and fills the gap which is not addressed neither by the Servlet/JSP standard or the EJB standard. Giants like IBM and Oracle have started embracing and supporting Struts in their product set.

Built on the success of Struts 1.0, Struts 1.1 beta was released in March this year and showcased at JavaOne 2002 and the latest Struts 1.1 beta-2 was released just two weeks ago. The immediate question existing Struts users or evaluators will have is "Should I now consider to migrate my existing applications to Struts 1.1 and start to develop my new project on Struts 1.1?"

To answer this question, we need to consider what important new features are offered in 1.1 and examine what impacts there are on existing projects to migrate from 1.0 to 1.1.


New Features

Instead of overwhelming you with the full list of all the new features, I will go through the most significant enhancements in Struts 1.1 in this section.


Multiple Sub-applications

One of the shortcomings in Struts 1.0 is manageability of the configuration file (commonly known as struts-config.xml) when the development of the application involves a sizable team. This problem arises because a Struts-based application must run under one controller servlet, the ActionServlet, and the ActionServlet can use only one struts-config.xml. It is not an issue when the project is relatively small and the team consists of a couple of developers; however, when the project size becomes significant and the project involves a large number of developers, maintaining all the mapping information in a single file becomes increasingly problematic.

Struts 1.1 solves this problem nicely by introducing multiple sub-applications. In Struts 1.1, each sub-application has its own struts-config.xml file. A large Struts-based application can thus be easily partitioned into largely independent modules, i.e. sub-applications, and each sub-team can maintain their struts-config.xml independently.

The sub-application scheme is a natural extension of the servlet context mapping scheme of the URI paths used by servlet containers. According to the Servlet standard, when the servlet container receives a request with a URL, the servlet container will try to match the prefix of the URI path to a deployed web-application in the container. What Struts 1.1 does is it maps the second prefix of the path to a sub-application. In effect, this prefix mapping scheme creates another level of namespace for each sub-application. For example, for the URI,


http://some-host.com/myApp/module2/editSubscription.do


/myApp is the context path for a web-application called "myApp" and /module2 is the sub-app prefix for a Struts sub-application called "module2".


DynaBean and BeanUtils

Another major complaint usually heard amongst Struts 1.0 users is the extensive effort involved in writing the FormBean (a.k.a. ActionForm) classes.

Struts provides two-way automatic population between HTML forms and Java objects, the FormBeans. To take advantage of this however, you have to write one FormBean per HTML form. (In some use cases, a FormBean can actually be shared between multiple HTML forms. But those are specific cases.) Struts' FormBean standard follows faithfully the verbose JavaBean standard to define and access properties. Besides, to encourage a maintainable architecture, Struts enforces a pattern such that it is very difficult to 'reuse' a model-layer object (e.g. a ValueObject from the EJB tier) as a FormBean. Combining all these factors, a developer has to spend a significant amount of time to write tedious getters/setters for all the FormBean classes.

Struts 1.1 offers an alternative, Dynamic ActionForms, which are based on DynaBeans. Simply put, DynaBeans are type-safe name-value pairs (think HashMaps) but behave like normal JavaBeans with the help of the BeanUtils library. (Both the DynaBeans and the BeanUtils library were found to be useful and generic enough that they have been 'promoted' into Jakarta's Commons project.) With Dynamic ActionForms, instead of coding the tedious setters/getters, developers can declare the required properties in the struts-config.xml files. Struts will instantiate and initialize Dynamic ActionForm objects with the appropriate metadata. From then onwards, The Dynamic ActionForm instance is treated as if it is an ordinary JavaBean by Struts and the BeanUtils library.


Declarative Exception Handling

If you have developed web applications long enough, you will realize a recurring pattern emerges: when the backend (e.g. the EJB tier) throws you an exception, you nearly always need to display an error page corresponding to the type of that exception. Sooner or later, you will come up with a mechanism to use a lookup table (e.g. an HashMap) to lookup an error page from the exception class.

Struts 1.1 now provides a similar but more powerful mechanism to declare exception handling. In Struts 1.1, you can declare in the struts-config.xml the associations between an exception class and an exception handler. Using the default exception handler included in Struts, you can also specify the path of the error pages. With this information, Struts will automatically forward to the specified pages when an uncaught exception is thrown from an Action.

Like other facilities in Struts, the exception handlers are pluggable. You can write and define your own handler classes if needed.


Validator

The Validator is not exactly a new feature. The Validator has been in the contrib package in the distribution since Struts 1.0.1. Since then, part of it has now been refactored and moved into the Jakarta-Commons subproject and renamed the Commons-Validator and the Struts specific portion is now called the Struts-Validator. However, since it is in the contrib package, people may overlook it and it is worthwhile to mention it here.

The Validator provides an extensible framework to define validation rules to validate user inputs in forms. What is appealing in the Validator is that it generates both the server-side validation code and the client-side validation code (i.e. Javascript) from the same set of validation rules defined in an XML configuration file. The Validator performs the validation based on regular-expression pattern matching. While a handful of commonly used validators are shipped with the framework (e.g. date validator, range validator), you can always define your own ones to suit your need.


Impact

Having gone through the list of exciting new features, it is time to examine the potentially negative impact of these enchacements. One of the highest priorities of the Struts' developer community when developing Struts 1.1 has been to achieve maximum backward compatibility with 1.0. Struts' developers have definitely done a good job in this regard; however, there are still some issues you need to be aware of.


Default Sub-application

To maintain backward compatibility, Struts 1.1 allows one default sub-application per application. The URI of the resources (i.e. JSPs, HTMLs, etc) in the default sub-application will have an empty sub-app prefix. This means when an existing 1.0 application is "dropped" into Struts 1.1, theoretically, it will automatically become the default sub-application.


Direct Requests to JSPs

To take the full advantage of sub-application support, Struts 1.1 stipulates the requirement that all requests must flow through the controller servlet, i.e. the ActionServlet. Effectively, this means all JSPs must be fronted by Actions. Instead of allowing direct requests to any of the JSPs, all requests must go through an Action and let the Action forward to the appropriate JSP.

This is perhaps the biggest impact of migration to Struts 1.1 if you have not followed this idiom in your applications. This restriction is required because without going through the ActionServlet, Struts navigation taglibs (e.g. <html:form> and <html:link>) used in the JSPs will not have the correct sub-app context to work with.


ActionServlet Configurations

With the introduction of sub-applications, a more flexible way is introduced to configure each sub-application independently. Many of the configuration entries (e.g. resource bundle location, maximum upload file size, etc) that used to be defined in web.xml have now been moved to struts-config.xml. The original entries in web.xml are deprecated but will still be effective.


Path-mapped Actions

Both extension-mapped (e.g. *.do) and path-mapped (e.g. /do/*) Actions are supported in Struts 1.0. However, at the time of writing (August 2002), mulitple sub-applications will not work with path-mapped Actions. It is likely this issue will be resolved in the final release of Struts 1.1.


Action.execute() and Action.getResources()

In Struts 1.0, request handling logic is coded in Action.perform(); however, Action.perform() throws only IOException and SevletException. To facilitate the new declarative exception handling , the request handling method needs to throw Exception, the superclass of all the checked exceptions. Therefore, to both maintain backward compatibility and facilitate declarative exception handling, Action.perform() is now deprecated in favour of Action.execute().

You also have to be careful if you use DispatchAction in your existing applications. At the time of writing, the DispatchAction in Struts 1.1 beta has not yet been updated to use execute(). (A bug report has been filed in Struts' bug database.) Therefore, without modifying the DispatchAction class yourself, declarative exception handling will not work with DispatchAction subclasses.

In addition, Action.getResources() is now deprecated. Instead, you should call Action.getResources(HttpServletRequest) instead. This allows Struts to return to you the sub-application specific message resources. Otherwise, the message resources for the default sub-app will be used.


Library Dependency

Struts 1.1 now depends on a handful of libraries from other Jakarta subprojects (e.g. Commons-Logging, Commons-Collections, etc.). Some of these libraries may cause classloading conflicts in some servlet containers. So far, people have reported in the mailing list the classloading problem of commons-digester/jaxp1.1, and commons-logging causing deployment difficulties in Struts 1.1 applications running on Weblogic 6.0. (The problems have been corrected in Weblogic 6.1 and 7.0.)


Resources under WEB-INF

According to the Servlet specification, resources (e.g. JSP files) stored under WEB-INF are protected and cannot be accessed directly by the browsers. One design idiom for Struts 1.0 is to put all the JSP files under WEB-INF and front them by Actions so that clients cannot illegally access the JSPs.

With the introduction of sub-application prefixes in Struts 1.1, mapping resources under WEB-INF gets complicated. Extra configuration steps utilizing the pagePattern and forwardPattern attributes of the <controller> element in struts-config.xml is required to inform Struts to construct the paths correctly. More specifically, you need to set these attributes to the pattern "/WEB-INF/$A$P".


Miscellenous issues for advanced users

The following issues are relevant to you if you are a power Struts user and make use of some advanced features in Struts:

  • If your application depends on the ActionFormBeans, ActionForwards or ActionMappings servlet context attributes, you have to get the information they need from the ApplicationConfig object instead.

  • If you subclass ActionServlet, you may have to retrofit it back to that of Struts 1.1 or the new RequestProcessor class as ActionServlet has been refactored.


Conclusion

So, "Should I consider upgrading to Struts 1.1?" Here are my recommendations.


For Existing Small Projects

If you have a relatively small project and are happy with what Struts 1.0 currently offers, it makes sense to stay with Struts 1.0.


For Existing Medium-to-Large Projects

If you have a large project, the multiple sub-application feature is definitely the overriding factor in influencing your decision. The litmus test is to ask yourself this question: "Is the existing struts-config.xml file getting very difficult to manage due to its sheer file size?" If the answer is yes, you should consider doing a pilot trial to replace Struts 1.0 with Struts 1.1 in your development environment without partitioning your application into sub-applications first.

Since Struts 1.1 can treat your existing application simply as the default sub-application, the replacement should be straightforward. However, to test if your application is actually Struts 1.1 compliant, you should configure it as a sub-application with a non-empty prefix and go through some representative use cases to test and see if the application works as it used to be. Before you embark onto the pilot trial, you have to make sure all of your developers are aware of the issues listed in the previous section, particularly the requirement that all requests must go through the controller servlet as it is quite likely that that may not the case in your application. You need their input to decide if the migration is feasible or not.

Once the pilot trial is successful and you decide to migrate to Struts 1.1, you can start to work out how to partition the application into sub-applications with adequate granularity. Being able to partition the application into sub-applications, you may also want to consider reorganizing your team structure and the project structure of your source code control to align with the partitioning.


For New Projects

If your project is a new one, the decision to use Struts 1.1 mainly depends on the amount of risk your project can take. Struts 1.0 is a proven technology but Struts 1.1 is still in beta. Besides, migrating backwards is always more difficult than migrating forwards. Once you start with Struts 1.1, it will involve a lot of hard work to go back to Struts 1.0. While the extra risk in using Struts 1.1 is generally very low (as the quality of work from Apache's developer community has been consistently very good), it is still a non-negligible factor you have to consider.



About the Author

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.

分享到:
评论

相关推荐

    struts1.1 jar包

    在实际项目中,开发人员会将struts1.1的jar包与其他依赖库(如log4j、commons-logging等)一起添加到项目的类路径中,以便充分利用Struts框架提供的服务。开发流程通常包括编写Action类、ActionForm类、配置文件以及...

    Commons Validator 1.3与Struts 1.1混合使用时的问题处理

    5. 更新组件:考虑升级Struts到更稳定或兼容性更好的版本,如Struts 1.3,这样可以解决许多已知的兼容性问题。同时,检查Commons Validator的最新版本,以获取最新的功能和修复。 解决这些问题通常需要对Struts和...

    struts2 所需8个Jar包(2.2.1.1版本)

    如果你的Web项目使用的是2.3.15.1版本的Struts2并且遇到了问题,尝试回退到2.2.1.1版本可能能够解决问题。 以下是Struts2框架中通常包含的一些关键Jar包及其作用: 1. **struts2-core.jar**:这是Struts2的核心库...

    Struts2.3.1.1.zip

    对于开发人员来说,升级到这个版本可以享受到更好的稳定性和安全性。然而,具体改动需要查看官方发布的更新日志才能详细了解。 总的来说,Struts2框架为Java Web开发提供了一种强大且灵活的解决方案,其丰富的特性...

    struts2.3.1.1 jar及源码

    升级到Struts2.3.1.1时,需要检查兼容性问题,确保现有的Action、Interceptor和Result不受影响,同时注意更新相应的依赖库。 通过学习和使用Struts2.3.1.1的源码,开发者不仅可以提升Java Web开发能力,还可以更好...

    struts-2.2.1.1

    Struts 2 的出现是对早期Struts 1框架的升级,它融合了WebWork框架的核心特性,从而在功能和性能上有了显著提升。 1. **MVC架构**:Struts 2遵循MVC设计模式,将业务逻辑、数据和用户界面分离,提高了代码的可维护...

    struts 2.3.7 jar

    Struts 2.3.7 是一个...同时,Struts 2.3.7还支持自定义拦截器、国际化、异常处理、主题和模板等特性,为开发者提供了高度灵活的开发选择。通过熟练掌握Struts 2.3.7,开发者可以更好地应对各种Web应用的需求和挑战。

    struts-1.3.8-lib(new)

    总的来说,"struts-1.3.8-lib(new)"这个压缩包代表了一个针对Struts 1.3.8版本的更新,特别关注了JSTL和Standard库的升级,这将影响到应用的视图层和与Servlet容器的交互。对于使用Struts 1.3.8的开发者来说,这是一...

    struts文档

    自Struts 1.1版本起,该框架开始支持多模块开发,这意味着不同的功能模块可以拥有各自的配置文件,包括`struts-config.xml`、消息资源文件和Validator框架配置文件等。这种模块化机制有效地解决了并行开发中常见的...

    struts2.3-001.rar

    Struts2.3-001.rar 是一个与Apache Struts框架相关的压缩包,其中包含了Struts 2.3.1.1版本的所有组件。Apache Struts是一个开源的MVC(Model-View-Controller)框架,它被广泛用于构建Java Web应用程序。这个压缩包...

    一个关于办公自动化的管理系统的源码

    7. **技术升级**:尽管Struts1.1和Hibernate3.0是较早的技术版本,但理解其原理对于学习更先进的Spring MVC和Hibernate5等框架大有裨益。此外,系统可能需要考虑升级到更现代的前端技术如React或Vue,后端可考虑...

    struts框架中数据源的配置

    Struts框架作为一种成熟的MVC架构实现,为开发者提供了丰富的功能来简化Web应用的开发流程。其中,数据源的配置是一项基础且重要的工作,它直接影响到应用的性能和可维护性。 本文将详细介绍如何在Struts框架中配置...

    Jakarta Struts2

    最初的版本为1.x系列,随着时间的推移,为了满足不断变化的技术需求,以及解决早期版本中存在的问题,发展到了2.x系列,即Jakarta Struts2。版本1.1是在保持向后兼容性的前提下进行的升级,这意味着1.0版本的开发者...

    struts2配置文件传值中文乱码

    Struts2是Apache组织下的一个开源框架,它是Struts框架的升级版,基于MVC(Model-View-Controller)设计模式,用于简化Java Web应用程序的开发过程。Struts2通过拦截器(Interceptor)和配置文件实现了灵活的功能...

    struts2学习笔记

    1.1 为什么要用Struts 在传统的JSP开发中,模型与视图、控制器的耦合度较高,导致代码维护困难。Struts2引入了MVC设计模式,提高了代码组织结构,降低了组件间的依赖,使得系统更易于扩展和维护。 1.2 什么是MVC ...

    struts2xwork2帮助文档

    - `struts2.2.1.1_xwork2.1.2.chm`:这个文档可能包含了Struts2.2.1.1和XWork2.1.2的联合信息,对于理解这两个版本的交互和升级非常重要。 - `Strutshelp.CHM`:可能是Struts框架的综合帮助文档,可能涵盖了更广泛的...

    struts 2 漏洞报告

    1. **升级Struts 2**:最简单也是最有效的解决方案是升级到Struts 2 的最新稳定版本。 2. **禁用Jakarta Multipart解析器**:如果暂时无法升级框架版本,可以通过配置文件禁用Jakarta Multipart解析器。 3. **使用...

Global site tag (gtag.js) - Google Analytics