The WebWork architecture can best be explained with a diagram:diagram describes the framework's architecture.
In the diagram, an initial request goes to the Servlet container (such as Tomcat Jetty or Resin) , the request goes through the which is passed through a standard filter chain. This The chain includes the (optional) ActionContextCleanUp filter, which is required if you wish to integrate in with useful when integrating technologies such as SiteMesh Plugin. Next, the required FilterDispatcher is called, which in turn consults the ActionMapper to determine if the request should invoke an action.
If the ActionMapper determines that an action Action should be invoked, the FilterDispatcher than delegates control to the ActionProxy, which in turn ActionProxy. The ActionProxy consults the WebWork framework Configuration manager, which finally reads your xworkFiles manager (initialized from the struts.xml file). Next, the ActionProxy creates an ActionInvocation, which is responsible for the command pattern implementation. This includes invoking any interceptors Interceptors (the before() method) before finally clause) in advance of invoking the action Action itself.
Once the action Action returns, the ActionInvocation is responsible for looking up the proper result associated with the action Action result code mapped in xwork struts.xml. 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. While rendering, the templates can utilize use the Struts Tags and UI Components provided by WebWorkthe framework. Some of those components will work with the ActionMapper to render proper URLs for additional requests.
| Note |
|---|
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 for any reason that requires knowing when objects in the framework are created. A popular ObjectFactory implementation uses Spring as provided by the Spring Plugin. |
Interceptors Finally, the interceptors are executed again (in reverse order, calling the after() method) and finally returning back clause). Finally, the response returns through the filters configured in the web.xml. If the ActionContextCleanUp filter is present, the FilterDispatcher will not clean up the ThreadLocal ActionContext. If the ActionContextCleanUp filter is not present, the FilterDispatcher will cleanup all ThreadLocals.