[Java/jsp] Comparison of struts1.x and struts2.x

characteristic	struts1.x	Struts2
Action class	struts1.x requires the action class to be extended from an abstract base class. A common problem with struts1.x is programming for abstract classes rather than interface-oriented programming.	The STRUTS2 action class implements an action interface, along with other interfaces, to implement optional and custom services. STRUTS2 provides a base class called Actionsupport to implement commonly used interfaces. Of course, the action interface is not required. Any Pojo object that uses the Execute method can be used as the action object for Struts 2.
Threading Model	The struts1.x action class is a singleton class, because there is only one instance to control all requests. A single example class policy creates some limitations and brings additional annoyance to development. The action resource must be thread safe or synchronized.	The Struts2 Action object instantiates objects for each request, so there is no thread-safe problem. (In practice, the servlet container produces many discarded objects for each request, and does not cause performance and garbage collection issues).
Servlet reliance on	The struts1.x action class relies on the servlet API to pass the Execute method with HttpServletRequest and httpservletresponse as arguments when the action is invoked.	The Struts2 action has nothing to do with the container. The servlet context is represented as a simple maps that allows the action to be independently tested. The Struts2 action can access the initial request, if necessary. However, if possible, avoid or exclude other elements from accessing HttpServletRequest or HttpServletResponse directly.
Ease of measurement	The main problem with testing struts1.x is that the Execute method exposes the Servlet API, which makes testing dependent on the container. Third-party extensions, such as Struts TestCase, provide a set of Struts1 mock objects (for testing).	STRUTS2 action can be tested by initializing, setting properties, and invoking methods. Dependency Injection support is also easier to test.
Capture Input	Struts1.x uses the Actionform object to capture the input. Like an action, all actionform must extend the base class. Because other JavaBean cannot be used as actionform, developers often create redundant classes to capture input. Dynabeans can be created as an alternative to the Actionform class. However, the developer may be recreating (creating) an already existing JavaBean (still leading to redundant javabean).	STRUTS2 uses the action attribute directly as an input property, eliminating the need for the second input object. The input property may be a rich object type with its own (child) attribute. The action attribute can be accessed through taglibs on a Web page. STRUTS2 also supports Actionform mode. Rich object types, including business objects, that can be used as input/output objects. This modeldriven feature simplifies taglib references to pojo input objects.
Expression Language	struts1.x consolidates Jstl, so it uses the JSTL expression language. Expression languages have basic graphics object movement, but support for collections and indexed properties is weak.	Struts2 uses JSTL, but it also supports a more powerful and flexible expression language-"Object Graph notation Language" (OGNL).
to bind a value to a page	Struts1.x uses standard JSP mechanisms to bind objects to the page context.	Struts2 uses the "valuestack" technique to enable taglib to access values without having to bind your page (view) to the object. The Valuestack policy allows pages (view) to be reused through a series of properties with the same name but different types.
Type Conversions	Struts1.x's Actionform properties are often string. Struts 1.x uses Commons-beanutils for type conversions. Convert each class, instead of configuring it for each instance.	STRUTS2 uses OGNL for type conversions. A converter that provides basic and commonly used objects.
Validate	struts1.x supports manual checksums in the Actionform validate method, or through Commons Validator extension to verify. The same class can have different checksum content, but cannot validate child objects.	STRUTS2 supports validation through the Validate method and the Xwork checksum framework. The Xwork validation Framework supports chain checksum properties using the checksum content checksum defined for the attribute class type
Action Execution Control	struts1.x supports each module with a separate request processors (lifecycle), but all the action in the module must share the same life cycle.	STRUTS2 supports creating different lifecycles for each action through the Interceptor Stack (Interceptor Stacks). The stack can be used in conjunction with different action as needed.