TABLE OF CONTENTS
How do I communicate with a JSP page from an applet?
How does the performance of JSP pages compare with that of servlets? How does it compare with Perl scripts?
What’s the difference between the JSDK and the JSWDK? And what’s the current version?
How can I get to print the stacktrace for an exception occuring within my JSP page?
Can I invoke a JSP error page from a servlet?
How can I send email from a JSP page?
How do I use a scriptlet to initialize a newly instantiated bean?
Can you make use of a ServletOutputStream object from within a JSP page?
How can I enable session tracking for JSP pages if the browser has disabled cookies?
How can I declare methods within my JSP page?
Can I stop JSP execution while in the midst of processing a request?
Is there a way I can set the inactivity lease period on a per-session basis?
How can I get to view any compilation/parsing errors at the client while developing JSP pages?
How can I delete a cookie from within a JSP page?
How do I set a cookie within a JSP page?
Can a JSP page instantiate a serialized bean?
Is there a way to reference the “this” variable within a JSP page?
Can JSPs and servlets share the same session?
Show me an example of POST request chaining using JSPs and servlets
How does a servlet communicate with a JSP page?
JSP 0.91 and 0.92 specifications are no longer available at java.sun.com. Is there somewhere else I can download them?
Where can I find the complete list of commercial vendor support for JSP?
Are there any JSP engines which support JavaScript?
How does the “application” scope work with the useBean tag?
My JSP file compiles just fine…but I always get a NoClassDefFoundError when I try to access a bean via the useBean tag. Why?
How can I implement a thread-safe JSP page?
Can a JSP page process HTML FORM data?
How does JSP handle run-time exceptions?
What JSP lifecycle methods can I override?
How can I override the jspInit() and jspDestroy() methods within a JSP page?
How do I include static files within a JSP page?
How do I use comments within a JSP page?
How do I perform browser redirection from a JSP page?
How do I prevent the output of my JSP pages from being cached by the browser?
It’s similar to communication between Servlet and Applet. I’m also suffering for that. In applet, there is no problem when posting a request to JSP. But in case of getting a response of JSP, “java.io.StreamCorruptedException” occurs if I use ObjectInputStream. It’s fine, however, if I use InputStreamReader. Confer the sample below.
/** applet */
:
// Get URLConnection
String urlStr = “http://www.webtrack.co.kr/jsp/appletproxy.jsp”;
URL serverURL = new URL(urlStr);
URLConnection uc = serverURL.openConnection();
uc.setDoOutput(true); // intends to write data to the URL connection
uc.setUseCaches(false); // the protocol must always try to get a fresh copy of the object
uc.setRequestProperty(”Content-type”, “application/octet-stream”);
// Request(POST)
ObjectOutputStream objOut = new ObjectOutputStream(uc.getOutputStream());
objOut.writeObject(new String(”Hello, acidzazz?”));
objOut.flush();
objOut.close();
// Get Server’s response
ObjectInputStream objIn = new ObjectInputStream(uc.getInputStream());
BufferedReader ir = new BufferedReader(new InputStreamReader(uc.getInputStream()));
String s = “”;
while( (s = ir.readLine()) != null )
System.out.println(s);
ir.close();
:
/** JSP */
:
<%
// Get Request(POST) of applet
ObjectInputStream objIn = new ObjectInputStream(request.getInputStream());
userID = (String)objIn.readObject();
objIn.close();
// Response to Applet
response.setContentType(”application/octet-stream”);
ObjectOutputStream objOut = new ObjectOutputStream(response.getOutputStream());
objOut.writeObject(new String(”Hello, applet”);
objOut.flush();
objOut.close();
:
%>
The performance of JSP pages is very close to that of servlets. However, users may experience a perceptible delay when a JSP page is accessed for the very first time. This is because the JSP page undergoes a “translation phase” wherein it is converted into a servlet by the JSP engine. Once this servlet is dynamically compiled and loaded into memory, it follows the servlet life cycle for request processing. Here, the jspInit() method is automatically invoked by the JSP engine upon loading the servlet, followed by the _jspService() method, which is responsible for request processing and replying to the client. Do note that the lifetime of this servlet is non-deterministic – it may be removed from memory at any time by the JSP engine for resource-related reasons. When this happens, the JSP engine automatically invokes the jspDestroy() method allowing the servlet to free any previously allocated resources.
Subsequent client requests to the JSP page does not result in a repeat of the translation phase as long as the servlet is cached in memory, and are directly handled by the servlet’s service() method in a concurrent fashion (i.e. the service() method handles each client request within a seperate thread concurrently.)
There have been some recent studies contrasting the performance of servlets with Perl scripts running in a “real-life” environment. The results are favorable to servlets, especially when they are running in a clustered environment. For details, see:
http://www.objexcel.com/workingjava.htm#Web Server Benchmarks
The kit for developing servlets, containing the Servlet API classes and tools, used to be called the Java Servlet Development Kit (JSDK). Then Sun renamed the Java Development Kit (JDK) to the Java 2 Software Development Kit (J2SDK). Since J2SDK sounds a lot like JSDK, the Servlet team renamed JSDK to JavaServer Web Development Kit (JSWDK). (They also added support for JSPs.)
Here’s where it gets confusing. When they renamed it, they also renumbered it. So the JSWDK 1.0 is actually more recent than the JSDK 2.1. It’s also confusing that when people want to develop servlets, they have to download something called a JavaServer Web Development Kit, which sounds like it should be used to develop servers, not servlets.
A further confusion is that the Servlet spec is developed independently from the JSP spec, and they both have different versions than the JSDK/JSWDK.
The following table summarizes the confusion.
|
Product
|
Version
|
Servlet spec
|
JSP spec
|
|
Tomcat
|
3.0
|
2.2
|
1.1
|
|
JSWDK
|
1.0.1
|
2.1
|
1.0.1
|
|
JSDK
|
2.1
|
2.1
|
none
|
|
JSDK
|
2.0
|
2.0
|
none
|
Make sure you look for the “W”!
By printing out the exception’s stack trace, you can usually diagonse a problem better when debugging JSP pages. By looking at a stack trace, a programmer should be able to discern which method threw the exception and which method called that method.
However, you cannot print the stacktrace using the JSP out implicit variable, which is of type JspWriter. You will have to use a PrintWriter object instead. The following snippet demonstrates how you can print a stacktrace from within a JSP error page:
<%@ page isErrorPage=”true” %>
<%
out.println(”<pre>”);
PrintWriter pw = response.getWriter();
exception.printStackTrace(pw);
out.println(”</pre>”);
%>
Yes, you can invoke the JSP error page and pass the exception object to it from within a servlet. The trick is to create a request dispatcher for the JSP error page, and pass the exception object as a javax.servlet.jsp.jspException request attribute. However, note that you can do this from only within controller servlets. If your servlet opens an OutputStream or PrintWriter, the JSP engine will throw the following translation error:
java.lang.IllegalStateException: Cannot forward as OutputStream or Writer has already been obtained
The following code snippet demonstrates the invocation of a JSP error page from within a controller servlet:
protected void sendErrorRedirect(HttpServletRequest request, HttpServletResponse response, String errorPageURL, Throwable e)
throws ServletException, IOException {
request.setAttribute (”javax.servlet.jsp.jspException”, e);
getServletConfig().getServletContext().getRequestDispatcher(errorPageURL).forward(request, response);
}
public void doPost(HttpServletRequest request, HttpServletResponse response) {
try {
// do something
} catch (Exception ex) {
try {
sendErrorRedirect(request,response,”/jsp/MyErrorPage.jsp”,ex);
} catch (Exception e) {
e.printStackTrace();
}
}
}
You can send email from any JSP engine (like the JSWDK reference implementation) that supports the Sun specific sun.net.smtp package.
(Statutory warning: Using internal Sun-specific packages is not an approach jGuru recommends, as it will prevent your JSP pages from being truly portable.)
The following scriptlet makes use of the SmtpClient class to send an email from within a JSP page.
<%@ page import=”sun.net.smtp.SmtpClient, java.io.*” %>
<%
String from=”gseshadri@hotmail.com”;
String to=”govind@jguru.com, govi@bigfoot.com”;
try{
SmtpClient client = new SmtpClient(”mail.perspex.com”);
client.from(from);
client.to(to);
PrintStream message = client.startMessage();
message.println(”To: ” + to);
message.println(”Subject: Sending email from JSP!”);
message.println(”This was sent from a JSP page!”);
message.println();
message.println(”Cool beans!
”);
message.println();
message.println(”Govind Seshadri”);
message.println(”jGuru.com”);
message.println();
client.closeServer();
}
catch (IOException e){
System.out.println(”ERROR SENDING EMAIL:”+e);
}
%>
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.
<jsp:useBean id=”foo” class=”com.Bar.Foo” >
<jsp:setProperty name=”foo” property=”today” value=”<%=java.text.DateFormat.getDateInstance().format(new java.util.Date())
%>”/>
<%– scriptlets calling bean setter methods go here –%>
</jsp:useBean >
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. A page author can always disable the default buffering for any page using a page directive as:
<%@ page buffer=”none” %>
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.
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.
hello1.jsp
<%@ page session=”true” %>
<%
Integer num = new Integer(100);
session.putValue(”num”,num);
String url =response.encodeURL(”hello2.jsp”);
%>
<a href=’<%=url%>’>hello2.jsp</a>
hello2.jsp
<%@ page session=”true” %>
<%
Integer i= (Integer )session.getValue(”num”);
out.println(”Num value in session is “+i.intValue());
%>
What’s a better approach for enabling thread-safe servlets and JSPs? SingleThreadModel Interface or Synchronization?
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 usuage is non-deterministic, it may not help much even if you did add more memory and increased the size of the instance pool.
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:
<%!
public String whereFrom(HttpServletRequest req) {
HttpSession ses = req.getSession();
…
return req.getRemoteHost();
}
%>
<%
out.print(”Hi there, I see that you are coming in from “);
%>
<%= whereFrom(request) %>
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 (asuming Java is your scripting language) is to use the return statement when you want to terminate further processing.
For example, consider:
<%
if (request.getParameter(”foo”) != null) {
// generate some html or update bean property
} else {
/* output some error message or provide redirection
back to the input form after creating a memento
bean updated with the ‘valid’ form elements that were input.
this bean can now be used by the previous form to initialize
the input elements that were valid
then, return from the body of the _jspService() method to
terminate further processing */
return;
}
%>
Typically, a default inactivity lease period for all sessions is set within your JSP engine 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. For example:
<%
session.setMaxInactiveInterval(300);
%>
would reset the inactivity period for this session to 5 minutes. The inactivity interval is set in seconds.
With JSWDK 1.0, set the following servlet initialization property within the \WEB-INF\servlets.properties file for your application:
jsp.initparams=sendErrToClient=true
This will cause any compilation/parsing errors to be sent as part of the response to the client.
A cookie, mycookie, can be deleted using the following scriptlet:
<%
Cookie killMyCookie = new Cookie(”mycookie”, null);
killMyCookie.setMaxAge(0);
killMyCookie.setPath(”/”);
response.addCookie(killMyCookie);
%>
Setting cookies from within a JSP page is similar to the way they are done within servlets. For example, the following scriptlet sets a cookie “mycookie” at the client:
<%
Cookie mycookie = new Cookie(”aName”,”aValue”);
response.addCookie(mycookie);
%>
Typically, cookies are set at the beginning of a JSP page, as they are sent out as part of the HTTP headers.
No problem! The useBean action specifies the beanName attribute, which can be used for indicating a serialized bean. For example:
<jsp:useBean id=”shop” type=”shopping.CD” beanName=”CD” />
<jsp:getProperty name=”shop” property=”album” />
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-INF\jsp\beans directory for it to be located by the JSP engine.
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.
With Sun’s JSWDK 1.0, I can access only the class file for the servlet generated from my JSP page. Is there a way to see the Java source for the generated servlets?
For Sun’s JSWDK 1.0, set the initialization parameter:
jsp.initparams=keepgenerated=true
This can be found within the web-inf/servlets.properties file for your application.
When this is passed to your JSP servlet, it will preserve the Java source along with the class file in the work subdirectory for the engine.
Yes, of course. Remember, JSPs are always translated into their servlet equivalent before they are initialized and ready to process incoming requests. JSP pages are also provided with the session implicit object which allows them to completely manage the session, including its creation and invalidation.
Any bean or object placed by the JSP page into the session can be later used by any other servlet or JSP page belonging to the same session.
The following code example demonstrates how request chaining can be implemented using a combination of JSPs and servlets.
Consider the following JSP page, say Bean1.jsp, which essentially instantiates the bean fBean, places it in the request, and forwards the call to the servlet JSP2Servlet. Observe the way the bean is instantiated – here we automatically call the bean’s setter methods for properties which match the names of the posted form elements, while passing the corrosponding values to the methods.
<html>
<body>
<jsp:useBean id=”fBean” class=”govi.FormBean” scope=”request”/>
<jsp:setProperty name=”fBean” property=”*” />
<jsp:forward page=”/servlet/JSP2Servlet” />
</body>
</html>
The servlet JSP2Servlet now extracts the bean passed to it from the request, makes changes using the appropriate setters, and forwards the call to another JSP page Bean2.jsp using a request dispatcher. Note that this servlet, acting as a controller, can also place additional beans if necessary, within the request.
public void doPost (HttpServletRequest request,
HttpServletResponse response) {
try {
FormBean f = (FormBean) request.getAttribute (”fBean”);
f.setName(”Mogambo”);
// do whatever else necessary
getServletConfig().getServletContext().
getRequestDispatcher(”/jsp/Bean2.jsp”).
forward(request, response);
} catch (Exception ex) {
. . .
}
}
The JSP page Bean2.jsp can now extract the bean fBean (and whatever other beans that may have been passed by the controller servlet) from the request and extract its properties.
<html>
<body>
Within JSP2
<P>
<jsp:useBean id=”fBean” class=”govi.FormBean” scope=”request”/>
<jsp:getProperty name=”fBean” property=”name” />
</body>
</html>
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, after 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” />
Yes. You can download JSP 0.91 specification at http://www.kirkdorffer.com/jspspecs/jsp091.html.
JSP 0.92 specification can be downloaded from http://www.kirkdorffer.com/jspspecs/jsp092.html
Daniel Kirkdorffer maintains a regularly updated list of products which support the JSP API. You can access it at http://www.interpasnet.com/JSS/textes/jsp2.htm.
Yes. Resin 1.0 from Caucho Technologies supports both Java and JavaScript for scripting and implements JSP 1.0.
PolyJSP from Plenix supports Java, JavaScript and WebL for scripting, and implements JSP 0.92.
Consider the following example:
<useBean id=”counter” class=”foo.Counter” scope=”application” />
In this example, when the Counter bean is instantiated, it is placed within the servlet context, and can be accessed by any JSP or servlet that belong to the application (i.e. belongs to the same servlet context).
The servlet equivalent of the above useBean action is:
getServletContext().setAttribute(”counter”, new foo.Counter());
If the bean was previously created by another JSP or servlet and was placed within the application (servlet) context, the useBean action would then serve to retrieve the object.
The servlet equivalent of retrieving a bean from the application context is:
foo.Counter ctr = (foo.Counter) getServletContext().getAttribute(”counter”);
Make sure your beans belong to a package, and that you are fully qualifying the bean when indicating the value for the class attribute. For example, if your bean abc.class belongs to the package foo, make sure you indicate the value for the class attribute as:
<useBean id=”mybean” class=”foo.abc” scope=”session” />
and not as:
<useBean id=”mybean” class=”abc” scope=”session” />
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.
Yes. However, unlike servlets, 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:
<%
String item = request.getParameter(”item”);
int howMany = new Integer(request.getParameter(”units”))
.intValue();
%>
or
<%= request.getParameter(”item”) %>
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” %>
the 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.
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:
<%!
public void jspInit() {
. . .
}
%>
<%!
public void jspDestroy() {
. . .
}
%>
Static resources should always be included using the JSP include directive. This way, the inclusion is performed just once during the translation phase. The following example shows the syntax:
<%@ include file=”copyright.html” %>
Do note that you should always supply a relative URL for the file attribute.
Although you can also include static resources using the action, this is not advisable as the inclusion is then performed for each and every request.
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:
<%– the scriptlet is now commented out
<%
out.println(”Hello World”);
%>
–%>
You can also use HTML-style comments anywhere within your JSP page. These comments are visible at the client. For example:
<!– (c)1999 jGuru.com –>
Of course, you can also use comments supported by your JSP scripting language within your scriptlets. For example, assuming Java is the scripting language, you can have:
<%
//some comment
/**
yet another comment
**/
%>
You can use the response implicit object to redirect the browser to a different resource, as:
response.sendRedirect(”http://www.foo.com/path/error.html”);
You can also physically alter the Location HTTP header attribute, as shown below:
<%
response.setStatus(HttpServletResponse.SC_MOVED_PERMANENTLY);
String newLocn = “/newpath/index.html”;
response.setHeader(”Location”,newLocn);
%>
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 %>