| |
| 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
%>
|
| |
[
Received from Sumit Dhamija ] |
|
| 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.
|
| |
[
Received from Sumit Dhamija ] |
|
| 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 .
|
| |
[
Received from Sumit Dhamija ] |
|
| 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.
<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
>
|
| |
[
Received from Sumit Dhamija ] |
|
| 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
<input
type="text" name="lastName"
value="<%=blanknull(lastName)%
>" >
|
| |
[
Received from Sumit Dhamija ] |
|
| 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.
|
| |
[
Received from Sumit Dhamija ] |
TOP
|
| 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.
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());
%>
|
| |
[
Received from Vishal Khasgiwala ]
|
|
|
|
