Explore topic-wise InterviewSolutions in .

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
• request
• response
• PAGECONTEXT
• SESSION
• application
• out
• config
• page
• exception.

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
• request
• response
• pageContext
• session
• application
• out
• config
• page
• exception.

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 <jsp:USEBEAN> 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.

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 <jsp:useBean> 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.

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; %>

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; %>

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 %&GT; 
<%= (new java.util.Date()).toLocaleString() %>
You cannot use a semicolon to END an expression.

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.

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" %>
<html>
<head><title>A Hidden Comment </title></head>
<body>
<%-- This comment will not be visible to the colent in the page source --%>
</body>
</html>

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" %>
<html>
<head><title>A Hidden Comment </title></head>
<body>
<%-- This comment will not be visible to the colent in the page source --%>
</body>
</html>

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
&LT;!-- comment [ <%= expression %> ] -->
Example 1
<!-- This is a commnet sent to client on
<%= (new java.util.Date()).toLocaleString()%>
-->
Displays in the page source:
<!-- This is a commnet sent to client on JANUARY 24, 2004 -->

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
<!-- comment [ <%= expression %> ] -->
Example 1
<!-- This is a commnet sent to client on
<%= (new java.util.Date()).toLocaleString()%>
-->
Displays in the page source:
<!-- This is a commnet sent to client on January 24, 2004 -->

Using errorPage attribute of PAGE directive and also we NEED to specify isErrorPage=true if the current page is INTENDED to URL redirecting of a JSP.

Using errorPage attribute of page directive and also we need to specify isErrorPage=true if the current page is intended to URL redirecting of a JSP.

RequestDispatcher: server-side REDIRECT with request and response OBJECTS.

SENDREDIRECT : Client-side redirect with new request and response objects.

RequestDispatcher: server-side redirect with request and response objects.

sendRedirect : Client-side redirect with new request and response objects.

include directive :

• The file gets INCLUDED at the COMPILE time.
• it is static in nature.output comes with jsp page but WHOLE file contains is included in jsp then compilation is done.

action tag :

• The file gets included at the RUN time. This is faster.
• it is dynamic in nature.output of YHE file willbe included in the jsp file.

include directive :

action tag :

yes, we can. We do it usually when we NEED to initialize any members which are to be AVAILABLE for a SERVLET/ JSP THROUGHOUT its lifetime.

yes, we can. We do it usually when we need to initialize any members which are to be available for a servlet/ JSP throughout its lifetime.

Compilation error, as TWO variables with same name can't be declared. This happens because, when a page is included STATICALLY, ENTIRE code of included page becomes part of the new page. at this time there are two declarations of VARIABLE 'a'. Hence compilation error.

Compilation error, as two variables with same name can't be declared. This happens because, when a page is included statically, entire code of included page becomes part of the new page. at this time there are two declarations of variable 'a'. Hence compilation error.

An INCLUDE directive tells the JSP engine to include the CONTENTS of another file (HTML, JSP, ETC.) in the current page. This PROCESS of INCLUDING a file is also called as static include.

An include directive tells the JSP engine to include the contents of another file (HTML, JSP, etc.) in the current page. This process of including a file is also called as static include.

_jspService() method will be written by the CONTAINER HENCE any methods which are not to be OVERRIDDEN by the end USER are typically written starting with an '_'. This is the reason why we don't override _jspService() method in any JSP PAGE.

_jspService() method will be written by the container hence any methods which are not to be overridden by the end user are typically written starting with an '_'. This is the reason why we don't override _jspService() method in any JSP page.

We can OVERRIDE JSPINIT() and JSPDESTROY() METHODS but not _jspService().

We can override jspinit() and jspDestroy() methods but not _jspService().

When a JSP include directive is used, the included FILE's code is added into the added JSP PAGE at page translation time, this happens before the JSP page is translated into a servlet. While if any page is included using action TAG, the page's OUTPUT is returned BACK to the added page. This happens at runtime.

When a JSP include directive is used, the included file's code is added into the added JSP page at page translation time, this happens before the JSP page is translated into a servlet. While if any page is included using action tag, the page's output is returned back to the added page. This happens at runtime.

USING <%JSP:PARAM&GT; tag.

Using <%jsp:param> tag.

request.getRequestDispatcher(PATH): In ORDER to create it we NEED to give the RELATIVE path of the resource context.getRequestDispatcher(path): In order to create it we need to give the absolute path of the resource.

request.getRequestDispatcher(path): In order to create it we need to give the relative path of the resource context.getRequestDispatcher(path): In order to create it we need to give the absolute path of the resource.

ServletContext: GIVES the INFORMATION about the CONTAINER
PAGECONTEXT: Gives the information about the Request.

ServletContext: Gives the information about the container
PageContext: Gives the information about the Request.

No

No

COOKIE mycook = NEW Cookie("NAME","VALUE");
response.addCookie(mycook);
Cookie killmycook = new Cookie("mycook","value");
killmycook.setMaxAge(0);
killmycook.setPath("/");
killmycook.addCookie(killmycook);

Cookie mycook = new Cookie("name","value");
response.addCookie(mycook);
Cookie killmycook = new Cookie("mycook","value");
killmycook.setMaxAge(0);
killmycook.setPath("/");
killmycook.addCookie(killmycook);

&LT;%@ PAGE SESSION="FALSE"&GT;

<%@ page session="false">

A Connection to a database can be established from a jsp PAGE by writing the code to establish a connection using a jsp scriptlets.

Further then you can use the RESULTSET object "res" to read data in the following WAY.

A Connection to a database can be established from a jsp page by writing the code to establish a connection using a jsp scriptlets.

Further then you can use the resultset object "res" to read data in the following way.

A cookie, mycookie, can be DELETED using the following scriptlet:

A cookie, mycookie, can be deleted using the following scriptlet:

By default, a JSP PAGE will automatically create a session for the request if ONE does not exist.
However, sessions consume resources and if it is not necessary to MAINTAIN a session, one should not be created. For example, a marketing CAMPAIGN MAY suggest the reader visit a web page for more information. If it is anticipated that a lot of traffic will hit that page, you may want to optimize the load on the machine by not creating useless sessions.

By default, a JSP page will automatically create a session for the request if one does not exist.
However, sessions consume resources and if it is not necessary to maintain a session, one should not be created. For example, a marketing campaign may suggest the reader visit a web page for more information. If it is anticipated that a lot of traffic will hit that page, you may want to optimize the load on the machine by not creating useless sessions.

If you're just including raw HTML, use the #include DIRECTIVE as usual inside your .jsp file.

But it's a little trickier if you want the SERVER to evaluate any JSP code that's inside the included file. If your data.inc file contains jsp code you will have to use <%@ vinclude="data.inc" %>

The is used for including non-JSP files.

include directive - <%@ include file="fileName" %> - as is the case with all other directives in a JSP page, this include directive is also PROCESSED at the time when the JSP page is translated into its equivalent servlet. This directive simply causes the contents of the specified file to be pasted into the JSP page at the place where the page contains this directive. Irrespective of whether the included resource is a static resource or a JSP page - only the contents of the file are pasted (and not the processed results). This directive is normally used for including static resources only - like, banner, header, footer, etc. for the obvious reason.

include action -<jsp:include page="relativeURL"></jsp:include> this include action is executed at run time and the specified 'page' is first executed and then the result of that 'page' is appended to the response object of the calling JSP at the point where the tag OCCURS. Obviously if the specified page is a static resource then the contents of it are included as there won't be an executed result in that case. This action allows additional parameters to be passed via child element of this include action element.

If you're just including raw HTML, use the #include directive as usual inside your .jsp file.

But it's a little trickier if you want the server to evaluate any JSP code that's inside the included file. If your data.inc file contains jsp code you will have to use <%@ vinclude="data.inc" %>

The is used for including non-JSP files.

include directive - <%@ include file="fileName" %> - as is the case with all other directives in a JSP page, this include directive is also processed at the time when the JSP page is translated into its equivalent servlet. This directive simply causes the contents of the specified file to be pasted into the JSP page at the place where the page contains this directive. Irrespective of whether the included resource is a static resource or a JSP page - only the contents of the file are pasted (and not the processed results). This directive is normally used for including static resources only - like, banner, header, footer, etc. for the obvious reason.

include action -<jsp:include page="relativeURL"></jsp:include> this include action is executed at run time and the specified 'page' is first executed and then the result of that 'page' is appended to the response object of the calling JSP at the point where the tag occurs. Obviously if the specified page is a static resource then the contents of it are included as there won't be an executed result in that case. This action allows additional parameters to be passed via child element of this include action element.

LET's CONSIDER the answer to that from two different perspectives: that of an HTML designer and that of a Java programmer.

If you are an HTML designer, you can look at JSP technology as extending HTML to provide you with the ability to seamlessly embed snippets of Java code within your HTML pages. These bits of Java code generate dynamic content, which is embedded within the other HTML/XML content you author. Even better, JSP technology provides the means by which programmers can create new HTML/XML tags and JavaBeans components, which provide new FEATURES for HTML designers without those designers needing to learn how to program.

Note: A common misconception is that Java code embedded in a JSP page is TRANSMITTED with the HTML and executed by the user AGENT (such as a browser). This is not the case. A JSP page is translated into a Java servlet and executed on the server. JSP statements embedded in the JSP page become part of the servlet generated from the JSP page. The resulting servlet is executed on the server. It is never visible to the user agent. If you are a Java programmer, you can look at JSP technology as a new, higher-level means to writing servlets. Instead of directly writing servlet classes and then emitting HTML from your servlets, you write HTML pages with Java code embedded in them. The JSP environment takes your page and dynamically compiles it. Whenever a user agent requests that page from the Web server, the servlet that was generated from your JSP code is executed, and the results are returned to the user.

Let's consider the answer to that from two different perspectives: that of an HTML designer and that of a Java programmer.

If you are an HTML designer, you can look at JSP technology as extending HTML to provide you with the ability to seamlessly embed snippets of Java code within your HTML pages. These bits of Java code generate dynamic content, which is embedded within the other HTML/XML content you author. Even better, JSP technology provides the means by which programmers can create new HTML/XML tags and JavaBeans components, which provide new features for HTML designers without those designers needing to learn how to program.

Note: A common misconception is that Java code embedded in a JSP page is transmitted with the HTML and executed by the user agent (such as a browser). This is not the case. A JSP page is translated into a Java servlet and executed on the server. JSP statements embedded in the JSP page become part of the servlet generated from the JSP page. The resulting servlet is executed on the server. It is never visible to the user agent. If you are a Java programmer, you can look at JSP technology as a new, higher-level means to writing servlets. Instead of directly writing servlet classes and then emitting HTML from your servlets, you write HTML pages with Java code embedded in them. The JSP environment takes your page and dynamically compiles it. Whenever a user agent requests that page from the Web server, the servlet that was generated from your JSP code is executed, and the results are returned to the user.

No PROBLEM! The USE Bean action specifies the beanName attribute, which can be USED for indicating a serialized bean.

For example:

A couple of important POINTS to note. Although you would have to NAME your serialized file "filename.ser", you only indicate "filename" as the value for the beanName attribute. Also, you will have to place your serialized file within the WEB-INFjspbeans directory for it to be located by the JSP engine.

No problem! The use Bean action specifies the beanName attribute, which can be used for indicating a serialized bean.

For example:

A couple of important points to note. Although you would have to name your serialized file "filename.ser", you only indicate "filename" as the value for the beanName attribute. Also, you will have to place your serialized file within the WEB-INFjspbeans directory for it to be located by the JSP engine.

No. You are supposed to MAKE use of only a JSPWriter object (given to you in the FORM of the implicit object out) for replying to clients.

A JSPWriter can be viewed as a buffered version of the stream object returned by response.getWriter(), ALTHOUGH from an implementational perspective, it is not.

No. You are supposed to make use of only a JSPWriter object (given to you in the form of the implicit object out) for replying to clients.

A JSPWriter can be viewed as a buffered version of the stream object returned by response.getWriter(), although from an implementational perspective, it is not.

The following code snippet shows how a servlet instantiates a bean and initializes it with FORM data posted by a browser. The bean is then PLACED into the request, and the call is then forwarded to the JSP page, Bean1.jsp, by means of a request dispatcher for downstream processing.

public void doPost (HttpServletRequest request, HttpServletResponse response)
{
try {
govi.FormBean f = new govi.FormBean();
String id = request.getParameter("id");
f.setName(request.getParameter("name"));
f.setAddr(request.getParameter("addr"));
f.setAge(request.getParameter("age"));
//use the id to COMPUTE
//additional bean properties like INFO
//maybe perform a db query, etc.
// . . .
f.setPersonalizationInfo(info);
request.setAttribute("fBean",f);
getServletConfig().getServletContext().getRequestDispatcher
("/jsp/Bean1.jsp").forward(request, response);
} catch (EXCEPTION EX) {
. . .
}
}

The JSP page Bean1.jsp can then process fBean, a fter first extracting it from the default request scope via the useBean action.

jsp:useBean id="fBean" class="govi.FormBean" scope="request"/ jsp:getProperty name="fBean"
property="name" / jsp:getProperty name="fBean"
property="addr" / jsp:getProperty name="fBean" property="age" / jsp:getProperty name="fBean"
property="personalizationInfo" /

The following code snippet shows how a servlet instantiates a bean and initializes it with FORM data posted by a browser. The bean is then placed into the request, and the call is then forwarded to the JSP page, Bean1.jsp, by means of a request dispatcher for downstream processing.

public void doPost (HttpServletRequest request, HttpServletResponse response)
{
try {
govi.FormBean f = new govi.FormBean();
String id = request.getParameter("id");
f.setName(request.getParameter("name"));
f.setAddr(request.getParameter("addr"));
f.setAge(request.getParameter("age"));
//use the id to compute
//additional bean properties like info
//maybe perform a db query, etc.
// . . .
f.setPersonalizationInfo(info);
request.setAttribute("fBean",f);
getServletConfig().getServletContext().getRequestDispatcher
("/jsp/Bean1.jsp").forward(request, response);
} catch (Exception ex) {
. . .
}
}

The JSP page Bean1.jsp can then process fBean, a fter first extracting it from the default request scope via the useBean action.

jsp:useBean id="fBean" class="govi.FormBean" scope="request"/ jsp:getProperty name="fBean"
property="name" / jsp:getProperty name="fBean"
property="addr" / jsp:getProperty name="fBean" property="age" / jsp:getProperty name="fBean"
property="personalizationInfo" /

Typically, a default inactivity lease PERIOD for all sessions is set within your JSPengine admin SCREEN or associated properties file. HOWEVER, if your JSP engine supports the Servlet 2.1 API, you can manage the inactivity lease period on a per-SESSION basis. This is done by invoking the HttpSession.setMaxInactiveInterval() method, right after the session has been created.

Typically, a default inactivity lease period for all sessions is set within your JSPengine admin screen or associated properties file. However, if your JSP engine supports the Servlet 2.1 API, you can manage the inactivity lease period on a per-session basis. This is done by invoking the HttpSession.setMaxInactiveInterval() method, right after the session has been created.

YES, there is. Under JSP 1.0, the PAGE implicit object is equivalent to "this", and RETURNS a reference to the Servlet generated by the JSP page.

Yes, there is. Under JSP 1.0, the page implicit object is equivalent to "this", and returns a reference to the Servlet generated by the JSP page.

Yes. However, unlike Servlet, you are not required to implement HTTP-protocol specific methods like doGet() or doPost() within your JSP page. You can obtain the data for the FORM input elements VIA the request IMPLICIT object within a scriptlet or expression as.

Yes. However, unlike Servlet, you are not required to implement HTTP-protocol specific methods like doGet() or doPost() within your JSP page. You can obtain the data for the FORM input elements via the request implicit object within a scriptlet or expression as.

Yes. Preemptive TERMINATION of request processing on an error CONDITION is a good way to maximize the throughput of a high-volume JSP engine. The TRICK (assuming JAVA is your scripting language) is to use the return STATEMENT when you want to terminate further processing.

Yes. Preemptive termination of request processing on an error condition is a good way to maximize the throughput of a high-volume JSP engine. The trick (assuming Java is your scripting language) is to use the return statement when you want to terminate further processing.

You can declare methods for use within your JSP page as declarations. The methods can then be INVOKED within any other methods you declare, or within JSP scriptlets and expressions.

Do note that you do not have DIRECT access to any of the JSP implicit objects like request, response, session and so forth from within JSP methods. However, you should be ABLE to pass any of the implicit JSP variables as PARAMETERS to the methods you declare.

For example:
Another Example:
file1.jsp:
file2.jsp
<%test(out);% >

You can declare methods for use within your JSP page as declarations. The methods can then be invoked within any other methods you declare, or within JSP scriptlets and expressions.

Do note that you do not have direct access to any of the JSP implicit objects like request, response, session and so forth from within JSP methods. However, you should be able to pass any of the implicit JSP variables as parameters to the methods you declare.

For example:
Another Example:
file1.jsp:
file2.jsp
<%test(out);% >

You can pass the HttpSession as parameter to an EJB method, only if all objects in session are serializable. This has to be CONSIDER as "passed-by-value", that means that it's read-only in the EJB.

If anything is altered from inside the EJB, it won't be reflected back to the HttpSession of the Servlet Container. The "pass-byreference" can be used between EJBs Remote Interfaces, as they are remote references.

While it IS possible to pass an HttpSession as a parameter to an EJB object, it is considered to be "bad practice" in terms of object oriented design. This is because you are creating an unnecessary coupling between back-end objects (ejbs) and front-end objects (HttpSession). Create a higher-level of ABSTRACTION for your ejb's api. Rather than passing the whole, fat, HttpSession (which carries with it a bunch of HTTP semantics), create a class that acts as a value object (or structure) that holds all the data you need to pass back and forth between front-end/back-end.

Consider the case where your ejb NEEDS to support a non-http-based client. This higher level of abstraction will be flexible enough to support it.

You can pass the HttpSession as parameter to an EJB method, only if all objects in session are serializable. This has to be consider as "passed-by-value", that means that it's read-only in the EJB.

If anything is altered from inside the EJB, it won't be reflected back to the HttpSession of the Servlet Container. The "pass-byreference" can be used between EJBs Remote Interfaces, as they are remote references.

While it IS possible to pass an HttpSession as a parameter to an EJB object, it is considered to be "bad practice" in terms of object oriented design. This is because you are creating an unnecessary coupling between back-end objects (ejbs) and front-end objects (HttpSession). Create a higher-level of abstraction for your ejb's api. Rather than passing the whole, fat, HttpSession (which carries with it a bunch of http semantics), create a class that acts as a value object (or structure) that holds all the data you need to pass back and forth between front-end/back-end.

Consider the case where your ejb needs to support a non-http-based client. This higher level of abstraction will be flexible enough to support it.

You can use "JSP-style" comments to selectively block out code while DEBUGGING or simply to COMMENT your scriptlets. JSP comments are not visible at the client.
For example:
--%>
You can also use HTML-style comments anywhere WITHIN your JSP page. These comments are visible at the client. For example: Of course, you can also use comments SUPPORTED by your JSP SCRIPTING language within your scriptlets.

You can use "JSP-style" comments to selectively block out code while debugging or simply to comment your scriptlets. JSP comments are not visible at the client.
For example:
--%>
You can also use HTML-style comments anywhere within your JSP page. These comments are visible at the client. For example: Of course, you can also use comments supported by your JSP scripting language within your scriptlets.

You can use the errorPage attribute of the page directive to have uncaught runtime exceptions AUTOMATICALLY forwarded to an ERROR processing page.
For example: 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: the Throwable object DESCRIBING the exception may be accessed within the error page via the exception implicit object.

You can use the errorPage attribute of the page directive to have uncaught runtime exceptions automatically forwarded to an error processing page.
For example: 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: the Throwable object describing the exception may be accessed within the error page via the exception implicit object.

You can use the response implicit object to redirect the BROWSER to a different RESOURCE, as: response. send Redirect ; You can also physically alter the LOCATION HTTP header attribute, as shown below: You can also use the:

Also note that you can only use this before any output has been SENT to the client. I beleve this is the case with the response.sendRedirect() method as WELL. If you want to pass any paramateres then you can pass using.

You can use the response implicit object to redirect the browser to a different resource, as: response. send Redirect ; You can also physically alter the Location HTTP header attribute, as shown below: You can also use the:

Also note that you can only use this before any output has been sent to the client. I beleve this is the case with the response.sendRedirect() method as well. If you want to pass any paramateres then you can pass using.

You cannot override the _jspService() METHOD within a JSP page. You can however, override the JSPINIT() and jspDestroy() METHODS within a JSP page. jspInit() can be USEFUL for allocating RESOURCES like database connections, network connections, and so forth for the JSP page. It is good programming practice to free any allocated resources within jspDestroy().

The jspInit() and jspDestroy() methods are each executed just once during the lifecycle of a JSP page and are typically declared as JSP declarations:

You cannot override the _jspService() method within a JSP page. You can however, override the jspInit() and jspDestroy() methods within a JSP page. jspInit() can be useful for allocating resources like database connections, network connections, and so forth for the JSP page. It is good programming practice to free any allocated resources within jspDestroy().

The jspInit() and jspDestroy() methods are each executed just once during the lifecycle of a JSP page and are typically declared as JSP declarations:

You first set "Errorpage" ATTRIBUTE of PAGE DIRECTORY to the name of the error page (IE Errorpage= "error.jsp")in your jsp page .Then in the error jsp page set "isErrorpage=TRUE". When an error occur in your jsp page it will automatically CALL the error page.

You first set "Errorpage" attribute of PAGE directory to the name of the error page (ie Errorpage= "error.jsp")in your jsp page .Then in the error jsp page set "isErrorpage=TRUE". When an error occur in your jsp page it will automatically call the error page.

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.

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.

Because it is not practical to have such model. WHETHER you set isThreadSafe to TRUE or false, you should take CARE of concurrent client requests to the JSP PAGE by synchronizing ACCESS to any shared objects defined at the page level.

Because it is not practical to have such model. Whether you set isThreadSafe to true or false, you should take care of concurrent client requests to the JSP page by synchronizing access to any shared objects defined at the page level.

There are three scripting LANGUAGE ELEMENTS: DECLARATIONS, scriptlets, expressions.

There are three scripting language elements: declarations, scriptlets, expressions.

SQLWarning objects are a subclass of SQLException that deal with database access warnings. Warnings do not stop the execution of an application, as exceptions do; they simply alert the user that something did not HAPPEN as PLANNED. A warning can be reported on a Connection object, a Statement object (INCLUDING PreparedStatement and CallableStatement objects), or a ResultSet object. Each of these classes has a getWarnings method, which you MUST INVOKE in order to see the first warning reported on the calling object .

SQLWarning warning = stmt.getWarnings();
if (warning != null)
{
while (warning != null)
{
System.out.println(\"Message: \" + warning.getMessage());
System.out.println(\"SQLState: \" + warning.getSQLState());
System.out.print(\"Vendor error code: \");
System.out.println(warning.getErrorCode());
warning = warning.getNextWarning();
}
}

SQLWarning objects are a subclass of SQLException that deal with database access warnings. Warnings do not stop the execution of an application, as exceptions do; they simply alert the user that something did not happen as planned. A warning can be reported on a Connection object, a Statement object (including PreparedStatement and CallableStatement objects), or a ResultSet object. Each of these classes has a getWarnings method, which you must invoke in order to see the first warning reported on the calling object .

SQLWarning warning = stmt.getWarnings();
if (warning != null)
{
while (warning != null)
{
System.out.println(\"Message: \" + warning.getMessage());
System.out.println(\"SQLState: \" + warning.getSQLState());
System.out.print(\"Vendor error code: \");
System.out.println(warning.getErrorCode());
warning = warning.getNextWarning();
}
}

It is used to CREATE an instance of a driver and register it with the DRIVERMANAGER. When you have loaded a driver, it is AVAILABLE for making a connection with a DBMS.

It is used to create an instance of a driver and register it with the DriverManager. When you have loaded a driver, it is available for making a connection with a DBMS.

The Local Systems IP ADDRESS and PORT NUMBER. And the REMOTE System’s IPAddress and Port Number.

The Local Systems IP Address and Port Number. And the Remote System’s IPAddress and Port Number.

JMS PROVIDE for two MESSAGING MODELS, publish-and-subscribe and point-to-point queuing.

JMS provide for two messaging models, publish-and-subscribe and point-to-point queuing.

USING System.exit(1); in TRY block will not allow FINALLY code to execute.

Using System.exit(1); in try block will not allow finally code to execute.

YES. JSP technology is EXTENSIBLE through the development of CUSTOM ACTIONS, or tags, which are encapsulated in TAG libraries.

YES. JSP technology is extensible through the development of custom actions, or tags, which are encapsulated in tag libraries.

Because no plug-ins or security policy files are needed on the client systems(APPLET does). Also, JSP pages enable cleaner and more module application design because they provide a way to separate APPLICATIONS programming from web page design. This MEANS personnel involved in web page design do not need to understand Java programming language SYNTAX to do their jobs.

Because no plug-ins or security policy files are needed on the client systems(applet does). Also, JSP pages enable cleaner and more module application design because they provide a way to separate applications programming from web page design. This means personnel involved in web page design do not need to understand Java programming language syntax to do their jobs.