ActionServlet provides the "controller" in the Model-View-Controller (MVC) design pattern for web applications that is commonly known as "Model 2". This nomenclature originated with a description in the JavaServerPages Specification, version 0.92, and has persisted ever since (in the absence of a better name).

Generally, a "Model 2" application is architected as follows:

• The user interface will generally be created with server pages, which will not themselves contain any business logic. These pages represent the "view" component of an MVC architecture.
• Forms and hyperlinks in the user interface that require business logic to be executed will be submitted to a request URI that is mapped to this servlet.
• There can be one instance of this servlet class, which receives and processes all requests that change the state of a user's interaction with the application. The servlet delegates the handling of a request to a RequestProcessor object. This component represents the "controller" component of an MVC architecture.
• The RequestProcessor selects and invokes an Action class to perform the requested business logic, or delegates the response to another resource.
• The Action classes can manipulate the state of the application's interaction with the user, typically by creating or modifying JavaBeans that are stored as request or session attributes (depending on how long they need to be available). Such JavaBeans represent the "model" component of an MVC architecture.
• Instead of producing the next page of the user interface directly, Action classes generally return an ActionForward to indicate which resource should handle the response. If the Action does not return null, the RequestProcessor forwards or redirects to the specified resource (by utilizing RequestDispatcher.forward or Response.sendRedirect) so as to produce the next page of the user interface.

The standard version of RequestsProcessor implements the following logic for each incoming HTTP request. You can override some or all of this functionality by subclassing this object and implementing your own version of the processing.

• Identify, from the incoming request URI, the substring that will be used to select an action procedure.
• Use this substring to map to the Java class name of the corresponding action class (an implementation of the Action interface).
• If this is the first request for a particular Action class, instantiate an instance of that class and cache it for future use.
• Optionally populate the properties of an ActionForm bean associated with this mapping.
• Call the execute method of this Action class, passing on a reference to the mapping that was used, the relevant form-bean (if any), and the request and the response that were passed to the controller by the servlet container (thereby providing access to any specialized properties of the mapping itself as well as to the ServletContext).

The standard version of ActionServlet is configured based on the following servlet initialization parameters, which you will specify in the web application deployment descriptor (/WEB-INF/web.xml) for your application. Subclasses that specialize this servlet are free to define additional initialization parameters.

• config - Comma-separated list of context-relative path(s) to the XML resource(s) containing the configuration information for the default module. (Multiple files support since Struts 1.1) [/WEB-INF/struts-config.xml].
• config/${module} - Comma-separated list of Context-relative path(s) to the XML resource(s) containing the configuration information for the module that will use the specified prefix (/${module}). This can be repeated as many times as required for multiple modules. (Since Struts 1.1)
• configFactory - The Java class name of the ModuleConfigFactory used to create the implementation of the ModuleConfig interface. [org.apache.struts.config.impl.DefaultModuleConfigFactory]
• convertNull - Force simulation of the Struts 1.0 behavior when populating forms. If set to true, the numeric Java wrapper class types (like java.lang.Integer) will default to null (rather than 0). (Since Struts 1.1) [false]
• rulesets - Comma-delimited list of fully qualified classnames of additional org.apache.commons.digester.RuleSet instances that should be added to the Digester that will be processing struts-config.xml files. By default, only the RuleSet for the standard configuration elements is loaded. (Since Struts 1.1)
• validating - Should we use a validating XML parser to process the configuration file (strongly recommended)? [true]