MVC for Servlets
26-Jul-16
MVC


One of the most common Design Patterns is ModelView-Controller (MVC)
The model does all the computational work



The controller tells the model what to do


It is input/output free
All communication with the model is via methods
User input goes to the controller
The view shows results; it is a “window” into the model


The view can get results from the controller, or
The view can get results directly from the model
2
Advantages of MVC

One advantage is separation of concerns



Another advantage is flexibility


The GUI (if one is used) can be completely revamped without
touching the model in any way
Another big advantage is reusability


Computation is not intermixed with I/O
Consequently, code is cleaner and easier to understand
The same model used for a servlet can equally well be used
for an application or an applet (or by another process)
MVC is widely used and recommended
3
MVC for servlets

The model, as usual, does all the computational work,
and no I/O


The servlet class (the one that extends HttpServlet)
acts as the controller



The model can consist of multiple classes
The servlet gives any relevant information from the user
request to the model
The servlet takes the results and passes them on to the view
The view—that is, the HTML page that is returned to
the user—is frequently created by JSP
4
Web applications

A web application typically consists of:





Some (Java) class, acting as the controller, that extends
HttpServlet
The model code (also Java)
The view code (ultimately Java, but we write it as JSP)
Plus, of course, the web.xml file
All these parts need to communicate with one another

That’s what the rest of this lecture is (mostly) about
5
web.xml  servlet
26-Jul-16
Servlet life-cycle methods

public void init()



public void service(ServletRequest request,
ServletResponse response)



Called after the servlet is constructed but before the servlet is placed into
service
As the name implies, a good place to do initializations
Called when a servlet request is made
The HttpServlet service method will dispatch the request to doGet,
doPost, or one of the other service methods
public void destroy()


Called when a servlet is terminated
Can be used to clean up any resources (files, databases, threads, etc.)
7
ServletConfig

You can override public void init()

Servlet has the methods:



public ServletConfig getServletConfig()
 You will probably use this if you override init()
public String getServletInfo()
 By default, returns an empty string; override to make it useful
The main purpose of ServletConfig is to provide initialization
information to the servlet

ServletConfig has these methods:





public java.lang.String getServletName()
public ServletContext getServletContext()
public Enumeration getInitParameterNames()
public String getInitParameter(String name)
Our interest will be in getting initialization parameters
8
Servlet init parameters

Where does a servlet get its initialization information?


Inside <servlet>:


From the web.xml file, of course!
<init-param>
<param-name>myName</param-name>
<param-value>myValue</param-value>
</init-param>
In the servlet code:

String myValue = getServletConfig().getInitParameter("myName");
9
web.xml  entire web application
26-Jul-16
Multiple servlets




A web application can consist of multiple servlets
We just saw how to send configuration information to a
single servlet
Context init parameters can send configuration
information to all servlets in a web application
Not inside a particular <servlet> tag:


<context-param>
<param-name>myName</param-name>
<param-value>myValue</param-value>
</context-param>
In any servlet:

String myValue =
getServletContext().getInitParameter("myName");
11
Servlet vs. context init parameters

Servlet init parameters are:

Defined within a <servlet> tag

Context init parameters are:


Written within an
<init-param> tag


Retrieved from a
ServletConfig object, which
you get by calling
getServletConfig()


Read from the ServletConfig
object by calling
getInitParameter(name)

Defined outside all <servlet>
tags
Written within a
<context-param> tag
Retrieved from a
ServletContext object, which
you get by calling
getServletContext()
Read from the ServletContext
object by calling
getInitParameter(name)
12
Public ServletContext methods








String getInitParameter(String name)
Enumeration getInitParameterNames()
Object getAttribute(String name)
Enumeration getAttributeNames()
void setAttribute(String name, Object object)
void removeAttribute(String name)
String getRealPath(String path)
RequestDispatcher getRequestDispatcher(String path)
13
servlet  JSP
26-Jul-16
The ServletRequest object

You’ve seen these methods of the ServletRequest
object:




ServletRequest also has these methods:




public Enumeration getParameterNames()
public String getParameter(String name)
public String[] getParameterValues(String name)
public Enumeration getAttributeNames()
public Object getAttribute(String name)
public void setAttribute(String name, Object object)
You can use attributes to send information to the JSP
15
Dispatching to the JSP

request.setAttribute(name, object)


Notice that we put the information on the request
RequestDispatcher view =
request.getRequestDispatcher("result.jsp");


We ask the request object for a dispatcher
We supply, as a String, a path to the JSP file



If the path begins with a slash, it is relative to the current context root
Otherwise, it is relative to the servlet location
view.forward(request, response);


Having added the result information to the HttpRequest
object, we forward the whole thing to the JSP
The JSP does the rest—it will send out the HTML page
16
Aside: redirect vs. forward

The previous slide showed how a servlet could forward
a request to JSP (or to another servlet)


This is all done on the server side
response.sendRedirect(URL) sends a response back
to the browser that says, in effect, “I can’t handle this
request; you should go to this URL instead.”


You cannot use this method if you have already written
something to the response
The URL can be relative to the location of this servlet
17
Attributes
26-Jul-16
Parameters are not attributes

You can get parameters from the Deployment Descriptor:




You cannot set these parameters
You can get request parameters



getServletConfig().getInitParameter(name);
getServletContext().getInitParameter(name);
request.getParameter(String name)
Parameter values are always Strings
Attribute values are always Objects

When you get an attribute, you have to cast it to the type you want
19
Attribute scopes

Servlets can access three scopes:

Application scope




Session scope




All servlets in the web application have access
Attributes are stored in the ServletContext object
Available for the lifetime of the servlet
Available to servlets that have access to this specific session
Attributes are stored in the HttpSession object
Available for the life of the session
Request scope



Available to servlets that have access to this specific request
Attributes are stored in the ServletRequest object
Available for the life of the request (until your doGet or doPost method
completes)
20
Attribute methods

ServletContext objects, ServletRequest objects, and
HttpSession objects all have the following methods:

Object getAttribute(String name)

void setAttribute(String name, Object object)

void removeAttribute(String name)

Enumeration getAttributeNames()
21
Thread safety

Thread problems can occur when:



Thread problems cannot (in general) be detected by the Java
runtime system


One Thread is writing to (modifying) an object at the same time another
Thread is reading it
Two (or more) Threads are trying to write to the same object at the same
time
Instead, thread problems cause random, mysterious, non-replicable
corruption of data
There are simple steps that you can take to avoid many threading
problems

However, threading is very error-prone and can be extremely difficult to
ensure that you have it right
22
Thread safety in servlets


Tomcat starts a new Thread for every new request
Each request, and therefore each Thread, has its own request and
response objects



Therefore, these are inherently Thread-safe
Local variables (including parameters) of your service methods are also
thread-safe
Instance variables are not thread-safe


Application (context) scope is shared by all servlets


You don’t have multiple servlet objects—you have multiple Threads using the
same servlet object
Therefore, context attributes are inherently Thread-unsafe
Session attributes are not completely Thread-safe

It is possible to have multiple simultaneous requests from the same session
23
Thread safety in class assignments

In reality, the servlets you write for this course are not going to
service thousands of requests per second



You (and my TA) will enter a few requests manually, with billions of
nanoseconds in between
You are not going to have threading problems
However...



I’m trying to teach “real world” programming
Therefore, you have to pretend that thread safety is a real issue in your
programming assignments
If I had lots of spare time (which I don’t!), I could write a program to send
your servlet thousands of requests per second


Even if I did that, my program could not reliably catch problems
Bottom line: Try your best to make your servlets thread-safe,
even though we can’t test them for thread safety
24
Protecting context attributes

To protect context attributes, synchronize on the ServletContext
object

Example (from Head First Servlets & JSP):
synchronized(getServletContext()) {
getServletContext().setAttribute("foo", "22");
getServletContext().setAttribute("bar", "42");
}


out.println(getServletContext().getAttribute("foo"));
out.println(getServletContext().getAttribute("bar"));
This will protect you from any other code that also synchronizes
on the ServletContext
It will not protect you from code that doesn’t so synchronize

But this is the best we can do
25
Protecting session attributes

To protect session attributes, synchronize on the HttpSession
object

Example (from Head First Servlets & JSP):
HttpSession session = request.getSession();
synchronized(session) {
session.setAttribute("foo", "22");
session.setAttribute("bar", "42");
out.println(session.getAttribute("foo"));
out.println(session.getAttribute("bar"));
}

This will protect you from any other code that also synchronizes
on the HttpSession
26
Getting init parameters in JSP


You can get servlet and context init parameters in your JSP
Step 1: Specify in your DD that you want them:


<servlet>
<servlet-name>SomeServletName</servlet-name>
<jsp-file>/UseServletInit.jsp</jsp-file>
<init-param> ... </init-param>
<init-param> ... </init-param>
...
</servlet>
Step 2: Override jspInit() (must be done in a JSP declaration):

<%!
public void jspInit() {
// use getServletConfig() and getServletContext() as usual
}
%>
27
PageContext


In JSP, pageContext is an implicit object (like request and response) of
type PageContext
PageContext has these methods (among others):




Object getAttribute(String name) // uses page scope
Object getAttribute(String name, int scope)
Enumeration getAttributeNamesInScope(int scope)
Object findAttribute(String name)




Searches in the order: page context, request scope, session scope, application scope
void setAttribute(String name, Object value)
void setAttribute(String name, Object value, int scope)
Where scope can be one of PageContext.APPLICATION_SCOPE,
PageContext.PAGE_SCOPE, PageContext.REQUEST_SCOPE, or
PageContext.SESSION_SCOPE

So you can access a lot of information from a PageContext object!
28
The End
29