Java Enterprise and Web Technologies

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).

Session attributes are shared across all servlets within the same ServletContext (web application). When you store an attribute in an HttpSession using setAttribute(), any other servlet in the same application can retrieve it using getAttribute() on the same session (identified by the same session ID). This sharing is a key purpose of session attributes - to maintain user-specific state across multiple servlets/JSPs in the application. Different ServletContexts have separate session scopes.

HttpServletRequest.getSession(true) returns the current session or creates a new one if none exists. The boolean parameter 'create' controls this behavior: true means create if needed, false means return null if no session exists. Option A (getSession(false)) would return null instead of creating a session. The method getSession() with no arguments is equivalent to getSession(true) - it also creates sessions.

Option C is FALSE (making it the correct answer to 'which is NOT true') because ServletContext has no getParameter() method - the correct method is getInitParameter(). Options A, B, and D are all TRUE: ServletContext init parameters are configured in web.xml, meant for data that rarely changes (like database connection strings), are application-wide (shared by all servlets), and are accessed using getInitParameter(String name).getParameter() methods exist on HttpServletRequest, not ServletContext.

ServletRequest.getInputStream() is declared in the ServletRequest interface and returns a ServletInputStream for reading the request body as binary data. Options A, B, and C are wrong because getMethod(), getHeader(), and getCookies() are declared in HttpServletRequest (which extends ServletRequest), not in ServletRequest itself. ServletRequest contains fundamental methods like getParameter(), getAttribute(), getInputStream(), and getReader(), while HttpServletRequest adds HTTP-specific methods.

In the init(ServletConfig) method, the ServletConfig object is passed as a parameter and can be accessed directly. The getServletConfig() method returns this stored config object, which is useful in other methods throughout the servlet lifecycle. getServletInfo() returns servlet information (not config), and getInitParameters() is not a standard method.

Spring defines five bean scopes: singleton (default), prototype, request, session, and global session. 'response' is NOT a valid scope in Spring - the option list includes singleton, prototype, and request, which ARE all valid Spring scopes, making 'response' the correct answer for what is NOT defined.

The ApplicationContext is Spring's bootstrap mechanism that loads all high-level entry-point objects required by your application. It provides configuration for the application, reads bean definitions, and assembles them at runtime. Application scope is a bean scope, and Application Integration is not a standard Spring term.

Spring supports constructor injection (via dependencies in constructor), setter injection (via setter methods), and field injection (via annotations). Interface injection is NOT supported by Spring - it was part of early DI frameworks but Spring chose not to implement it, preferring the other three approaches.

Java is widely used for both desktop applications (Swing, JavaFX) and web applications (servlets, JSP, Spring). The most complete answer includes both domains.