Servlets & JSP Series 5 - Being a Web App
-
Every servlet inherits a getServletConfig() method, the getServletConfig method returns a ServletConfig, and one of its methods is getInitParameter(), we cannot use servlet init parameters until the servlet is initialized.
-
When the container initializes a servlet, it makes a unique ServletConfig for the servlet, the Container “reads” the servlet init parameters from the DD and gives them to the ServletConfig, then passes the ServletConfig to the servlet’s init() method.
-
The whole process of ServletConfig survive: 1.Container reads the Deployment Descriptor for this servlet, including the servlet init parameters; 2.Container creates a new ServletConfig instance for this servlet; 3.Container creates a name/value pair of String for each servlet init parameter; 4.Container gives the ServletConfig references to the name/value init parameters; 5.Container creates a new instance of the servlet class; 6.Container calls the servelt’s init() method passing in the reference to the ServletConfig().
-
Serveltconfig’s main job is to give you init parameters, ServletConfig is one per servlet, ServletContext is one per web app.
-
There’s only on ServletContext for an entire web app, and sll the parts of the web app share it, but each servelt in the app has its own ServletConfig, the container makes a ServletContext when a web app is deployed, and makes the context available to each Servlet and JSP(which becomes a servlet) in the web app.
-
To listen for ServletContext events, write a listener class that implements ServletContextListener, put it I your WEB-INF/classes directory, and tell the Container by putting a <listener> element in the Deployment Descriptor.
-
How context listener works: 1.Container reads the Deployment Descriptor for this app, including the <listener> and <context-param> elements; 2.Container creates a new ServletContext for this application, that all parts of the app will share; 3.Container creates a name/value pair of Strings for each context init parameter; 4.Container gives the ServletContext references to the name/value parameters; 5.Container creates a new instance of the Listener class; 6.Container calls the listener’s contextInitialized() method, passing in a new ServletContextEvent, the event object has a reference to the ServletContext, so the event-handling code can get the context from the event, and get the context init parameter from the context; 7.Listener asks ServletContextEvent for a reference to the ServletContext; 8.Listener asks ServletContext for the context init parameter; 9. Listener uses the init parameter to construct a new Dog object; 10.Listener sets the Dog as an attribute in the ServletContext; 11.Container makes a new Servlet; 12.Servlet gets a request, and asks the ServletContext for the attrivute “dog”; 13. Servlet calls the method on this object.
-
Attrivute API: the three attribute scopes-context, request, and session-are handled by the ServletContext, ServletRequest, and HttpSession interfaces, the API methods for attributes are exactly the same in every interface.
-
We don’t need a lock on the servlet, we need the lock on the context, the typical way to protect the context attribute is to synchronize on the context object itself.
-
Protect session attributes by synchronizing on the HttpSession.
-
SingleThreadModel ensures that servlet handle only one request at a time, this interface has no methods, if a servlet implements this interface, you are guaranteed that no two threads will execute concurrently in the servlet’s service method, the servlet container can make this guarantee by synchronizing access to a single instance of the servlet, or by maintaining a pool of servlet instances and dispatching each new request to a free servlet.
-
If you want all the threads to access a value, decide which attribute state makes the most sense, and store the value in an attribute, chances are, you can solve your problems in one of two ways: 1.Declare the variable as a local variable within the service method,rather than as an instance variable; 2.Use an attribute in the most appropriate scope.
-
RequestDispatchers have only two methods-forward() and include(), both take the request and response object, of the two methods, forward() is by far the most popular, it’s very unlikely you will use the include method from a controller servlet, however, hehind the scenes the include method is being used by JSPs in the <jsp:include> standard action, you can get a RequestDispatcher in two ways: from the request or from the context, regardless of where you get it, you have to tell it the web component to which you are fowwarding the request, in orther words, the servlet or JSP that will take over.
-
The include() method of RequestDispatcher is not used much in the real world, the include() method sends the request to something else to do some work and then comes back to the sender.