Santhosh Annira wrote:
> Craig,
>
> Thanks for the clarifications. I am all for servlets. I have already delivered
>products
> using servlets. Actually, I am spoilt by all the features that servlets support. My
>code
> hinges on the - getServletContext().getServlet("ServletName')- feature (I ignored
>the
> the warning note in Sun's documentation) . I am wondering how to fix my production
>code,
> when that feature goes away in the new servlet API specification. Do you have any
>insights
> ?
>
Yah, that one got me and everyone else too. How to fix it depends mainly on what you
are
using it for. Here's some common uses, and the approaches I would suggest to undo your
dependence on it. None of these changes are trivial, but they all will improve your
application designs:
SHARING "GLOBAL" DATA ITEMS -- In the 2.0 API, it was quite convenient to use a
particular
servlet as a "database" of sorts, without having to resort to static class variables
and
their associated problems. In the 2.1/2.2 APIs, the better place to store shared data
is in
the servlet context, as attributes. An example of this usage might be a JDBC
connection pool
that I want to make available to all of the servlets (and JSP pages) in my
application. I do
this as follows:
* Identify a particular servlet as my
"startup" servlet, and tell the servlet
engine to load it at startup time.
(JSWDK can't do this yet).
* In the init() method of the startup
servlet, create the connection pool
(based on the configuration parameters
for that servlet), and store it as an
attribute:
public void init() throws ServletException {
ConnectionPool pool = ...;
getServletConfig().getServletContext().setAttribute("pool", myPool);
}
* In the destroy() method of the startup
servlet, which will be called when the servlet
engine shuts down, gracefully close the
JDBC connections in the pool.
Using this approach, any servlet in my app can gain access to the connection pool like
this:
ConnectionPool myPool =
(ConnectionPool) getServletContext().getAttribute("pool");
or a JSP page can access it like this:
<jsp:useBean id="pool"
scope="application" type="ConnectionPool" />
SHARING METHODS -- Some developers succumb to the "I am writing a servlet based app, so
*everything* has to be a servlet" syndrome, and use their servlets essentially as a
class
library in addition to their normal purpose of creating response pages. You are
better off
extracting this kind of logic into separate objects, and turning them into shared data
that
you can access as described earlier.
IMPLEMENTING A KIND OF SERVLET CHAINING -- Perhaps what you really wanted to do was
have your
servlet decide what other servlet should really respond to this particular request,
based on
the input parameters. This is a perfect case for using a RequestDispatcher.forward()
call:
RequestDispatcher rd =
getServletContext().getRequestDispatcher("/other/servlet/path");
rd.forward(request, response);
IMPLEMENTING A KIND OF SERVER SIDE INCLUDE -- In a similar way, you can use
RequestDispatcher.include() to include the output of a different servlet at this point
in the
current response:
RequestDispatcher rd =
getServletContext().getRequestDispatcher("/other/servlet/path");
rd.forward(request, response);
All of these things are pretty major changes. However, I ended up not doing any of
them "for
real", because I went to an application design where servlets only do business logic,
and
JSP pages only do presentation. Thus, every form in the app points at a servlet that
receives the parameters, does whatever is requested, stores any results in request
attributes
or in the user's session, and forwards to an appropriate JSP page to do the response.
It's
still possible to create HTML output directly in servlets, but I personally prefer the
split
of responsibility -- it makes my designs much easier to modify later.
>
> Thanks
> Santhosh.
>
Craig
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
