When the Framework is loaded, it first loaded the Web.xml
file. Then from the Servlet tag of Web.xml, it identifies
the ActionServlet(or the Struts-Cofig.xml). Then from
welcome-file tag of Struts-Cofig.xml, it identifies the
first JSP page and runs it. Then when the request comes
through that jsp, from acion-mappings tag of Struts-
Cofig.xml it identifies the request, through path tag
(request name) and input tag (jsp name), through name tag
it identifies which bean is needed to access the data and
through type tag it identifies which Action should be
invoked. Then through the forward tag it identifies to
which jsp it has to forward the response.
When any struts based web application loaded into server
initially it will load the ActionServlet class, due to
<load-on-startup> tag in web.xml. After instantiation it
will read struts-config.xml file, due to <init-param> tag in
web.xml. When anybody makes request to the respective web
application it will display the file which is mentioned in
<welcome-file-list> tag of web.xml file. When the view
page(.jsp) is displayed to the user internally the struts
framework (ActionServlet) will create an object for the form
bean class (which extends the ActionForm by calling zero
argument constructor(default construtor)) which is mapped
with the Action class path mentioned in .jsp file <html:form
action="/path"> b'coz ActionServlet already read the
information mentioned in struts-config.xml file. later it
will call the reset() and all the getter methods of the form
bean class. when the user fills the form and submit the
input, our form bean class again calls the default
constructor, reset(), all setter() methods, validate()
methods respectively. Validate method return ActionErrors
object. If the ActionErrors object contains any error
values(ActionError/ActionMessage values) then the
ActionServlet calls the input page mapped with respective
action class(<action input="/input.jps") that page will
display to the user with error messages. If ActionErrors
object is null(doesn't contains any ActionError/
ActionMessage) then the ActionServlet calls the execute()
method of the Action class which is bind with input request
(<action path="/path" type="package.OurActionClass"). the
execute() method will return ActionForward object. Depend on
the value, again the ActionServlet will call the respective
view(.jps page) as response and send it back to user. For
processing all the above steps ActionServlet will take the
help with RequestProcessor class. In this way one request
will be processed by the struts framework. And ActionServlet
will act as a front controllet for the application.
The request is given to Action Servlet i.e; doGet or
ActionServlet with the help of request uri locates one of
the RequestProcessor and dispatch the request to
RequestProcessor i.e; process method on RequestProcessor is
It processes content type.
After processing action(i.e; execute method) depending on
the results locate the path to view(with the help of
ActionMapping) and dispatch the request to the located
From Jsp page the controller looks into <form>tag with that
it enters into the web.xml, in web.xml it checks the <url-
pattern> tag, and it maps with <servlet-name> tag in
<servlet-mapping> tag, again it checks with <servlet-name>
which is there in <servlet> tag, it looks for corresponding
<servlet-class>.The Controller goes in strus-config.xml
from the it controller checks with the (req name) both in
<action> and <form-bean> if it is matching it will look
into the FormBean class.In FormBean class we have to write
setters and getters for the form input fields which are
there in Jsp page.Then the req is forwadard to Action
class. In Action class it will do some business logic based
on the requirement.
Struts request lifecycle
In this section you will learn about the Struts controller
classes – ActionServlet, RequestProcessor, ActionForm,
Action,ActionMapping and ActionForward – all residing in
org.apache.struts.action package and struts-config.xml – the
Struts Configuration file. Instead of the traditional "Here
is the class – go use it" approach, you will study the
function of each component in the context of HTTP request
handling lifecycle in Struts.
The central component of the Struts Controller is the
ActionServlet. It is a concrete class and extends the
javax.servlet.HttpServlet. It performs two important things.
1. On startup, its reads the Struts Configuration file and
loads it into memory in the init() method.
2. In the doGet() and doPost() methods, it intercepts HTTP
request and handles it appropriately.
The name of the Struts Config file is not cast in stone. It
is a convention followed since the early days of Struts to
call this file as struts-config.xml and place it under the
WEB-INF directory of the web application. In fact you can
name the file anyway you like and place it anywhere in
WEB-INF or its subdirectories. The name of the Struts Config
file can be configured in web.xml. The web.xml entry for
configuring the ActionServlet and Struts Config file is as
In the above snippet, the Struts Config file is present in
the WEB-INF/config directory and is named myconfig.xml. The
ActionServlet takes the Struts Config file name as an
init-param. At startup, in the init() method, the
ActionServlet reads the Struts Config file and creates
appropriate Struts configuration objects (data structures)
into memory. For now, assume that the Struts Config file is
loaded into a set of objects in memory, much like a
properties file loaded into a java.util.Properties class.
Like any other servlet, ActionServlet invokes the init()
method when it receives the first HTTP request from the
caller. Loading Struts Config file into configuration
objects is a time consuming task. If the Struts
configuration objects were to be created on the first call
from the caller, it will adversely affect performance by
delaying the response for the first user. The alternative is
to specify load-on-startup in web.xml as shown above. By
specifying load-onstartup to be 1, you are telling the
servlet container to call the init() method immediately on
startup of the servlet container.
The second task that the ActionServlet performs is to
intercept HTTP requests based on the URL pattern and handles
them appropriately. The URL pattern can be either path or
suffix. This is specified using the servlet-mapping in
web.xml. An example of suffix mapping is as follows.
If the user types
http://localhost:8080/xyz/submitCustomerForm.do in the
browser URL bar, the URL will be intercepted and processed
by the ActionServlet since the URL has a pattern *.do, with
a suffix of "do". Once the ActionServlet intercepts the HTTP
request, it doesn't do much. It delegates the request
handling to another class called RequestProcessor by
invoking its process()method. Most of the Struts Controller
functionality is embedded in the process() method of
RequestProcessor class. Mastery over this flowchart will
determine how fast you will debug problems in real life
Struts applications. Let us understand the request handling
in the process() method step by step with an example covered
in the next several sub sections.
RequestProcessor and ActionMapping
The RequestProcessor does the following in its process() method:
Step 1: The RequestProcessor first retrieves appropriate XML
block for the URL from struts-config.xml. This XML block is
referred to as ActionMapping in Struts terminology. In fact
there is a class called ActionMapping in
org.apache.struts.action package. ActionMapping is the class
that does what its name says – it holds the mapping between
a URL and Action. A sample ActionMapping from the Struts
configuration file looks as follows.
Step 2: The RequestProcessor looks up the configuration file
for the URL pattern /submitDetailForm. (i.e. URL path
without the suffix do) and finds the XML block
(ActionMapping) shown above. The type attribute tells Struts
which Action class has to be instantiated. The XML block
also contains several other attributes. Together these
constitute the JavaBeans properties of the ActionMapping
instance for the path /submitDetailForm. The above
ActionMapping tells Struts to map the URL request with the
path /submitDetailForm to the class
mybank.example.CustomerAction. The Action class is explained
in the steps ahead. For now think of the Action as your own
class containing the business logic and invoked by Struts.
This also tells us one more important thing. Since each HTTP
request is distinguished from the other only by the path,
there should be one and only one ActionMapping for every
path attribute. Otherwise Struts overwrites the former
ActionMapping with the latter.
Another attribute in the ActionMapping that you should know
right away is name. It is the logical name of the ActionForm
to be populated by the RequestProcessor. After selecting the
ActionMapping, the RequestProcessor instantiates the
ActionForm. However it has to know the fully qualified class
name of the ActionForm to do so. This is where the name
attribute of ActionMapping comes in handy. The name
attribute is the logical name of the ActionForm. Somewhere
else in struts-config.xml, you will find a declaration like
This form-bean declaration associates a logical name
CustomerForm with the actual class mybank.example.CustomerForm.
Step 3: The RequestProcessor instantiates the CustomerForm
and puts it in appropriate scope – either session or
request. The RequestProcessor determines the appropriate
scope by looking at the scope attribute in the same
Step 4: Next, RequestProcessor iterates through the HTTP
request parameters and populates the CustomerForm properties
of the same name as the HTTP request parameters using Java
Introspection. (Java Introspection is a special form of
Reflection using the JavaBeans properties. Instead of
directly using the reflection to set the field values, it
uses the setter method to set the field value and getter
method to retrieve the field value.)
Step 5: Next, the RequestProcessor checks for the validate
attribute in the ActionMapping. If the validate is set to
true, the RequestProcessor invokes the validate() method on
the CustomerForm instance. This is the method where you can
put all the html form data validations. For now, let us
pretend that there were no errors in the validate() method
and continue. We will come back later and revisit the
scenario when there are errors in the validate() method.
Step 6: The RequestProcessor instantiates the Action class
specified in the ActionMapping (CustomerAction) and invokes
the execute() method on the CustomerAction instance. The
signature of the execute method is as follows.
public ActionForward execute(ActionMapping
request,HttpServletResponse response) throws Exception
Apart from the HttpServletRequest and HttpServletResponse,
the ActionForm is also available in the Action instance.
This is what the ActionForm was meant for; as a convenient
container to hold and transfer data from the http request
parameter to other components of the controller, instead of
having to look for them every time in the http request.
The execute() method itself should not contain the core
business logic irrespective of whether or not you use EJBs
or any fancy middle tier. The first and foremost reason for
this is that business logic classes should not have any
dependencies on the Servlet packages. By putting the
business logic in the Action class, you are letting the
javax.servlet.* classes proliferate into your business
logic. This limits the reuse of the business logic, say for
a pure Java client. The second reason is that if you ever
decide to replace the Struts framework with some other
presentation framework (although we know this will not
happen), you don't have to go through the pain of modifying
the business logic. The execute() method should preferably
contain only the presentation logic and be the starting
point in the web tier to invoke the business logic. The
business logic can be present either in protocol independent
Java classes or the Session EJBs.
The RequestProcessor creates an instance of the Action
(CustomerAction), if one does not exist already. There is
only one instance of Action class in the application.
Because of this you must ensure that the Action class and
its attributes if any are thread-safe. General rules that
apply to Servlets hold good. The Action class should not
have any writable attributes that can be changed by the
users in the execute() method.
User clicks on a link in an HTML page
Servlet controller receives the request, looks up mapping information in struts-config.xml, and routes to an action.
Action makes a call to a Model layer service.
Service makes a call to the Data layer (database) and the requested data is returned.
Service returns to the action.
Action forwards to a View resource (JSP page)
Servlet looks up the mapping for the requested resource and forwards to the appropriate JSP page.
JSP file is invoked and sent to the browser as HTML.
User is presented with a new HTML page in a web browser.
Please find the below ural for struts life cycle digram.
suppose one form having name,age two fields and one submit
button. when ever enter the two fields and submit button.
the request goes to web.xml. the request check in the struts
config.file. the related form bean and action class will be
executing. then related redirect page.