300 likes | 469 Views
2. MVC. One of the most common Design Patterns is Model-View-Controller (MVC)The model does all the computational workIt is input/output freeAll communication with the model is via methodsThe controller tells the model what to doUser input goes to the controllerThe view shows results; it is a
E N D
1. 27-Sep-12 MVC for Servlets
2. 2 MVC One of the most common Design Patterns is Model-View-Controller (MVC)
The model does all the computational work
It is input/output free
All communication with the model is via methods
The controller tells the model what to do
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
3. 3 Advantages of MVC One advantage is separation of concerns
Computation is not intermixed with I/O
Consequently, code is cleaner and easier to understand
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
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
4. 4 MVC for servlets The model, as usual, does all the computational work, and no I/O
The model can consist of multiple classes
The servlet class (the one that extends HttpServlet) acts as the controller
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
5. 5 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
6. 27-Sep-12 web.xml ? servlet
7. 7 Servlet life-cycle methods public void init()
Called after the servlet is constructed but before the servlet is placed into service
As the name implies, a good place to do initializations
public void service(ServletRequest request, ServletResponse response)
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.)
8. 8 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
9. 9 Servlet init parameters Where does a servlet get its initialization information?
From the web.xml file, of course!
Inside <servlet>:
<init-param> <param-name>myName</param-name> <param-value>myValue</param-value></init-param>
In the servlet code:
String myValue = getServletConfig().getInitParameter("myName");
10. 27-Sep-12 web.xml ? entire web application
11. 11 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");
12. 12 Servlet vs. context init parameters Servlet init parameters are:
Defined within a <servlet> tag
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) Context init parameters are:
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)
13. 13 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)
14. 27-Sep-12 servlet ? JSP
15. 15 The ServletRequest object You’ve seen these methods of the ServletRequest object:
public Enumeration getParameterNames()
public String getParameter(String name)
public String[] getParameterValues(String name)
ServletRequest also has these methods:
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
16. 16 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
17. 17 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
18. 27-Sep-12 Attributes
19. 19 Parameters are not attributes You can get parameters from the Deployment Descriptor:
getServletConfig().getInitParameter(name);
getServletContext().getInitParameter(name);
You cannot set these parameters
You can get request parameters
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
20. 20 Attribute scopes Servlets can access three scopes:
Application scope
All servlets in the web application have access
Attributes are stored in the ServletContext object
Available for the lifetime of the servlet
Session scope
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)
21. 21 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()
22. 22 Thread safety Thread problems can occur when:
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
Thread problems cannot (in general) be detected by the Java runtime system
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
23. 23 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
You don’t have multiple servlet objects—you have multiple Threads using the same servlet object
Application (context) scope is shared by all servlets
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
24. 24 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
25. 25 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
26. 26 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
27. 27 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 }%>
28. 28 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!
29. 29 The End