|In web.xml file <load-on-startup>1</load-on-startup> is defined between <servlet></servlet> tag what does it means.||whenever we request for any servlet the servlet container will initialize the servlet and load it which is defined in our config file called web.xml by default it will not initialize when our context is loaded .defining like this <load-on-startup>1</load-on-startup> is also known as pre initialization of servlet means now the servlet for which we have define this tag has been initialized in starting when context is loaded before getting any request.When this servlet question was asked to me in an interview few years back , I was not even aware of this element but this questions pointed me to look DTD of web.xml and understand other elements as well..|
|How can we create deadlock condition on our servlet?||one simple way to call doPost() method inside doGet() and doGet()method inside doPost() it will create deadlock situation for a servlet. This is rather simple servlet interview questions but yet tricky if you don’t think of it.|
|For initializing a servlet can we use constructor in place of init ().||No, we can not use constructor for initializing a servlet because for initialization we need an object of servletConfig using this object we get all the parameter which are defined in deployment descriptor for initializing a servlet and in servlet class we have only default constructor according to older version of java so if we want to pass a
Config object we don’t have parametrized constructor and apart from this servlet is loaded and initialized by container so ots a job of container to call the method according to servlet specification they have lifecycle method so init() method is called firstly.
More important Java doesn’t allow interfaces to declare constructors. These kinds of servlet interview questions are quite popular on service based companies who just want to dig one level more.
|Why super.init (config) wiil be the first statement inside init(config) method?||This will be the first statement if we are overriding the init(config ) method by this way we will store the config object for future reference and we can use by getServletConfig () to get information about config object if will not do this config object will be lost and we have only one way to get config object because servlet pass config object only in init method . Without doing this if we call the servletConfig method will get NullPointerException.|
|Can we call destroy() method inside the init() method is yes what will happen?||Yes we can call like this but if we have not override this method container will call the default method and nothing will happen.after calling this if any we have override the method then the code written inside is executed.|
|How can we refresh servlet on client and server side automatically?||On client side we can use Meta http refresh and server side we can use server push.|
|How can you get the information about one servlet context in another servlet?||In context object we can set the attribute which we want on another servlet and we can get that attribute using their name on another servlet.
Context.setAttribute (“name”,” value”)
|Why we need to implement Single Thread model in case of Servlet ?||In J2EE we can implement our servlet on two different ways either by using:
1. Single Thread Model
2. Multithread Model
Depending upon our scenario, if we have implemented single thread means only one instance is going handle one request at a time no two thread will concurrently execute service method of servlet.
Example in banking account where sensitive data is handle mostly this scenario was used this interface is deprecated in Servlet API version 2.4.
As the name signifies multi thread means a servlet is capable to handle multiple requests at same time. This servlet interview question was quite popular few years back on entry level but now its loosing its shine.
|what is servlet collaboration?||communication between two servlet is called servlet collaboration which is achieved by 3 ways.
1. RequestDispatchers include () and forward() method .
2. Using sendRedirect()method of Response object.
3. Using servlet Context methods.
|What is the difference between ServletConfig and ServletContext?||ServletConfig as the name implies provide the information about configuration of a servlet which is defined inside the web.xml file or we can say deployment descriptor.its a specific object for each servlet.
ServletContext is application specific object which is shared by all the servlet belongs to one application in one JVM .this is single object which represent our application and all the servlet access application specific data using this object.servlet also use their method to communicate with container.
These Servlet interview questions are good for quick recap of important concept before appearing on any J2EE interview. Please share if you have come across any other interesting interview question on Servlets.
|What is Session Tracking?||Session tracking is a mechanism that servlets use to maintain state about a series of requests from the same user (that is, requests originating from the same browser) across some period of time.|
|What is the need of Session Tracking in web application?||HTTP is a stateless protocol i.e., every request is treated as new request. For web applications to be more realistic they have to retain information across multiple requests. Such information which is part of the application is reffered as “state”. To keep track of this state we need session tracking.
Typical example: Putting things one at a time into a shopping cart, then checking out–each page request must somehow be associated with previous requests.
|What are the types of Session Tracking ?||Sessions need to work with all web browsers and take into account the users security preferences. Therefore there are a variety of ways to send and receive the identifier:
URL rewriting : URL rewriting is a method of session tracking in which some extra data (session ID) is appended at the end of each URL. This extra data identifies the session. The server can associate this session identifier with the data it has stored about that session. This method is used with browsers that do not support cookies or where the user has disabled the cookies.
Hidden Form Fields : Similar to URL rewriting. The server embeds new hidden fields in every dynamically generated form page for the client. When the client submits the form to the server the hidden fields identify the client.
Cookies : Cookie is a small amount of information sent by a servlet to a Web browser. Saved by the browser, and later sent back to the server in subsequent requests. A cookie has a name, a single value, and optional attributes. A cookie’s value can uniquely identify a client.
Secure Socket Layer (SSL) Sessions : Web browsers that support Secure Socket Layer communication can use SSL’s support via HTTPS for generating a unique session key as part of the encrypted conversation.
To set a cookie on the client, use the addCookie() method in class HttpServletResponse. Multiple cookies may be set for the same request, and a single cookie name may have multiple values.
To get all of the cookies associated with a single HTTP request, use the getCookies() method of class HttpServletRequest
|What are some advantages of storing session state in cookies?||Cookies are usually persistent, so for low-security sites, user data that needs to be stored long-term (such as a user ID, historical information, etc.) can be maintained easily with no server interaction.
For small- and medium-sized session data, the entire session data (instead of just the session ID) can be kept in the cookie.
|What are some disadvantages of storing session state in cookies?||Cookies are controlled by programming a low-level API, which is more difficult to implement than some other approaches.
All data for a session are kept on the client. Corruption, expiration or purging of cookie files can all result in incomplete, inconsistent, or missing information.
Cookies may not be available for many reasons: the user may have disabled them, the browser version may not support them, the browser may be behind a firewall that filters cookies, and so on. Servlets and JSP pages that rely exclusively on cookies for client-side session state will not operate properly for all clients. Using cookies, and then switching to an alternate client-side session state strategy in cases where cookies aren’t available, complicates development and maintenance.
Browser instances share cookies, so users cannot have multiple simultaneous sessions.
|What is URL rewriting?||URL rewriting is a method of session tracking in which some extra data is appended at the end of each URL. This extra data identifies the session. The server can associate this session identifier with the data it has stored about that session.
Every URL on the page must be encoded using method HttpServletResponse.encodeURL(). Each time a URL is output, the servlet passes the URL to encodeURL(), which encodes session ID in the URL if the browser isn’t accepting cookies, or if the session tracking is turned off.
URL rewriting works just about everywhere, especially when cookies are turned off.
Multiple simultaneous sessions are possible for a single user. Session information is local to each browser instance, since it’s stored in URLs in each page being displayed. This scheme isn’t foolproof, though, since users can start a new browser instance using a URL for an active session, and confuse the server by interacting with the same session through two instances.
Entirely static pages cannot be used with URL rewriting, since every link must be dynamically written with the session state. It is possible to combine static and dynamic content, using (for example) templating or server-side includes. This limitation is also a barrier to integrating legacy web pages with newer, servlet-based pages.
Every URL on a page which needs the session information must be rewritten each time a page is served. Not only is this expensive computationally, but it can greatly increase communication overhead.
URL rewriting limits the client’s interaction with the server to HTTP GETs, which can result in awkward restrictions on the page.
URL rewriting does not work well with JSP technology.
If a client workstation crashes, all of the URLs (and therefore all of the data for that session) are lost.
|What is servlet lazy loading?||A container doesnot initialize the servlets ass soon as it starts up, it initializes a servlet when it receives a request for that servlet first time. This is called lazy loading.
The servlet specification defines the <load-on-startup> element, which can be specified in the deployment descriptor to make the servlet container load and initialize the servlet as soon as it starts up.
The process of loading a servlet before any request comes in is called preloading or preinitializing a servlet.
|What are Filters?||Filters are Java components that are used to intercept an incoming request to a Web resource and a response sent back from the resource. It is used to abstract any useful information contained in the request or response. Some of the important functions performed by filters are as follows:
Modifying the request or response
Logging and auditing
Filters are configured in the deployment descriptor of a Web application. Hence, a user is not required to recompile anything to change the input or output of the Web application.
|What are the functions of an intercepting filter?||The functions of an intercepting filter are as follows:
It intercepts the request from a client before it reaches the servlet and modifies the request if required.
It intercepts the response from the servlet back to the client and modifies the request if required.
There can be many filters forming a chain, in which case the output of one filter becomes an input to the next filter. Hence, various modifications can be performed on a single request and response.