Jsp : Model 2 architecture – MVC

The Model 2 architecture for designing JSP pages is in reality, Model View Controller (MVC) applied to web applications. Hence the two terms can be used interchangeably in the web world. MVC originated in SmallTalk and has since made its way into Java community. Model 2 architecure and its derivatives are the cornerstones for all serious and industrial strength web applications designed
in the real world. Hence it is essential for you understand this paradigm thoroughly. Figure 1.2 shows the Model 2 (MVC) architecture.
The main difference between Model 1 and Model 2 is that in Model 2, a controller handles the user request instead of another JSP. The controller is implemented as a Servlet. The following steps are executed when the user submits the request. 

  1. The Controller Servlet handles the user’s request. (This means the hyperlink in the JSP should point to the controller servlet). 
  2. The Controller Servlet then instantiates appropriate JavaBeans based on the request parameters (and optionally also based on session attributes). 
  3. The Controller Servlet then by itself or through a controller helper communicates with the middle tier or directly to the database to fetch the required data. 
  4. The Controller sets the resultant JavaBeans (either same or a new one) in one of the following contexts – request, session or application. 
  5. The controller then dispatches the request to the next view based on the request URL. 
  6. The View uses the resultant JavaBeans from Step 4 to display data. Note that there is no presentation logic in the JSP. The sole function of the JSP in Model 2 architecture is to display the data from the JavaBeans set in the request, session or application scopes.


Advantages of Model 2 Architecture
Since there is no presentation logic in JSP, there are no scriptlets. This means lesser nightmares. [Note that although Model 2 is directed towards elimination of scriptlets, it does not architecturally prevent you from adding scriptlets. This has led to widespread misuse of Model 2 architecture.]
With MVC you can have as many controller servlets in your web application. In fact you can have one Controller Servlet per module. However there are several advantages of having a single controller servlet for the entire web application. In a typical web application, there are several tasks that you want to do for every incoming request. For instance, you have to check if the user requesting an operation is authorized to do so. You also want to log the user’s entry and exit from the web application for every request. You might like to centralize the logic for dispatching requests to other views. The list goes on. If you have several controller servlets, chances are that you have to duplicate the logic for all the above tasks in all those places. A single controller servlet for the web application lets you centralize all the tasks in a single place. Elegant code and easier to maintain.
Web applications based on Model 2 architecture are easier to maintain and extend since the views do not refer to each other and there is no presentation logic in the views. It also allows you to clearly define the roles and responsibilities in large projects thus allowing better coordination among team members.

JSP : Model 1 architecture

Model 1 architecture is the easiest way of developing JSP based web applications. It cannot get any easier. In Model 1, the browser directly accesses JSP pages. In other words, user requests are handled directly by the JSP.
Let us illustrate the operation of Model 1 architecture with an example. Consider a HTML page with a hyperlink to a JSP. When user clicks on the hyperlink, the JSP is directly invoked. This is shown in Figure below. The servlet container parses the JSP and executes the resulting Java servlet. The JSP contains embedded code and tags to access the Model JavaBeans. The Model JavaBeans contains attributes for holding the HTTP request parameters from the query string. In addition it contains logic to connect to the middle tier or directly to the database using JDBC to get the additional data needed to display the page. The JSP is then rendered as HTML using the data in the Model JavaBeans and other Helper classes and tags. 


Problems with Model 1 Architecture

Model 1 architecture is easy. There is some separation between content (Model JavaBeans) and presentation (JSP). This separation is good enough for  smaller applications. Larger applications have a lot of presentation logic. In Model 1 architecture, the presentation logic usually leads to a significant amount of Java code embedded in the JSP in the form of scriptlets. This is ugly and  maintenance nightmare even for experienced Java developers. In large applications, JSPs are developed and maintained by page authors. The intermingled scriptlets and markup results in unclear definition of roles and is very problematic.
Application control is decentralized in Model 1 architecture since the next page to be displayed is determined by the logic embedded in the current page. Decentralized navigation control can cause headaches. All this leads us to Model 2 architecture of designing JSP pages.

Web.xml Servlet Configuration

For a Java servlet to be accessible from a browser, you must tell the servlet container what servlets to deploy, and what URL’s to map the servlets to. This is done in the web.xml file of your Java web application.

Here is a list of the topics covered in this text about the web.xml servlet configuration:

  1. Configuring and Mapping a Servlet
  2. Servlet Init Parameters
  3. Servlet Load-on-Startup
  4. Context Parameters

Configuring and Mapping a Servlet

To configure a servlet in the web.xml file, you write this:

<!--DOCTYPE web-app
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"



First you configure the servlet. This is done using the <servlet> element. Here you give the servlet a name, and writes the class name of the servlet.

Second, you map the servlet to a URL or URL pattern. This is done in the <servlet-mapping>element. In the above example, all URL’s ending in .html are sent to the servlet.

Other possible servlet URL mappings are:




The * is a wild card, meaning any text. As you can see, you can either map a servlet to a single, specific URL, or to a pattern of URL’s, using a wild card (*). What you will use depends on what the servlet does.

Servlet Init Parameters

You can pass parameters to a servlet from the web.xml file. The init parameters of a servlet can only be accessed by that servlet. Here is how you configure them in the web.xml file:


Here is how you read the init parameters from inside your servlet – in the servlets init() method:

public class SimpleServlet extends GenericServlet {

  protected String myParam = null;

  public void init(ServletConfig servletConfig) throws ServletException{
    this.myParam = servletConfig.getInitParameter("myParam");

  public void service(ServletRequest request, ServletResponse response)
        throws ServletException, IOException {

    response.getWriter().write("myParam = " +
            this.myParam + "");

A servlets init() method is called when the servlet container loads the servlet for the first time. No one can access the servlet until the servlet has been loaded, and the init() method has been called successfully.

Servlet Load-on-Startup

The <servlet> element has a subelement called <load-on-startup> which you can use to control when the servlet container should load the servlet. If you do not specify a <load-on-startup> element, the servlet container will typically load your servlet when the first request arrives for it.

By setting a <load-on-startup> element, you can tell the servlet container to load the servlet as soon as the servlet container starts. Remember, the servlets init() method is called when the servlet is loaded.

Here is an example <load-on-startup> configuration:


The number inside the <load-on-startup>1</load-on-startup> element tells the servlet container in what sequence the servlets should be loaded. The lower numbers are loaded first. If the value is negative, or unspecified, the servlet container can load the servlet at any time.

Context Parameters

You can also set some context parameters which can be read from all servlets in your application. Here is how you configure a context parameter:

    <param-value>the value</param-value>

Here is how you access the parameter from inside an HttpServlet subclass:

String myContextParam =

What is Servlet Mapping ?

Servlet mapping specifies the web container of which java servlet should be invoked for a url given by client. It maps url patterns to servlets. When there is a request from a client, servlet container decides to which application it should forward to. Then context path of url is matched for mapping servlets.

How is servlet mapping defined?

Servlets should be registered with servlet container. For that, you should add entries in web deployment descriptor web.xml. It is located in WEB-INF directory of the web application.
Entries to be done in web.xml for servlet-mapping:


servlet-mapping has two child tags, url-pattern and servlet-name. url-pattern specifies the type of urls for which, the servlet given in servlet-name should be called. Be aware that, the container will use case-sensitive for string comparisons for servlet matching.

Syntax for servlet mapping as per servlet specification SRV.11.2:

A string beginning with a ‘/’ character and ending with a ‘/*’ suffix is used for path mapping.
A string beginning with a ‘*.’ prefix is used as an extension mapping.
A string containing only the ‘/’ character indicates the “default” servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null.

All other strings are used for exact matches only.

Rule for URL path mapping:

It is used in the following order. First successful match is used with no further attempts.

1. The container will try to find an exact match of the path of the request to the path of the servlet. A successful match selects the servlet.
2. The container will recursively try to match the longest path-prefix. This is done by stepping down the path tree a directory at a time, using the ’/’ character as a path separator. The longest match determines the servlet selected.
3. If the last segment in the URL path contains an extension (e.g. .jsp), the servlet container will try to match a servlet that handles requests for the extension. An extension is defined as the part of the last segment after the last ’.’ character.
4. If neither of the previous three rules result in a servlet match, the container will attempt to serve content appropriate for the resource requested. If a “default” servlet is defined for the application, it will be used.

What is implicit mapping?

A servlet container can have a internal JSP container. In such case, *.jsp extension is mapped to the internal container. This mapping is called implicit mapping. This implicit mapping allows ondemand execution of JSP pages. Servlt mapping defined in web application has high precedence over the implicit mapping.

Example code for java servlet mapping:



What is Servlet Invoker?

As defined by Apache Tomcat specification, the purpose of Invoker Servlet is to allow a web application to dynamically register new servlet definitions that correspond with a element in the /WEB-INF/web.xml deployment descriptor.By enabling servlet invoker the servlet mapping need not be specified for servlets. Servlet ‘invoker’ is used to dispatch servlets by class name.

Enabling the servlet invoker can create a security hole in web application. Because, Any servlet in classpath even also inside a .jar could be invoked directly. The application will also become not portable. Still if you want to enable the servlet invoker consult the web server documentation, because every server has a different method to do it.

In Tomcat 3.x, by default the servlet invoker is enabled. Just place the servlets inside /servlet/ directory and access it by using a fully qualified name like http://%5Bdomain%5D:%5Bport%5D/%5Bcontext%5D/servlet/%5Bservlet.
This mapping is available in web application descriptor (web.xml), located under $TOMCAT_HOME/conf.

/servlet/ is removed from Servlet 2.3 specifications.
In Tomcat 4.x, by defaul the servlet invoker id disabled. The tag is commented inside the default web application descriptor (web.xml), located under $CATALINA_HOME/conf. To enable the invoker servlet uncomment the following two blocks.

<!–– The mapping for the invoker servlet –>