× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Servlet question, WAS 3.5.2
  • From: "Art Smet" <smet@xxxxxxxxxx>
  • Date: Thu, 8 Feb 2001 12:08:13 -0600
  • Importance: Normal


The question of whether to override service( ) vs doGet( )/doPost( ) of a
servlet has come up, and thought I'd try to clear this up.  On the client
side unless an action like "POST" is explicitly issued, "GET" will be the
default.  But that does not mean a doPost( ) or doGet( ) will be
necessarily invoked in the target servlet.

To understand why, it is important to understand the subclass relationship
between a "GenericServlet" (base class) and the "HttpServlet" (subclass of
GenericServlet).  The heart of the GenericServlet is the service( ) method
which you override to get anything useful done - there is no doGet( ) or
doPost( ).  Contrast this with the HttpServlet, which overrides the service
( ) method which merely decodes the incoming HttpRequest to decide whether
it is for a GET, POST, or other and then calls the appropriate method:
doGet( ), doPost( ), or other method.  The service( ) method in the
HttpRequest is rendered to nothing more than a router to the appropriate
method.

Most people routinely code their servlets as HttpServlet's, which may be
okay with them since they have access to a wider set of api's and avoid
learning the limitations  GenericServlet's.  For such folks, the only
option in their world is to override doGet( ) or doPost( ).  But there is
nothing stopping folks from having their HttpRequests be targetted to a
GenericServlet if they want to, in which case they must override the
service( ) method to get any useful work done - there is no doPost( ) or
doGet( ) involved.  If there is a GET embedded in the incoming HttpRequest,
the GenericServlet pays no attention to it.  Those who want to eke better
performance might want to use a lightweight GenericServlet over an
HttpServlet.

So if there are any samples out there that show the service( ) method being
overriden, I suspect it is in the context of a GenericServlet.  If so,
there is nothing flaky about it as that is the only way.

How do JSPs fit into this picture?  When a JSP is compiled, you will find
the service( ) method gets generated in the source.   So it is a hybrid of
sorts because it is an HttpServlet with just a service( ) method
implemented.  So GETs or POSTs that make their way to a JSP from other
servlets, all get funneled to the same service( ) method.  JSPs can get
away with this because no one ever subclasses or overrides the JSP itself.

Art


"Joe Pluta" <joepluta@plutabrothers.com>@midrange.com on 02/08/2001
10:18:48 AM

Please respond to JAVA400-L@midrange.com

Sent by:  owner-java400-l@midrange.com


To:   <JAVA400-L@midrange.com>
cc:
Fax to:
Subject:  RE: Servlet question, WAS 3.5.2



Frances, this is very interesting and enlightening information.  I've often
wondered about this.  I had always assume that the method invoked by
HttpServlet is based on the type of HTTP request.  However, I had also
assumed that a direct link to a servlet using the <a href=...> technique
caused the browser to issue an HTTP GET.  Is this incorrect??

Similarly, what happens with a JSP forward?  What type of "request" is
forwarded?  Wouldn't it be the same as the request that originally invoked
the servlet doing the forwarding?

I suppose I ought to add my usual addendum: "And if you know of links to
any more information on this subject, please feel free to let me know"
<grin>.  Specifically, I'd love some documents on the internals of the
interactions between browsers, application servers and servlets.  The
Javadoc is good for implementation, but doesn't really tell me much about
the internals.

Joe

---------- Original Message ----------------------------------
From: "Frances Stewart" <francess@us.ibm.com>
Reply-To: JAVA400-L@midrange.com
Date: Thu, 8 Feb 2001 09:38:25 -0600

>
It is not necessarily incorrect to override the service() method. It
depends on how you plan on the servlet being invoked. If the servlet will
only be invoked as the result of a
 <FORM METHOD="post" ACTION=.../> or <FORM METHOD="get" ACTION=.../>, etc.
tag, then you should not override service() and you should implement doGet
and doPost.

However, if your servlet will be invoked from a JSP using forward, or if
you will invoke the servlet directly from an HTML tag such as <a href
="http://as400service.ibm.com/servlet/EstimatorServlet">Workload
Estimator</a>, you will need to implement the service() method.

There are two classes, GenericServlet and HttpServlet.  HttpServlet extends
GenericServlet and adds the doXXX methods which add functionality for
invoking the servlet from an HTML page. The Javadoc for both classes can be
seen at http://java.sun.com:80/products/servlet/2.3/javadoc/index.html.


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---



+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.