Comparison between struts1.x and struts2

Features	Struts1.x	Struts2
ActionClass	Struts1.x requires the Action class to be extended from an abstract base class. A common problem of Struts1.x is that it is oriented to abstract class programming rather than interface programming.	The Action class of Struts2 implements an Action interface, along with other interfaces, to implement selectable and custom services. Struts2 provides a base class named ActionSupport to implement common interfaces. Of course, the Action interface is not required. Any POJO object using the execute method can be used as the Action object of Struts 2.
Thread Model	The Struts1.x Action class is a singleton class, because only one instance controls all requests. Singleton policies impose certain restrictions and cause extra troubles for development. Action resources must be thread-safe or synchronous.	The Struts2 Action object is instantiated for every request, so there is no thread security problem. (In practice, the servlet container generates many discard objects for each request without causing performance and garbage collection problems ).
ServletDependency	The Action class of Struts1.x depends on the servlet API. When an Action is called, it is passed to the execute method using HttpServletRequest and HttpServletResponse as parameters.	The Action of Struts2 is irrelevant to the container. Servlet context is represented as simple Maps, allowing the Action to be tested independently. The Struts2 Action can access the initial request (if needed ). However, try to avoid or exclude other elements from directly accessing HttpServletRequest or HttpServletResponse.
Testability	The main problem with Struts1.x testing is that the execute method exposes the Servlet API, which makes the test dependent on the container ). Third-party extensions, such as Struts TestCase, provide a set of Struts1 simulated objects (for testing ).	The Struts2 Action can be tested by initializing, setting properties, and calling methods. The support for dependency injection is also easier to test.
Capture Input	Struts1.x uses the ActionForm object to capture input. Like Action, all actionforms must extend the base class. Because other JavaBean cannot be used as an ActionForm, developers often create redundant classes to capture input. DynaBeans can be created as a substitute for ActionForm classes. However, the developer may be re-describing (creating) the existing JavaBean (still leading to redundant javabean ).	Struts2 directly uses the Action attribute as the INPUT attribute, eliminating the need for the second input object. The INPUT attribute may be a rich object type with its own (sub) attribute. The Action attribute can be accessed through taglibs on the web page. Struts2 also supports the ActionForm mode. Rich object type, including business objects, which can be used as input/output objects. This ModelDriven feature simplifies taglib's reference to POJO input objects.
Expression Language	Struts1.x integrates JSTL, So it uses the expression language of JSTL. Expression languages have basic graphical objects, but their support for set and index attributes is weak.	Struts2 uses JSTL, but also supports a stronger and more flexible Expression Language-"Object Graph Notation Language" (OGNL ).
Bind value to page	Struts1.x uses the standard JSP mechanism to bind objects to the page context.	Struts2 uses the "ValueStack" technology to enable taglib to access the value without binding your page (view) and object. The ValueStack policy allows you to reuse a page (view) through a series of attributes with the same name but different types ).
Type conversion	The ActionForm attribute of Struts1.x is often String. Struts 1. x uses Commons-Beanutils for type conversion. Convert each class, instead of configuring each instance.	Struts2 uses OGNL for type conversion. Provides Converters for basic and common objects.
Verify	Struts1.x supports manual verification in the validate method of ActionForm, or through Commons Validator extension. The same class may have different verification content, but it cannot verify the child object.	Struts2 supports verification through the validate method and XWork verification framework. The XWork verification framework uses the checksum defined for the attribute class type to support the chain checksum subattribute.
ActionExecution Control	Struts1.x supports a separate Request Processors (lifecycle) for each module, but all actions in the module must share the same lifecycle.	Struts2 supports creating different lifecycles for each Action through Interceptor Stacks. The stack can be used with different actions as needed.

Struts2 is a WebWork upgrade, not a Struts 1.x upgrade. Although Struts 2 is compatible with Struts1.x, it is no longer an upgrade of Struts1.x. For developers who already have Struts1.x development experience, Struts1.x development experience is not very helpful for Struts2. On the contrary, for developers who already have WebWork development experience, the development experience of WebWork will be of great reference to the development of Struts2.