Let us see the component and functional differences between struts 1.x and struts 2.x

In 2.x we have Interceptors instead RequestProcessor will see about this concept later just remember as of now

In 2.x we do not have multiple libraries, instead we have single library which includes all tags

In struts 1.x the configuration fine name can be [any name].xml and we used to place in web-inf folder

In 2.x the configuration file must be struts.xml only and this must be in classes folder

In 2.x form bean, Action classes are combinedly given as Action class only, of course we can take separately if we want

But in 2.x we need to configure our resource bundle(s) in struts.properties file

In 2.x we have annotations support too along with programmatic and declarative validations

Functional Differences

In 2.x, declarative validations are done by using xwork2 frame work by webwork the reason being, its support valuations through Annotations

In struts 1.x an Action class is a single ton class, so Action class object is not a thread safe, as a programmer we need to make it as thread safe by applying synchronization

In 2.x an Action class object will be created for each request, so it is by default thread safe, so we no need to take care about safety issues here

In 2.x we have support of multiple view technologies like velocity, Freemarker, jasper reports, jsp bla bla

In struts 1.x Action class is having servlet dependency, because in execute() method accepts req, res parameter right ! so.

In 2.x Action class doesn’t have any servlet dependency, because its execute() method doesn’t accepts any parameters, however we can access all servlet objects with dependency injection

Struts Execution Flow Diagram, How Struts Works

Execution flow of struts

When a client request is given, a web container will receive request
Web container loads web.xml and verifies whether the url-patterns are verified or not, if matches web-container transfer the request to FilterDispatcher
FilterDispatcher hand overs the request to ActionProxy, it is a proxy class which is responsible to apply before and after services to original business logic
ActionProxy contacts ConfiguraionManager class, to know the suitable Action for the request and the needed services for the request
ConfigurationManager class loads structs.xml and provides the required information back to ActionProxy
ActionPorxy delegates the request along with its information to ActionInvocation
ActionInvocation executes the interceptors added to an Action from 1 – N, after that it will calls the business logic implemented from N – 1 in reverse order
ActionInvocation receives finally result produced by an action aclass
ActionProxy transfers the result back to FilterDispatcher
FilterDispatcher selects an appropriate view, basing on the result
Finally FilterDispatcher uses RequestDispatchers forwarding mechanism and forward a view as a response back to the client