What is the difference between struts1 and struts2?

Today, during the interview, I asked the difference between struts1 and struts2. At that time, I did it. I found a complete one on the Internet and shared the following:

-Comparison of Action Implementation classes: struts 1 requires that action classes inherit one abstract base class. the specific problem of struts 1 is that abstract classes are used for programming rather than interfaces. The struts 2 Action class can implement one action interface or other interfaces to make optional and customized services possible. Struts
2. Provides an actionsupport base class to implement common interfaces. Even if the action interface is not required, only one pojo class containing the execute method can be used as the action of struts 2.

-Comparison of the thread mode: struts 1 action is a singleton mode and must be thread-safe, because only one instance of action is used to process all requests. The Singleton policy limits what struts 1 action can do and requires caution during development. Action resources must be thread-safe or synchronized; struts
2. The action object generates one instance for each request, so there is a thread security problem.

-Servlet dependency comparison: struts 1 action depends on servlet API, because the execute method of struts 1 action contains the httpservletrequest and httpservletresponse methods. Struts 2 Action no longer depends on Servlet
API to allow the action to run out of the Web Container, thus reducing the difficulty of testing the action. Of course, if action needs to directly access the httpservletrequest and httpservletresponse parameters, Struts 2 action can still access them. However, most of the time, actions do not need to directly access httpservetrequest and httpservletresponse, thus giving developers more flexible choices.

-Comparison of testability: one major problem in testing struts 1 action is that the execute method depends on the servlet API, which makes the test of action dependent on the Web container. To get rid of the Web container to test the action of struts 1, you must use the third-party Extension: struts
Testcase. This extension contains a series of mock objects (simulating the httpservetrequest and httpservletresponse objects), which can be used to test the action class of struts 1 from the Web container. Struts 2 action can be tested by initializing, setting properties, and calling the usage method.

-Comparison of encapsulated request parameters: struts 1 uses the actionform object to encapsulate the user's request parameters. All actionforms must inherit one base class: actionform. Normal JavaBean cannot be used as an actionform. Therefore, developers must create a large number of actionform classes to encapsulate user request parameters. Although struts
1. Dynamic actionform is provided to simplify the development of actionform, but actionform must still be defined in the configuration file. Struts 2 directly uses the action attribute to encapsulate the user request attributes, this avoids the hassle of developers developing a large number of actionform classes. In fact, such attributes can also be rich object types containing sub-attributes. If developers still miss the struts 1 actionform mode, Struts 2 provides the modeldriven mode, allowing developers to encapsulate user request parameters with separate model objects, however, this model object does not need to inherit any struts 2 base class and is a pojo, which reduces code pollution.

-Expression Language Comparison: struts 1 integrates jstl, so jstl can be used. This expression language provides basic object graph traversal, but does not have a strong function in support of set and index attributes. Struts 2 can use jstl, but it integrates a stronger and more flexible Expression Language: ognl (Object
Graph notation language). Therefore, the expression language function in struts 2 is more powerful.

-Comparison of binding values to views: struts 1 binds objects to view pages using the standard JSP mechanism; struts 2 uses the valuestack technology to enable the tag library to access values, instead of binding objects with view pages.

-Comparison of type conversion: the struts 1 actionform attribute is usually of the string type. Struts 1 uses commons-beanutils for type conversion. One converter for each class is not configurable. Struts 2 uses ognl for type conversion, supports conversion between basic data types and common objects.

-Data verification comparison: struts 1 supports manual verification in the actionform override validate method, or data verification by integrating the commons alidator framework. Struts 2 supports validation by rewriting the validate method, and also supports validation by integrating the xwork verification framework.

-Comparison of Action execution control: struts 1 supports one request processing (the concept of lifecycle) for each module. However, all actions in the module must share the same lifecycle. Struts 2 supports creating different lifecycles for each action through the interceptor stack (interceptor stacks. Developers can create corresponding stacks and use them with different actions.