16: 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());
%>
17: 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.
18: 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 <hs@webapp.de> & Peter Rossbach
<pr@webapp.de>) 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.
19: Explain the life cycle methods of a Servlet.
A: The javax.servlet.Servlet interface defines the three methods known as
life-cycle method.
public void init(ServletConfig config) throws ServletException
public void service( ServletRequest req, ServletResponse res) throws
ServletException, IOException
public void destroy()
First the servlet is constructed, then initialized wih the init() method.
Any request from client are handled initially by the service() method before
delegating to the doXxx() methods in the case of HttpServlet.
The servlet is removed from service, destroyed with the destroy() methid, then
garbaged collected and finalized.
20: What is the difference between the getRequestDispatcher(String path) method of javax.servlet.ServletRequest interface and javax.servlet.ServletContext
interface?
A: The getRequestDispatcher(String path) method of
javax.servlet.ServletRequest interface accepts parameter the path to the resource
to be included or forwarded to, which can be relative to the request of the calling
servlet. If the path begins with a "/" it is interpreted as relative to the current
context root.
The getRequestDispatcher(String path) method of javax.servlet.ServletContext
interface cannot accepts relative paths. All path must sart with a "/" and are
interpreted as relative to curent context root.
Thursday, May 8, 2008
Subscribe to:
Post Comments (Atom)
2 comments:
Hi, in your answer to question 20 - your answer seems to not make a distinction between the two options. In both cases you refer to getRequestDispatcher..
Hi there is a distinction.It is for The getRequestDispatcher(String path)method of
javax.servlet.ServletRequest interface and The getRequestDispatcher(String path) method of javax.servlet.ServletContext
interface.
Please read the answer again
Post a Comment