Java Servlets and JSP Quiz

ServletContext provides servlets with information about their environment (container) and allows sharing data across servlets. Through it, servlets can access initialization parameters, server info, and resources. The statement correctly describes this interface.

The HttpServletResponse interface provides getWriter() method which returns a PrintWriter object for sending character text to the client. This is the standard way to output response content in servlets.

The servlet lifecycle consists of three main phases: initialization (init() called once), service (service()/doGet()/doPost() called per request), and destruction (destroy() called once before removal). All three are lifecycle methods, making 'Above All' the correct answer.

Servlets are inherently multi-threaded - a single servlet instance handles multiple concurrent requests, with each request processed in a separate thread. The servlet container manages this threading model automatically.

The init(ServletConfig) method receives the ServletConfig object as a parameter. The getServletConfig() method returns this ServletConfig object, which contains initialization parameters and servlet configuration. getServletInfo() returns servlet information (author, version etc.), not the config object. getInitParameters() is not a standard method - parameters are accessed via getInitParameter() on the config object.

JSP stands for Java Server Pages, a server-side technology that enables dynamic web content generation. It simplifies web development by allowing developers to embed Java code directly into HTML pages. The technology is specifically designed for creating platform-independent, dynamically generated web content.

JSP files do not need explicit configuration in web.xml because modern servlet containers automatically handle them. When a JSP is first accessed, the container translates it into a servlet and compiles it. The JSP engine built into the container processes JSP files without requiring manual mapping or configuration.

JSP requires a servlet container with a JSP engine to process and execute pages. Apache Tomcat and BEA WebLogic are application servers that include JSP engines. JSP Engine is a generic term for any container component that can process JSP files. Servlets are a technology, not an execution environment.

JSP scriptlets use the syntax <% code %> to embed Java code that executes during page generation. The percentage symbols distinguish scriptlets from other JSP elements. Other options are incorrect - @jsp is not a valid prefix, and jsp:scriptlet is for XML-style actions, not scriptlets. Scriptlets are one of three main JSP scripting elements.

JSP declaration elements use the <%! code %> syntax to define class-level variables and methods. These declarations become members of the generated servlet class, not part of the _jspService() method. Option A incorrectly closes with !%>, and the jsp:scriptlet format is for XML-style actions, not declarations.

JavaBean standard actions in JSP include useBean (instantiate or locate a bean), setProperty (assign values to bean properties), and getProperty (retrieve property values). These three actions provide complete bean manipulation capability in JSP pages without requiring scriptlet code. They simplify working with JavaBeans through declarative syntax.

Web servers can deploy JAR files (as libraries or standalone apps) and WAR files (web applications). WAR files are specifically designed for web application deployment with web components. EAR files are for application servers, not basic web servers - they contain multiple modules (WARs, JARs) with deployment descriptors.

The servlet container provides comprehensive support services including communication mechanisms (request/response handling), lifecycle management (instantiation, initialization, destruction), and multithreading support (managing concurrent requests). These infrastructure services allow developers to focus on business logic rather than runtime concerns.

In the MVC (Model-View-Controller) pattern for Java web applications: Model represents the business logic and data (typically Java classes); View handles presentation (JSP pages for rendering HTML); Controller manages user interaction and coordinates Model and View (Servlets receive requests and delegate to appropriate components). Option A incorrectly places HTML as a separate component rather than what JSP generates. Option C is wrong because 'Container' is not an MVC role. Option D adds unnecessary complexity with EJB.

To answer this question, the user needs to have a basic understanding of HTTP methods.

An HTTP method is a type of request that a client sends to a server to perform a specific action. HTTP defines several standard methods, each of which is designed to be used for different purposes.

A non-idempotent request is a request that changes the state of the server. This means that if the same request is made multiple times, the result may be different each time.

OPTIONS:

A) GET: This option is not correct. The GET method is used to retrieve data from the server and is considered idempotent. This means that multiple identical requests will return the same response every time.

B) POST: This option is correct. The POST method is used to submit an entity to the specified resource, often causing a change in state or side effects on the server. POST requests are non-idempotent, meaning that multiple identical requests will not produce the same response.

C) PUT: This option is not correct. The PUT method is used to replace all current representations of a target resource with the request payload. Like the POST method, PUT requests are non-idempotent.

D) HEAD: This option is not correct. The HEAD method is used to retrieve the headers that would be returned if the HEAD request's URL was instead requested with the GET method. The HEAD request is considered idempotent because it does not change the state of the server.

Therefore, the correct answer is:

The Answer is: B. POST

HttpServletRequest.getParameter() retrieves request parameter values sent by the client (from query string or POST body). Option B is wrong because HttpServletResponse has no getAttribute() method - attributes are on requests, not responses. Option C is wrong because HttpServletResponse has no getParameter() - parameters belong to requests only. Option D is wrong because HttpServletRequest has no setParameter() method - request parameters are read-only once set by the client.

HttpServletResponse.sendRedirect(String URL) is the standard method to redirect the client to a different URL. This sends a 302 temporary redirect response to the browser, which then makes a new request to the target URL. Options A and B are non-existent methods. Option D (getRequestDispatcher) is for server-side forwarding/dispatching, not client-side redirection - it forwards the request without the client knowing.

Servlets are inherently multi-threaded - one instance serves multiple requests concurrently. The recommended approach is to use local variables (thread-safe by design since each thread has its own stack) and avoid instance variables. If instance variables are necessary, synchronize access to them. Option A is wrong - no such class exists. Option B (SingleThreadModel) is deprecated and inefficient - it creates problems without solving thread safety. Option C (synchronizing service()) serializes ALL requests, causing severe performance bottlenecks.

HttpSession invalidation is managed by the servlet container based on a configurable timeout period (default typically 30 minutes). The container checks session inactivity and invalidates sessions that exceed the timeout. Option A is wrong - timeout of -1 means no timeout limit, but session can still be invalidated when server restarts or explicitly. Option B is wrong - closing browser doesn't immediately invalidate session; the session cookie persists until it expires or is cleared. Option D has the wrong method name - the correct method is HttpSession.invalidate() not invalidateSession().

Option D is FALSE (making it the correct answer to 'which is NOT true') because there is no such class as javax.servlet.http.CookielessHttpSession in the Servlet API. When cookies are disabled, containers use URL rewriting (appending the session ID to URLs) - they don't switch to a different HttpSession implementation class. Options A, B, and C are all TRUE statements: URL rewriting is a valid session tracking mechanism; SSL sessions can be used; and JSESSIONID is the standard cookie name (though containers can configure a different name).