The contrast between Struts2 and Struts1.

Action class:
? STRUTS1 requires the action class to inherit an abstract base class. A common problem with Struts1 is the use of abstract class programming instead of interfaces.
? The Struts 2 action class can implement an action interface or implement other interfaces to make optional and custom services possible. STRUTS2 provides a actionsupport base class to implement commonly used interfaces. The action interface is not required, and any Pojo object that has an execute identity can be used as the Struts2 action object.

Threading Mode:
? The Struts1 action is a singleton pattern and must be thread-safe because only one instance of the action handles all requests. The singleton strategy limits what Struts1 action can do, and is especially careful when developing. The action resource must be thread-safe or synchronous.
? The Struts2 Action object generates an instance for each request, so there is no thread safety issue. (In fact, the servlet container produces many objects that can be discarded for each request and does not cause performance and garbage collection issues)

Servlet dependencies:
? The Struts1 action relies on the servlet API because HttpServletRequest and HttpServletResponse are passed to the Execute method when an action is invoked.
? Struts 2 Action does not depend on the container, allowing the action to be tested separately from the container. If required, the STRUTS2 action can still access the initial request and response. However, other elements reduce or eliminate the need for direct access to Httpservetrequest and HttpServletResponse.

Testability :
? A major problem in testing the STRUTS1 action is that the Execute method exposes the servlet API (which makes the test dependent on the container). A third-party extension--struts testcase--provides a set of Struts1 mock-up objects (to be tested).
? Struts 2 action can be tested by initializing, setting properties, invoking methods, and "Dependency injection" support makes testing easier.

Capture Input:
? Struts1 uses the Actionform object to capture the input. All Actionform must inherit a base class. Because other JavaBean cannot be used as actionform, developers often create extra class-capture inputs. Dynamic Beans (Dynabeans) can be used as a choice for creating traditional actionform, but developers may be re-describing (creating) existing JavaBean (still causing redundant javabean).
? Struts 2 uses the Action property directly as an input property, eliminating the need for a second input object. The input attribute may be a rich object type with its own (child) attribute. The Action property can be accessed through taglibs on a Web page. STRUTS2 also supports Actionform mode. Rich object types, including business objects, that can be used as input/output objects. This modeldriven feature simplifies taglib references to pojo input objects.

Expression Language:
? Struts1 integrates the Jstl, so the Jstl EL is used. This El has a basic object graph traversal, but support for collections and indexed properties is weak.
? Struts2 can use Jstl, but it also supports a more powerful and flexible expression language-"Object Graph Notation Language" (OGNL).

Bind value to page (view):
? Struts 1 uses the standard JSP mechanism to bind objects to pages for access.
? Struts 2 uses "Valuestack" technology to enable taglib to access the values without having to bind your page (view) and objects together. The Valuestack policy allows pages (view) to be reused through a series of properties with the same name but different types.
　
Type conversions:
? The Struts 1 Actionform property is usually a string type. Struts1 uses commons-beanutils for type conversion. Each class is a converter that is not configurable for each instance.
? STRUTS2 uses OGNL for type conversion. A converter that provides basic and common objects.

Checksum:
? Struts 1 supports manual validation in the Validate method of the Actionform, or through Commons Validator extensions. The same class can have different checksum content, but it cannot validate child objects.
? STRUTS2 supports validation through the Validate method and the Xwork check framework. The Xwork checksum framework uses checksum content validation defined for the attribute class type to support the chain check sub-property

control of Action execution:
? STRUTS1 supports each module with a separate request processors (life cycle), but all the actions in the module must share the same life cycle.
? STRUTS2 supports creating different lifecycles for each action through the Interceptor Stack (Interceptor Stacks). Stacks can be used in conjunction with different actions as needed.

It is estimated that struts spends too much time on the work of Struts1.0 to webwork integration.
did not see what Struts2.0 proposed than webwork Update or practical function points.

You can focus on JBoss Seam,seam to provide some useful features, such as
The method of the client's Ajax remote calling EJB
Integrated workflow engine for page flow and business process
Provides multiple contexts (including page, evnent (request), session, conversation, business, and application) that can maintain the state of the object

Developers are easy to build on seam based applications that are not visible at least in today's struts and spring MVC.

Struts 2 action is to use WebWork thought, webwork will gradually disappear, struts or to continue the scenery.

Currently the SAF is WebWork 2.2, just changing the package name and configuration file, small modifications.
As Action Based Mvc,webwork is basically a collection of peaks, the idea has not changed greatly. Improvement is the complexity of configuration and development.
Struts 1 (Struts Classic) and SAF estimates cannot be upgraded smoothly, simply two products, similar to struts shale.
WebWork 2 and SAF should be easier to upgrade, so start with struts 2 or learn WebWork 2.