Logo F2FInterview

JSP Interview Questions

Q   |   QA

Custom JSP tag is the one the user defines. The user defines how the tags, its attributes and its body should be interpreted, and then the user groups the tags collections called tag libraries that can be used in large number of JSP files.

Even though custom tags and beans accomplish almost the same objectives of encapsulating complex behavior into simple and accessible forms there are several differences:

  • Custom tags can manipulate JSP content; beans cannot.
  • Complex operations can be reduced to a significantly simpler form with custom tags than with beans.
  • Custom tags require quite a bit more work to set up than do beans.
  • Custom tags usually define relatively self-contained behavior, whereas beans are often defined in one servlet and used in a different servlet or JSP page.
  • Custom tags are available only in JSP 1.1 and later, but beans can be used in all JSP 1.x versions

The JSPs can be made thread-safe by having them implement the SingleThreadModel interface. This can be achieved by adding the directive <%@ page isThreadSafe=”false” %> within your JSP page. Instead of having a single instance of the servlet generated for your JSP page loaded in memory, you will have number of instances of the servlet loaded and initialized, with the service method of each instance effectively synchronized. You can typically control the number of instances (N) that are instantiated for all servlet implementing SingleThreadModel through the admin screen for your JSP engine. More importantly, avoid using the tag for variables. If you do use this tag, then you should set isThreadSafe to true, as mentioned above. Otherwise, all requests to that page will access those variables, causing a nasty race condition. SingleThreadModel is not recommended for normal use. There are many pitfalls, including the example above of not being able to use <%! %>.

Normally the errorPage attribute of the page directive used to have uncaught run-time exceptions automatically forwarded to an error processing page.

For example:

<%@ page errorPage=”error.jsp” %>

redirects the browser to the JSP page error.jsp if an uncaught exception is encountered during request processing. Within error.jsp, if you indicate that it is an error-processing page, via the directive: <%@ page isErrorPage=”true” %> Throwable object describing the exception may be accessed within the error page via the exception implicit object. Note: You must always use a relative URL as the value for the errorPage attribute.

Yes. This can be achieved. We need to set the appropriate HTTP header attributes to ensure that the dynamic content output by the JSP page is not cached by the web browser.This can be done by executing the following scriptlet at the start of the JSP pages to prevent them from being cached by the browser.

The below statements will take care to prevent the caching.

response.setHeader("Cache-Control","no-store"); //HTTP 1.1
response.setHeader("Pragma","no-cache"); //HTTP 1.0
response.setDateHeader ("Expires", 0); //prevents caching at the proxy server

This can be done using the JSP style and HTML style.


JSP style

<%-- this comments the single line of the JSP
Here the entire block is commented out

HTML style

HTML-style comments can be used anywhere in the JSP page. These comments are visible at the client.


<!-- The HTML style commenting -->

Apart from these we can use the comment that the scripting language supports within the scriptlets.

e.g. If Java is used as the scripting language, we can have

// comment 1
comment 2

In order to link this F2FInterview's page as Reference on your website or Blog, click on below text area and pres (CTRL-C) to copy the code in clipboard or right click then copy the following lines after that paste into your website or Blog.

Get Reference Link To This Page: (copy below code by (CTRL-C) and paste into your website or Blog)
HTML Rendering of above code: