2. the required FilterDispatcher is called, which in turn consults the ActionMapper to determine if the request should invoke an action.
3. The ActionMapper interface provides a mapping between HTTP requests and action invocation requests and vice-versa.
When given an HttpServletRequest, the ActionMapper may return null if no action invocation request matches, or it may return an ActionMapping that describes an action invocation for the framework to try.If the ActionMapper determines that an Action should be invoked, the FilterDispatcher delegates control to the ActionProxy.
4. The ActionProxy consults the framework Configuration Files manager (initialized from the struts.xml file).
5. the ActionProxy creates an ActionInvocation, which is responsible for the command pattern implementation. This includes invoking any Interceptors (the before clause) in advance of invoking the Action itself.
6. Once the Action returns, the ActionInvocation is responsible for looking up the proper result associated with the Action result code mapped in struts.xml.
7. The result is then executed, which often (but not always, as is the case for Action Chaining) involves a template written in JSP or FreeMarker to be rendered.
8. While rendering, the templates can use the Struts Tags provided by the framework.
9. All objects in this architecture (Actions, Results, Interceptors, and so forth) are created by an ObjectFactory.
This ObjectFactory is pluggable. We can provide our own ObjectFactory
A popular ObjectFactory implementation uses Spring as provided by the Spring Plugin.
Normally, in struts.xml you specify the class for each Action. When using the default SpringObjectFactory, the framework will ask Spring to create the Action and wire up dependencies as specified by the default auto-wire behavior.
10. Interceptors are executed again (in reverse order, calling the after clause).
11. Finally, the response returns through the filters configured in the web.xml.
don't know how to setup simple struts2 project? see simple setup