Java Servlets Interview Questions

Deployment descriptor (web.xml) is an XML file that configures servlets, filters, listeners, security constraints, and other settings for a web application.

Container instantiates servlet (constructor), calls init(), then repeatedly calls service() for requests, and finally calls destroy() on shutdown.

Application servers provide additional services beyond container functionality: connection pooling, transaction management, JMS messaging, clustering, security, and resource management.

Extend HttpServlet, override doGet/doPost/doPut/doDelete as needed, and deploy the compiled class with a mapping in web.xml or @WebServlet annotation.

Override service() only if you need custom request routing or handling logic that differs from standard HTTP method delegation; typically override specific doXxx() methods instead.

Servlet Container is the runtime environment (like Tomcat, Jetty) that manages servlet lifecycle, handles HTTP requests/responses, and provides threading and resource management.

Use ServletContextListener with contextInitialized() method to initialize services when the application starts up.

Use filters to intercept and modify request/response data; use listeners to react to application lifecycle events like initialization.

Listeners monitor servlet lifecycle events (initialization, destruction) and session/request events to execute code at specific points.

Servlet filters intercept requests/responses before they reach servlets, enabling cross-cutting concerns like logging, authentication, and compression.

ServletConfig holds servlet-specific configuration parameters defined in web.xml, accessible only to that particular servlet.

ServletContext represents the servlet container environment, accessible to all servlets, and provides shared application resources and attributes.

ServletConfig is servlet-specific with init parameters; ServletContext is application-wide and shared across all servlets.

ServletResponse encapsulates the HTTP response, providing methods to set headers, content type, and send data back to the client.

ServletRequest encapsulates the HTTP request, providing access to parameters, headers, session, and request attributes from the client.

RequestDispatcher forwards or includes requests to other servlets/JSPs within the same application without changing the URL.

Call another servlet using RequestDispatcher.forward() or include() obtained from ServletContext.getRequestDispatcher().

forward() keeps the original URL and transfers control server-side; sendRedirect() changes the URL and makes the client request a new resource.

Servlet attributes store request-scoped or application-scoped data; access via setAttribute()/getAttribute() on ServletRequest or ServletContext.

GenericServlet is protocol-agnostic; HttpServlet extends GenericServlet with HTTP-specific methods like doGet(), doPost().

HttpServlet is abstract to force developers to override specific HTTP method handlers rather than implementing the generic service() method.

Main HTTP methods are doGet(), doPost(), doPut(), doDelete(), doHead(), doOptions(), doTrace() called by service() based on request type.

TRACE method is typically disabled or unchanged in most implementations, used for debugging request headers across proxies.

GET, POST, PUT, DELETE, HEAD requests through HTML forms, AJAX calls, or direct HTTP requests to the server.

GET appends parameters to URL (limited size, cached, bookmarkable), POST sends data in request body (larger data, not cached, secure for sensitive info).

No, calling getWriter() and getOutputStream() simultaneously throws IllegalStateException; only one output stream can be active per request.

URL Encoding converts special characters to %HEX format for safe transmission; use URLEncoder.encode(string, 'UTF-8') in Java.

Request processing (parsing, validation, routing), resource management (connection pooling, thread management), session/security handling, and response generation.

Cookies are small text files stored on client side, sent with every request, used for session tracking, preferences, and authentication tokens.

Override init() without arguments to leverage container initialization; overriding init(ServletConfig) requires calling super.init(config) to properly initialize the servlet.

URL Rewriting embeds session ID in URLs as parameter (jsessionid) when cookies are disabled; used as fallback session tracking mechanism.

Session is server-side state storage for each client, persisting data across requests using session ID tracked via cookies or URL rewriting.

No, constructors shouldn't be overridden for initialization; use init() method instead because container controls servlet instantiation and lifecycle.

Implement Filter with session validation, or use ServletFilter to check session validity before delegating to servlets; deny requests without valid session.

Override service() when handling multiple HTTP methods with shared logic; typically implement doGet(), doPost(), etc. instead for method-specific handling.

Use connection pooling (HikariCP, Tomcat), initialize in ServletContextListener, store in ServletContext, implement try-with-resources, and use SLF4J/Log4j for logging.

HTTP Basic Auth (base64 encoded credentials), Form-based Auth (servlet handles login form), Digest Auth (MD5 hashing), and SSL Client Certificate Auth.

JSP simplifies HTML generation by embedding Java in markup, reducing boilerplate servlet code; compiled to servlet automatically by container.

JSP lifecycle: translation (JSP to servlet), compilation, loading, instantiation, initialization (jspInit), request processing (service), and destruction (jspDestroy).

Create a class extending HttpServlet, override doGet/doPost/doPut/doDelete methods, implement init/destroy if needed, and configure in web.xml or use @WebServlet annotation.

Only jspInit() and jspDestroy() methods can be redefined; the service method is generated from scriptlets and cannot be overridden.

A deployment descriptor (web.xml) is an XML file defining servlet mappings, filters, listeners, initialization parameters, and security constraints for a web application.

Dynamic content is generated at runtime based on requests (JSP/servlets), while static content is pre-existing files (HTML, images) served as-is.

The container calls init() once on startup, service() for each request (which dispatches to doGet/doPost), and destroy() once on shutdown.

Application servers provide additional services beyond servlet containers: clustering, transactions, JPA, messaging, security, and dependency injection; containers only handle HTTP requests.

JSP variable scopes are: page (local to current page), request (across forward/include), session (per user), and application (global to all users).

The pageContext implicit object is not available in regular JSP pages; it's only used in JSP tag files and custom tags.

Use <init-param> tags in web.xml or @WebInitParam annotation on the @WebServlet, then access via getInitParameter() in servlet.

A servlet container is a runtime environment that manages servlet lifecycle, handles HTTP requests/responses, and provides JSP compilation and execution.

Web project structure: src/main/java (code), src/main/webapp (static files), WEB-INF (web.xml, libraries), and build output in target directory.

Servlets are faster than CGI (no process creation per request), support session management, can access application context, and integrate with containers' resource management.

Use MVC pattern: servlets handle requests, JSP handles presentation, session/request objects for data passing, avoid business logic in JSP.

JspWriter is JSP-specific for writing to output stream with automatic flushing; PrintWriter is generic Java writer without JSP context.

Session objects are created by default; disable with <%@ page session="false" %> directive to reduce memory overhead.

Yes, JavaScript can be embedded directly in JSP pages using <% %> tags or via the Scripting API; JSP is server-side Java that generates HTML/JavaScript.

Configure JSP servlets in web.xml using <servlet> and <servlet-mapping> tags with jsp-file or explicit JSP servlet declarations; modern apps use annotations (@WebServlet).

JSTL uses <c:catch> tag to catch exceptions and store them in a variable, or <c:if> to conditionally handle errors; detailed error handling typically delegates to error pages.

Configure error handling via try-catch blocks, JSP error pages (<error-page> in web.xml), or exception handling filters; use <c:catch> in JSTL for runtime error capture.

Standard JSP tags (JSTL) are configured via taglib directives in JSP pages themselves; web.xml configuration is not required since they're part of the servlet specification.

JSP automatically escapes special HTML characters using &lt;, &gt;, &amp; entities; use expression language ${variable} or JSTL tags, which handle encoding automatically.

Keep JSP for view logic only; use EL/JSTL instead of scriptlets; delegate business logic to servlets/controllers; leverage jsp:include for reusability.

JspWriter is request/response buffered output tied to PageContext; PrintWriter is standard Java IO without JSP context.

Session objects are created by default on JSP; disable with <%@ page session="false" %> directive to reduce memory overhead.

Yes, JSP pages can include JavaScript; scripting elements and client-side scripts are fully supported.

JSP servlets configured via servlet and servlet-mapping elements in web.xml with URL patterns.

JSTL error handling via c:catch tag or error-page directive; catches exceptions and stores in pageContext.

Use error pages via <%@ page errorPage="error.jsp" %> directive or configure <error-page> in web.xml to specify error handlers for different exception types and HTTP status codes.

Standard JSP tags (JSTL) are built-in and automatically available; they're pre-compiled by container and don't require manual taglib registration in web.xml like custom tags do.

Use JSP expression <%= value %> to output strings to HTML, or use out.println() in scriptlets; escape HTML special characters using JSTL <c:out> or Apache Commons Lang to prevent XSS.

Custom JSP tags are created by extending SimpleTag or BodyTagSupport, defined in .tag files or tag classes, then registered in web.xml with <tag> element or via @WebServlet annotation.

Custom JSP tags are written using Tag classes implementing Tag/BodyTag interfaces or TagSupport, defining doStartTag/doEndTag methods, then registered in TLD files for use in JSP pages.

JSP functionality expands via custom tag libraries (JSTL, custom tags), include directives, beans, servlets forwarding requests, and expression language (EL).

JSTL consists of five groups: Core (flow control, variables), Formatting (dates, numbers, localization), SQL (database access), XML (XML processing), Functions (string utilities).

JSTL (JSP Standard Tag Library) is a standard library providing reusable tags for common operations like loops, conditionals, string formatting, and database access without scriptlets.

JSTL consists of five tag groups: Core, Formatting, SQL, XML, and Functions tags for control flow, formatting, database access, XML processing, and string manipulation.

JSTL (JSP Standard Tag Library) is a collection of custom tags that provide common functionality like iteration, conditionals, and formatting in JSP pages without scriptlets.

EL implicit objects (pageScope, requestScope, sessionScope, applicationScope, param, paramValues, header, headerValues, cookie, initParam) provide access to request/response data; JSP objects are scriptlet variables like request, response, session obtained directly.

EL operators: arithmetic (+, -, *, /, %), comparison (==, !=, <, >, <=, >=), logical (&&, ||, !), relational (instanceof), and ternary (? :).

EL (Expression Language) is a simple scripting language in JSP/Servlets for accessing data and invoking methods using ${expression} syntax; supports property access, collections, operators, and implicit objects.

Yes, you can access the class using getClass() or reflection APIs in JSP, typically through request/response objects or scriptlet code, though it's better practice to handle this in servlets.

Scriptlets (< % %>) in JSP are hard to maintain, debug, and test; prefer MVC pattern with servlets for logic and JSP for view layer only.

Servlets are more efficient than CGI as they run in process, reuse threads, have persistent connections, and eliminate process creation overhead for each request.

A typical web project structure includes src/, WebContent/, WEB-INF/, web.xml (deployment descriptor), lib/ for dependencies, and jsp/ for views.

Servlet container is a runtime environment that loads, instantiates, and manages servlet lifecycles, handling HTTP requests/responses and resource management.

Application servers provide additional features beyond servlet containers: transaction management, EJB support, clustering, security, and enterprise services.

Container calls init() once on startup, then service() for each request (which delegates to doGet/doPost/etc.), and destroy() on shutdown.

Deployment descriptor (web.xml) is an XML file in WEB-INF/ that configures servlets, mappings, filters, listeners, security constraints, and application parameters.

Create a class extending HttpServlet, override doGet() and/or doPost() methods, implement request/response logic, then configure servlet mapping in web.xml.

Override service() method when you need custom logic before/after HTTP method handling or to handle custom HTTP methods beyond GET/POST/PUT/DELETE.