Difference between Struts1 and Struts2

1) Comparison of Action implementation classes: Struts 1 requires Action classes to inherit an abstract base class; a specific problem with Struts 1 is to use abstract classes to program rather than interfaces. Struts 2 Action classes can implement an Action interface and others, making optional and customized services possible. Struts 2 provides an ActionSupport base class to implement commonly used interfaces. Even if the Action interface is not required to be implemented, only a POJO class containing an execute method can be used as a Struts 2 Action.
2) Comparison of thread mode: Struts 1 Action is a singleton mode and must be thread-safe, because only one instance of Action handles all requests. The singleton strategy limits what a Struts 1 Action can do, and should be developed with great care. Action resources must be thread-safe or synchronized; Struts 2 Action objects generate an instance for each request, so there are no thread-safety issues.
3) Comparison of Servlet dependencies: Struts 1 Action depends on the Servlet API, because Struts 1 Action has HttpServletRequest and HttpServletResponse methods in its execute method. Struts 2 Action no longer depends on the Servlet API, allowing Action to run away from the Web container, thus reducing the difficulty of testing Action. Of course, if the Action needs to directly access the HttpServletRequest and HttpServletResponse parameters, Struts 2 Action can still access them. However, most of the time, Action does not need to directly access HttpServetRequest and HttpServletResponse, thus giving developers more flexible choices.
4) Comparison of testability: One of the main problems in testing Struts 1 Action is that the execute method depends on the Servlet API, which makes the testing of Action depend on the Web container. In order to test the Action of Struts 1 from the Web container, a third-party extension must be used: Struts TestCase, which contains a series of Mock objects (simulating the HttpServetRequest and HttpServletResponse objects), so that the Action class of Struts 1 can be tested from the Web container. Struts 2 Actions can be tested by initializing, setting properties, and calling methods.
5) Comparison of encapsulating request parameters: Struts 1 uses the ActionForm object to encapsulate the user's request parameters. All ActionForms must inherit a base class: ActionForm. Ordinary JavaBeans cannot be used as ActionForms, so developers must create a large number of ActionForm classes to encapsulate user request parameters. Although Struts 1 provides dynamic ActionForm to simplify the development of ActionForm, it still needs to define the ActionForm in the configuration file; Struts 2 directly uses the Action attribute to encapsulate the user request attribute, which avoids the tediousness of developers needing to develop a large number of ActionForm classes. In fact, These properties can also be Rich object types that contain sub-properties. If developers still miss the Struts 1 ActionForm mode, Struts 2 provides the ModelDriven mode, which allows developers to use a separate Model object to encapsulate user request parameters, but the Model object does not need to inherit any Struts 2 base class, it is a POJO, thus Reduced code pollution.
6) Comparison of expression language: Struts 1 integrates JSTL, so it can use JSTL expression language. This expression language has basic object graph traversal, but is less powerful in support of collections and indexed properties; Struts 2 can use JSTL, but it integrates a more powerful and flexible expression language: OGNL (Object Graph Notation Language), therefore, the expression language under Struts 2 is more powerful.
7) — Comparison of binding values ​​to views: Struts 1 uses standard JSP mechanisms to bind objects to view pages; Struts 2 uses "ValueStack" technology to enable tag libraries to access values ​​without binding objects to view pages together.
8) Comparison of type conversion: Struts 1 ActionForm properties are usually String type. Struts 1 uses Commons-Beanutils for type conversion, one converter per class, and the converter is not configurable; Struts 2 uses OGNL for type conversion, which supports conversion between basic data types and common objects.
9) Comparison of data validation: Struts 1 supports manual validation in the ActionForm rewrite validate method, or by integrating the Commons alidator framework to complete data validation. Struts 2 supports verification by overriding the validate method, and also supports the integration of the XWork verification framework for verification.
10) Comparison of Action execution control: Struts 1 supports each module corresponding to a request processing (ie the concept of life cycle), but all Actions in the module must share the same life cycle. Struts 2 supports creating different life cycles for each Action through Interceptor Stacks. Developers can create corresponding stacks as needed to use with different Actions.
11) Capture input: Struts1 uses the ActionForm object to capture input. All ActionForms must inherit from a base class. Because other JavaBeans cannot be used as ActionForms, developers often create redundant classes to capture input. Dynamic Beans (DynaBeans) can be used as the choice for creating traditional ActionForms, however, developers may be re-description (creating) existing JavaBeans (which still lead to redundant javabeans). Struts 2 uses Action properties directly as input properties, eliminating the need for a second input object. Input properties may be rich object types with their own (sub)properties. Action properties can be accessed through taglibs on web pages. Struts2 also supports ActionForm mode. Rich object types, including business objects, can be used as input/output objects. This ModelDriven feature simplifies taglib references to POJO input objects.