Differences between struts1 and strut2

Struts1 and struts2 are two completely different frameworks.

Struts1 workflow:
Initialize ActionServlet and ActionContext based on Web. xml when publishing Struts web Services.
After receiving an HttpRequest request, ActionServlet uploads the request parameters to the corresponding Formbean according to the configuration content in the struts-config.xml and sets the session. then, based on the Action parameter in the request, find the specified Action in the struts-config.xml and call this Action to process the request. according to the processing result of the Action, a forward variable is returned. findForward () finds the Action or JSP page marked by the corresponding forward, and forwards the request to the next processing. if forward points to the JSP page, it is output to the foreground.

Struts2 workflow:
(1) The client submits an HttpServletRequest request (. action or JSP page)
(2) The request is submitted to a series of Filter filters, such as ActionCleanUp and FilterDispatcher.
(3) FilterDispatcher is the core of the Struts2 controller. It is usually the last filter in the filter chain.
(4) After a Request is sent to FilterDispatcher, FilterDispatcher queries whether ActionMapper needs to call an Action to process the Request (usually determined based on whether the URL suffix is. action)
(5) If ActionMapper decides to call an Action, FilterDispatcher submits the request to ActioProxy for processing.
(6) ActionProxy queries the framework Configuration file through Configuration Manager (which will access struts. xml) and finds the Action class to be called.
(7) ActionProxy creates an ActionInvocation instance, while ActionInvocation calls Action in proxy mode (all the Interceptor interceptors related to the configuration file will be loaded before the call)
(8) after the Action is executed, a result string is returned, and the Interceptor is used in reverse order.
(9) Finally, ActionInvocation is responsible for finding the result corresponding to the returned value based on the result element configured in struts. xml and deciding on the next output.

 

Differences:

/** Action class
Struts1 requires the Action class to inherit an abstract class. Struts1 uses the abstract class programming instead of the interface.
Struts2 can implement the Action interface or not. Struts2 provides an ActionSuport base class to implement common interfaces. The Action interface is not required. Any POJO with the execute identifier may become the Action object of struts2.

/** Thread mode
The Action of Struts1 is a singleton mode and thread-safe. Only one Action instance is used to process all requests. The single-policy mode limits what Struts1 Action can do. During development, note that Action resources must be thread-safe and synchronous.
The Action object of Struts2 generates an instance for each request, so there is no thread security problem.

/** 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.
The Struts2 Action does not depend on the container and allows the Action to be tested independently from the container. If necessary, struts2 can still access the initial request and response. However, other elements reduce or eliminate the need to directly access HttpServletRequest and HttpServletResponse.

/** Expression Language
Struts1 integrates JSTL, so jstl el is used. This EL has basic object graph traversal, but its support for set and index attributes is very weak.
Struts2 can use JSTL, but it also supports a stronger and more flexible Expression Language-"object graph Notation Language" (OGNL)

/** Verification
Struts1 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 validity 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 an infeasible life cycle for each Action through Interceptor Stacks. The stack can be used with different actions as needed.

/** Type conversion
The Struts1 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 and provides Converters for basic and common objects.

/** Bind the value to the page (view)
Struts1 uses the standard JSP mechanism to bind an object to the page for access.
Struts2 uses the ValueStack technology to enable taglib to access values without binding your page (view) and object. The ValueStack policy allows you to use a series of attributes with the same name but different types to repeat the page (view)

/** Capture input:
Struts1 uses the ActionForm object to capture input. All actionforms must inherit one base class. Because other JavaBean cannot be used as an ActionForm, developers often create unnecessary base classes or input them. 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 a sunk JavaBean ).

Struts2 directly uses the Acrtion attribute as the INPUT attribute, eliminating the request 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. Richard object type, including business objects, which can be used as input/output objects. This ModelDriven feature simplifies Taglib's reference to POJO input objects.