Differences and comparison between struts1 and struts2

Differences and comparison between struts1 and struts2:

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.
• The 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 is used to 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 problems)

Servlet dependency:
• The struts1 action depends on the servlet API, because 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 attributes, and calling methods. "dependency injection" 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 input. Dynamic beans (dynabeans) can be used to create traditional actionforms. However, developers may re-describe (create) the existing JavaBean (which still leads 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 and therefore uses jstl el. 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 ).

Bind the value to the page (View ):
• Struts 1 uses the standard JSP mechanism to bind objects to pages 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 generally 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 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.

Control of Action execution:
• Struts1 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.