| 
 
 
 
 
 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
JSP Interview Questions
(All App Labs)
| What is a output comment?  | ||
| What is a Hidden comment?  | ||
| What is an Expression? | ||
| What is a Declaration ?  | ||
| What is a Scriptlet?  | ||
| What are implicit objects? List them? | ||
| Difference between forward and sendRedirect? | ||
| What are the different scope values for the ? | ||
| Explain the life-cycle methods in JSP? | ||
| Q: | What is a output   comment? | |
| A: | A comment that is sent to the client   in the viewable page source.The JSP engine handles an output comment as   uninterpreted HTML text, returning the comment in the HTML output sent to the   client. You can see the comment by viewing the page source from your Web   browser.  JSP Syntax  Example 1 Displays in the page source: | |
| Q: | What is a Hidden   Comment? | 
| A: | A comments that documents the JSP   page but is not sent to the client. The JSP engine ignores a hidden comment,   and does not process any code within hidden comment tags. A hidden comment is   not sent to the client, either in the displayed JSP page or the HTML page   source. The hidden comment is useful when you want to hide or "comment   out" part of your JSP page. You can use any characters   in the body of the comment except the closing --%> combination. If you   need to use --%> in your comment, you can escape it by typing --%\>. JSP Syntax <%-- comment --%> Examples <%@ page language="java" %> <%-- This comment will not be visible to the colent in the page source --%> | 
| Q: | What is a   Expression? | 
| A: | An expression tag contains a   scripting language expression that is evaluated, converted to a String, and   inserted where the expression appears in the JSP file. Because the value of   an expression is converted to a String, you can use an expression within text   in a JSP file. Like  <%= someexpression %> <%= (new java.util.Date()).toLocaleString() %> You cannot use a semicolon to end an expression | 
| Q: | What is a   Declaration? | 
| A: | A declaration declares one or more   variables or methods for use later in the JSP source file. A declaration must contain   at least one complete declarative statement. You can declare any number of   variables or methods within one declaration tag, as long as they are   separated by semicolons. The declaration must be valid in the scripting   language used in the JSP file. <%! somedeclarations %> <%! int i = 0; %> <%! int a, b, c; %> | 
| Q: | What is a Scriptlet? | 
| A: | A scriptlet can contain any number of   language statements, variable or method declarations, or expressions that are   valid in the page scripting language.Within scriptlet tags, you can 1.Declare variables or   methods to use later in the file (see also Declaration). 2.Write expressions valid in the page scripting language (see also Expression). 3.Use any of the JSP implicit objects or any object declared with a tag. You must write plain text, HTML-encoded text, or other JSP tags outside the scriptlet. Scriptlets are executed at request time, when the JSP engine processes the client request. If the scriptlet produces output, the output is stored in the out object, from which you can display it. | 
| Q: | What are implicit   objects? List them? | |
| A: | Certain objects that are available   for the use in JSP documents without being declared first. These objects are   parsed by the JSP engine and inserted into the generated servlet. The   implicit objects re listed below 
 | |
| Q: | Difference between   forward and sendRedirect? | |
| A: | When you invoke a forward request,   the request is sent to another resource on the server, without the client   being informed that a different resource is going to process the request.   This process occurs completly with in the web container. When a sendRedirtect   method is invoked, it causes the web container to return to the browser   indicating that a new URL should be requested. Because the browser issues a   completly new request any object that are stored as request attributes before   the redirect occurs will be lost. This extra round trip a redirect is slower   than forward.  | |
| Q: | What are the different   scope valiues for the ? | 
| A: | The different scope values   for are 1.page 2.request 3.session 4.application | 
| Q: | Explain the life-cycle   mehtods in JSP? | 
| A: | The generated servlet class   for a JSP page implements the HttpJspPage interface of the javax.servlet.jsp   package. Http HttpJspPage interface extends the JspPage interface which   inturn extends the Servlet interface of the javax.servlet package. the   generated servlet class thus implements all the methods of the these three   interfaces. The JspPage interface declares only two methods - jspInit()   and jspDestroy() that must be implemented by all JSP   pages regardless of the client-server protocol. However the JSP specification   has provided the HttpJspPage interface specifically for the JSP pages serving   HTTP requests. This interface declares one method _jspService(). The jspInit()- The container calls the jspInit() to initialize te servlet instance.It is called before any other method, and is called only once for a servlet instance. The _jspservice()- The container calls the _jspservice() for each request, passing it the request and the response objects. The jspDestroy()- The container calls this when it decides take the instance out of service. It is the last method called in the servlet instance. | 
| Question: | |||
| Question: | |||
| Question: | |||
| Question: | |||
| Question: | |||
| Question: | |||
| Question: | |||
| Q: | How   do I prevent the output of my JSP or Servlet pages from being cached by the   browser? | ||
| A: | You will need to set the appropriate   HTTP header attributes to prevent the dynamic content output by the JSP page   from being cached by the browser. Just execute the following scriptlet at the   beginning of your JSP pages to prevent them from being cached at the browser.   You need both the statements to take care of some of the older browser   versions.  <%   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 %> | ||
| Q: | How   does JSP handle run-time exceptions?  | ||
| A: | You can use   the errorPage attribute of the page directive 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. | ||
| Q: | How   can I implement a thread-safe JSP page? What are the advantages and   Disadvantages of using it? | |
| A: | You can   make your JSPs thread-safe by having them implement the SingleThreadModel   interface. This is done by adding the directive <%@ page   isThreadSafe="false" %> within your JSP page. With this, instead   of a single instance of the servlet generated for your JSP page loaded in   memory, you will have N 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 servlets   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 <%!   %>. You should try really hard to make them thread-safe the old fashioned   way: by making them thread-safe . | |
| Q: | How   do I use a scriptlet to initialize a newly instantiated bean?  | |
| A: | A jsp:useBean action may   optionally have a body. If the body is specified, its contents will be   automatically invoked when the specified bean is instantiated. Typically, the   body will contain scriptlets or jsp:setProperty tags to initialize the newly   instantiated bean, although you are not restricted to using those alone. The following example shows the “today” property of the Foo bean initialized to the current date when it is instantiated. Note that here, we make use of a JSP expression within the jsp:setProperty action. "> <%-- scriptlets calling bean setter methods go here --%> | |
| Q: | How   can I prevent the word "null" from appearing in my HTML input text   fields when I populate them with a resultset that has null values?  | ||
| A: | You could make a simple   wrapper function, like <%! String blanknull(String s) { return (s == null) ? \"\" : s; } %> then use it inside your JSP form, like "   > | ||
| Q: | What's   a better approach for enabling thread-safe servlets and JSPs?   SingleThreadModel Interface or Synchronization? | ||
| A: | Although the SingleThreadModel technique is easy to use,   and works well for low volume sites, it does not scale well. If you   anticipate your users to increase in the future, you may be better off   implementing explicit synchronization for your shared data. The key however,   is to effectively minimize the amount of code that is synchronzied so that   you take maximum advantage of multithreading.  Also,   note that SingleThreadModel is pretty resource intensive from the server\'s   perspective. The most serious issue however is when the number of concurrent   requests exhaust the servlet instance pool. In that case, all the unserviced   requests are queued until something becomes free - which results in poor   performance. Since the usage is non-deterministic, it may not help much even   if you did add more memory and increased the size of the instance pool.  | ||
| Q: | How   can I enable session tracking for JSP pages if the browser has disabled   cookies? | ||
| A: | We know that session tracking uses cookies by default to   associate a session identifier with a unique user. If the browser does not   support cookies, or if cookies are disabled, you can still enable session   tracking using URL rewriting. URL rewriting essentially includes the session   ID within the link itself as a name/value pair. However, for this to be   effective, you need to append the session ID for each and every link that is   part of your servlet response. Adding the session ID to a link is greatly   simplified by means of of a couple of methods: response.encodeURL()   associates a session ID with a given URL, and if you are using redirection,   response.encodeRedirectURL() can be used by giving the redirected URL as   input. Both encodeURL() and encodeRedirectedURL() first determine whether   cookies are supported by the browser; if so, the input URL is returned   unchanged since the session ID will be persisted as a cookie. hello1.jsp Consider the following example, in which two JSP files, say hello1.jsp and hello2.jsp, interact with each other. Basically, we create a new session within hello1.jsp and place an object within this session. The user can then traverse to hello2.jsp by clicking on the link present within the page. Within hello2.jsp, we simply extract the object that was earlier placed in the session and display its contents. Notice that we invoke the encodeURL() within hello1.jsp on the link used to invoke hello2.jsp; if cookies are disabled, the session ID is automatically appended to the URL, allowing hello2.jsp to still retrieve the session object. Try this example first with cookies enabled. Then disable cookie support, restart the brower, and try again. Each time you should see the maintenance of the session across pages. Do note that to get this example to work with cookies disabled at the browser, your JSP engine has to support URL rewriting. <%@ page session=\"true\" %> <% Integer num = new Integer(100); session.putValue("num",num); String url =response.encodeURL("hello2.jsp"); %> \'>hello2.jsp hello2.jsp <%@ page session="true" %> <% Integer i= (Integer )session.getValue("num"); out.println("Num value in session is " + i.intValue()); %> | ||
| Question: | |||
| Question: | |||
| Q: | What is the   difference b/w variable declared inside a declaration part and variable   declared in scriplet part? | ||
| A: | Variable declared inside declaration   part is treated as a global variable.that means after convertion jsp file   into servlet that variable will be in outside of service method or it will be   declared as instance variable.And the scope is available to complete jsp and   to complete in the converted servlet class.where as if u declare a variable   inside a scriplet that variable will be declared inside a service method and   the scope is with in the service method.  | ||
| Q: | Is there a way to   execute a JSP from the comandline or from my own application? | 
| A: | There is a little tool   called JSPExecutor that allows you to do just that. The developers (Hendrik   Schreiber & Peter Rossbach ) aim was not to write a full blown servlet   engine, but to provide means to use JSP for generating source code or   reports. Therefore most HTTP-specific features (headers, sessions, etc) are   not implemented, i.e. no reponseline or header is generated. Nevertheless you   can use it to precompile JSP for your website. | 
 
0 comments:
Post a Comment