What is the difference between Struts2.0 and Struts1.0 in Java programming?

Difference between the two: 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 rather than interfaces. ◆ Struts 2 Action class can implement an Action interface or other interfaces to make optional and customized services possible. Struts2 provides an ActionSupport base class to implement common interfaces. The Action interface is not required. Any POJO object with the execute identifier can be used as the Action object of Struts2. Thread mode: ◆ Struts1 Action is a singleton mode and must be thread-safe, because only one instance of Action can process all requests. The Singleton policy limits what Struts1 actions can do and requires caution during development. Action resources must be thread-safe or synchronized. ◆ The Struts2 Action object generates an instance for each request, so there is no thread security problem. (In fact, the servlet container generates many discarded objects for each request without causing performance and garbage collection issues) Servlet dependency: ◆ Struts1 Action depends on the Servlet API, when an Action is called, HttpServletRequest and HttpServletResponse are passed to the execute method. ◆ Struts 2 Action does not depend on the container, allowing the Action to be tested independently from the container. If necessary, Struts2 Action can still access the initial request and response. However, other elements reduce or eliminate the need to directly access HttpServetRequest and HttpServletResponse. Testability: ◆ a major problem in testing 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 simulated objects for testing ). ◆ Struts 2 Action can be tested through initialization, setting properties, and calling methods. "dependency injection" support also makes testing easier. Capture input: ◆ Struts1 uses the ActionForm object to capture input. All actionforms must inherit a base class. Because other JavaBean cannot be used as an ActionForm, developers often create redundant class capture inputs. Dynamic beans (DynaBeans) can be used as an option to create a traditional ActionForm. However, developers may re-describe (create) the existing JavaBean (which will still lead to redundant javabean ). ◆ Struts 2 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 integrates JSTL, so jstl el is used. This kind of EL has basic object graph traversal, but the support for set and index attributes is weak. ◆ Struts2 can use JSTL, but also supports a stronger and more flexible Expression Language-"Object Graph Notation Language" (OGNL ). binding value to the page (view): ◆ Struts 1 uses the standard JSP mechanism to bind the object to the page for access. ◆ Struts 2 uses the "ValueStack" technology to enable taglib to access values without binding your page (view) and objects. 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 Struts 1 ActionForm attribute is usually of the String type. Struts1 uses Commons-Beanutils for type conversion. One converter for each class is not configurable for each instance. ◆ Struts2 uses OGNL for type conversion. Provides Converters for basic and common objects. Verification: ◆ Struts 1 supports manual verification in the validate method of ActionForm, or verification 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 content validation defined for the attribute class type to support control the execution of the chain checksum subattribute Action: ◆ Struts1 supports a separate Request Processors (lifecycle) for each module ), however, 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.