Homework – 1
CAP618T: Modern Web Programming Tools and Techniques - I
Max. Marks: 30
Instructions:
i. Each Question is of 5 marks. ii. Do not copy the answers from internet or from other students. iii. All questions are compulsory. iv. Submission should be made online through the upload link available in the UMS.
Q1. What are the various implicit objects available in JSP? Explain each of them with an example.
Ans:
Implicit Objects
In any JSP Page, there are a bunch of implicit objects that are available for the programmer to use. It contains a variety of information that can be used to display stuff on the page. In this chapter, we are going to look at the following JSP Implicit Objects that are available for a programmer.

• request
• response
• out
• session
• config
• application
• page
• pageContext

So, Lets get Started!!!

JSP Implicit Objects

The JSP Implicit objects mentioned in the list in the previous paragraph are available by means of automatically defined variables. These variables have the same name and case as the list above. In the forthcoming paragraphs we will be looking at them one by one.

request

This is the HttpServletRequest instance associated with the client request. As you know, the data between the Servlet and the JSP flows by using the HttpServletRequest and the HttpServletResponse objects. The page receives a request and sends a response. The data sent by a JSP page is available in the request in the Servlet and similarly the data sent by the servlet is available in the JSP again in the request object. There is a surprising amount of information stored in it. For example, you can get the request type (whether it is GET, POST, or HEAD) and the associated cookies. You can extract information from the request object and act on that data.

Let us take a look at a small piece of code that would help us understand how to read data from the request object.
< html >
< body >
< h1 > Inspecting the Request Object < / h1 >
< font size="4" >
Request Method: < % = request.getMethod() % >

Request URI: < % = request.getRequestURI() % >

Request Protocol: < % = request.getProtocol() % >

Servlet path: < % = request.getServletPath() % >

Path info: < % = request.getPathInfo() % >

Path translated: < % = request.getPathTranslated() % >

Query string: < % = request.getQueryString() % >

Content length: < % = request.getContentLength() % >

Content type: < % = request.getContentType() % >

Server name: < % = request.getServerName() % >

Server port: < % = request.getServerPort() % >

Remote user: < % = request.getRemoteUser() % >

Remote address: < % = request.getRemoteAddr() % >

Remote host: < % = request.getRemoteHost() % >

Authorization type: < % = request.getAuthType() % >

Browser type: < % = request.getHeader("User-Agent") % >
< / font >
< / body >
< / html >

If you deploy this JSP on your TomCat server and run it, you will see the details of the request on your web page. This is how the page would look if you run your local instance.

response

This is the HttpServletResponse class that manages the response to the client. You use this object to send data back to the client. For example, among other things, you can add cookies (addCookie), add a specified header (addHeader), and return an error that includes a status and a default message (sendError). You can redirect a browser to another URL with sendRedirect. You can set the content type and the HTTP status (setStatus) as well. For ex: you can set the content type on the response using the below line of code.

response.setContentType("text/html")

The response object doesn't do much. It doesn't have any elaborate functionality like the HttpServletRequest but at the same time, it is not trivial. It still can do a lot of things that would affect the whole J2EE application as such.

Besides manipulating the output buffer (such as, setBufferSize(), flushBuffer(), and getBufferSize()), Sun's public interface ServletResponse defines only the following methods: getLocale(), getOutputStream(), getWriter(), isCommitted(), setContentLength(), setContentType(), and setLocale().

session

This is the HttpSession object associated with the request. We have taken a detailed look at the Session Management in the previous few chapters which are as follows:

1. Introduction to Sessions
2. Storing & Retrieving Session Objects
3. Session Event Listeners
4. Invalidating Sessions
5. Session Tracking Through URL Rewriting

The JSP container handles (creates, tracks, and destroys) sessions automatically. You can use the session attribute of the page directive to turn sessions off. When they are explicitly set to - off, there is no session state available for a JSP page, and any reference to the session variable causes a fatal error.

The primary use of the session variable is to store state information between pages for a given user. A session applies to a single user where you can share information across JSP pages. This differs from the application object, which shares information across all users. The session is on by default, so you don't have to set the "session=true" attribute in the JSP page directive, but it is good practice to make your intentions clear.

The exam objectives only address your understanding of what a session is and how to turn on session tracking for a JSP page. Still, you should at least review the methods and properties of the session object, as they might appear in a test question. They are as follows:

• getAttribute
• getAttributeNames
• getCreationTime
• getId
• getLastAccessedTime
• getMaxInactiveInterval
• invalidate
• isNew
• putValue
• removeAttribute
• setAttribute
• setMaxInactiveInterval

I repeat, the Session Management has been covered in great depth as part of this SCWCD series and you can visit those article to understand the HttpSession, if you havent done already…
Exam Trivia:
Each new session gets its own unique id number. That is how the JSP container keeps track of browsers. The number has to be long enough to eliminate the possibility of session id collision

config

The config implicit object is an instance of the class javax.servlet.ServletConfig. It is usually used in servlets rather than JSP pages. The methods of this object return initialization parameters for the page which are declared in the web.xml file. You define initialization parameters by setting the property when you register a servlet in the web.xml file, the deployment descriptor. The most used methods of this object are getInitParameter and getInitParameterNames.

Though it is used predominantly in servlets, the config object is available in the JSP page as well. Let us take a look at a sample piece of code and see how to use the config object.
< % String DFLT_PARAM_ONE = "first parameter"; String DFLT_PARAM_TWO = "second parameter"; String param_one = config.getInitParameter("first_parameter"); if (param_one == null) { param_one = DFLT_PARAM_ONE; } String param_two = config.getInitParameter("second_parameter"); if (param_two == null) { param_two = DFLT_PARAM_TWO; } % >
< % = "param_one: " + param_one % >
< % = "
" % >
< % = "param_two: " + param_two % >
< % = "< P >" % >

I will leave you to execute this in your JSP page to ponder the output. It would be a good exercise for you to understand these implicit objects…

application

While a session object shares information between JSP pages for a given user, an application object shares information among all users of a currently active J2EE Web application. You can also use this object to communicate with the Servlet Container running the current JSP page. Normally, there is one application object per Java Virtual Machine. So, every JSP page on a Web server shares the same application object (irrespective of how many sessions are running currently).

Q2. How Java beans can be used inside a JSP page? Create a sample application based on Java Beans.
Ans:
Java Beans
Java Beans are reusable components. They are used to separate Business logic from the Presentation logic. Internally, a bean is just an instance of a class. JSP?s provide three basic tags for working with Beans. * <jsp:useBean id=?bean name? class=?bean class? scope = ?page | request | session |application ?/> bean name = the name that refers to the bean.
Bean class = name of the java class that defines the bean. * <jsp:setProperty name = ?id? property = ?someProperty? value = ?someValue? /> id = the name of the bean as specified in the useBean tag. property = name of the property to be passed to the bean. value = value of that particular property .
An variant for this tag is the property attribute can be replaced by an ? * ?. What this does is that it accepts all the form parameters and thus reduces the need for writing multiple setProperty tags. The only consideration is that the form parameter names should be the same as that of the bean property names. * <jsp:getProperty name = ?id? property = ?someProperty? />
Here the property is the name of the property whose value is to be obtained from the bean.
Sample application: class Puppy implements java.io.Serializable
{
private static final long serialVersionUID = 2006L; private String color; private int age;

public String getColor() { return color; }

public void setColor(String color) { this.color = color; }

public int getAge() { return age; }

public void setAge(int age) { this.age = age; }
}
Q3. Design a “Contact Us” JSP page containing fields like Email Address, Subject and message. Explain how this page will get translated into a Servlet and write the corresponding servlet code for this JSP Page.
Q4. Create a web application and perform the following database operations: a. Create a database and write steps for configuring the system DSN.
Ans:
Create a System DSN in Windows XP 1. Click Start, point to Control Panel, double-click Administrative Tools, and then double-click Data Sources(ODBC). 2. Click the System DSN tab, and then click Add. 3. Click the database driver that corresponds with the database type to which you are connecting, and then clickFinish. 4. Type the data source name. Make sure that you choose a name that you can remember. You will need to use this name later. 5. Click Select. 6. Click the correct database, and then click OK. 7. Click OK, and then click OK.

b. Create a table using a class file and execute it from NetBeans.
c. Design a form having text fields as Name, Reg No., City, Mobile No. and store the data into database table.
Q5. Differentiate between translation and request time errors. Create a sample JSP Error page and use this page in another JSP Page.
Ans:
Translation and Compilation
During the translation phase each type of data in a JSP page is treated differently. Static data is transformed into code that will emit the data into the response stream. JSP elements are treated as follows: * Directives are used to control how the web container translates and executes the JSP page. * Scripting elements are inserted into the JSP page’s servlet class. See Chapter 9, Scripting in JSP Pages for details. * Expression language expressions are passed as parameters to calls to the JSP expression evaluator. * jsp:[set|get]Property elements are converted into method calls to JavaBeans components. * jsp:[include|forward]elements are converted into invocations of the Java Servlet API. * The jsp:plugin element is converted into browser-specific markup for activating an applet. * Custom tags are converted into calls to the tag handler that implements the custom tag.
In the Application Server, the source for the servlet created from a JSP page named pageName is in this file: domain-dir/generated/jsp/j2ee-modules/WAR-NAME/pageName_jsp.java For example, the source for the index page (named index.jsp) for the date localization example discussed at the beginning of the chapter would be named: domain-dir/generated/jsp/j2ee-modules/date/index_jsp.java Both the translation and the compilation phases can yield errors that are observed only when the page is requested for the first time. If an error is encountered during either phase, the server will return JasperException and a message that includes the name of the JSP page and the line where the error occurred.
After the page has been translated and compiled, the JSP page’s servlet (for the most part) follows the servlet life cycle described in Servlet Life Cycle: 1. If an instance of the JSP page’s servlet does not exist, the container: a. Loads the JSP page’s servlet class b. Instantiates an instance of the servlet class c. Initializes the servlet instance by calling the jspInit method 2. The container invokes the _jspService method, passing request and response objects.
If the container needs to remove the JSP page’s servlet, it calls the jspDestroy method.
JSP Request Time Errors
The second type of JSP error occurs during request time. These errors are runtime errors that can occur in either the body of the JSP page or in some other object that is called from the body of the JSP page.
Request time errors result in an exception being thrown. These exceptions can be caught and appropriately handled in the body of the calling JSP, which would be the end of the error. Those exceptions that are not caught result in the forwarding of the client request, including the uncaught exception, to the error page specified by the offending JSP. The following sections describe, in detail, how to define and implement JSP error pages.

Handling JSP Page Errors
Any number of exceptions can arise when a JSP page is executed. To specify that the web container should forward control to an error page if an exception occurs, include the following page directive at the beginning of your JSP page:

<%@ page errorPage="file-name" %>
The Duke’s Bookstore application page tut-install/javaeetutorial5/examples/web/bookstore2/web/template/preludeErrorPage.jspf contains the directive:

<%@ page errorPage="errorpage.jsp"%>
The following page directive at the beginning of tut-install/javaeetutorial5/examples/web/bookstore2/web/error/errorpage.jsp indicates that it is serving as an error page:

<%@ page isErrorPage="true" %>
This directive makes an object of type javax.servlet.jsp.ErrorData available to the error page so that you can retrieve, interpret, and possibly display information about the cause of the exception in the error page. You access the error data object in an EL (see Unified Expression Language) expression by way of the page context. Thus, ${pageContext.errorData.statusCode} retrieves the status code, and ${pageContext.errorData.throwable} retrieves the exception. You can retrieve the cause of the exception using this expression:

${pageContext.errorData.throwable.cause}
For example, the error page for Duke’s Bookstore is as follows:

<%@ page isErrorPage="true" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>
<html>
<head>
<title><fmt:message key="ServerError"/></title>
</head>
<body bgcolor="white">
<h3>
<fmt:message key="ServerError"/>
</h3>
<p>
: ${pageContext.errorData.throwable.cause}
</body>
</html>
Q6. Explain about the requirements of a super-class and a sub-class while implementing Inheritance in JSP. Support the requirements mentioned in the solution by implementing it in a sample Web Application.
Ans:
To recap what you've seen before, classes can be derived from other classes. The derived class (the class that is derived from another class) is called a subclass. The class from which it's derived is called thesuperclass. The following figure illustrates these two types of classes:

In fact, in Java, all classes must be derived from some class. Which leads to the question "Where does it all begin?" The top-most class, the class from which all other classes are derived, is the Object class defined in java.lang. Object is the root of a hierarchy of classes, as illustrated in the following figure.

The subclass inherits state and behavior in the form of variables and methods from its superclass. The subclass can use just the items inherited from its superclass as is, or the subclass can modify or override it. So, as you drop down in the hierarchy, the classes become more and more specialized. sub class is the child of super class and super class is the parent of sub class sub class auto matically having all the properties of sub class and super class itsef, but super class having all the properties of super class only not the sub class properties. super class is the one which will declare members and methods and will allow all the subclasses to make use of them.

sub class is the class which inherits the mebes and methods from the super class and declares it's own members as well.