I disagree. One should apply traditional optimization procedures and good
solid engineering principles to decide if this tradeoff is worth it or not.
FWIW, Craig I see disagrees with me, but here are some of the pros and cons.
You would do best to consider these for your own particular situation and
make the decision:
Pros - overriding service
-------------------------------------------------
- faster, doesn't have to do unnecessary comparisons of the HTTP request
(GET, POST) and polymorphic calls (arguably not that big of a deal, ALL
java calls are polymorphic lookups anyway) - maybe you don't care and want
to treat all HTTP requests the same, or you know that you will always want
to treat them the same
- cleaner, from a certain point of view. If you make a single function that
all of the HTTP request methods have to call, then your app structure looks
like this:
HTTPRequestServlet::service
|
+-------------------+----------+----...
| | |
Your Servlet::GET ::POST ::HEAD ...
| | |
+-------------------+----------+
|
Your Servlet::CommonHandler
See how silly that looks?
Cons - overriding service
-------------------------------------------------
- don't get advantage of automatic (correct) handling of all HTTP requests
- harder to maintain(??? Suggested by someone on the list, but I don't
think so given proper comments -- do people still use those these days?
;-) )
Pros - calling a common method
-------------------------------------------------
- cleaner code? from a certain point of view ;-)
- handles HTTP requests correctly, now and in the future too (HTTP/1.2 ???)
Cons - calling a common method
-------------------------------------------------
- slower, lots of function calls in the way and have to compare the HTTP
request to find out what method to call
- not as clean? from a certain point of view...
These are just some things to consider (don't flame me if there are more, I
am *SURE* there are others I have missed).
I have servlet that is performance critical. Thus I do want to squeeze as
much performance out of it as possible. I also don't expect anything but
GET and POST to come into this servlet, and for either one I handle the
request the same.
Thus I override the service method :)
-tg
----- Original Message -----
From: Kirkdorffer, Daniel <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 12, 1999 11:37 AM
Subject: Re: doPost versus doGet - DESIGN DECISION???
> And based on that information I would say don't override service(). There
> is also the inefficiency of maintenance of such overriden methods by
persons
> not familiar with why it was done. I think the cleaner approach is
leaving
> service alone - regardless of what your Weblogic instructor told you.
>
> Dan
>
> > ----------
> > From: Craig McClanahan[SMTP:[EMAIL PROTECTED]]
> > Reply To: Craig McClanahan
> > Sent: Tuesday, October 12, 1999 10:21 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: doPost versus doGet - DESIGN DECISION???
> >
> > Nanduri Amarnath wrote:
> >
> > > Hi Guys,
> > > I recently had WebLogic training and this Instructor said that
> > instead of
> > > using the
> > > doGet() (or) the doPost() method, over-write the service() method. He
> > says that
> > > if you use either a
> > > doGet() (or) doPost() method, the WebServer has to do a POLYMORPHIC
> > lookup on
> > > these methods in the
> > > service() method. This will lead to a little bit of in-efficiency.
> > Instead if
> > > you over-write the service() method, there
> > > won't be any polymorphic lookup. I argued with him that the Java
> > Servlet
> > > specs..tell us not to over-write the
> > > service() method, but to no avail . Any suggestions - comments
welcome.
> > >
> > > Cheers,
> > > Amar..
> > >
> >
> > Overriding the service() method is certainly legal Java code. However,
> > doing so
> > means you give up *all* of the default processing that
> > HttpServlet.service() does.
> > Among other things, that includes:
> >
> > * Dispatching requests based on the HTTP method that
> > was requested, including rejecting those that are not
> > supported by this servlet.
> >
> > * Handling the "If-Modified-Since" header and calling your
> > getLastModified() method. These techniques are used
> > to avoid re-downloading a response that has not been
> > changed.
> >
> > * Handling the HEAD request transparently (returns just
> > the HTTP headers instead of the entire body.
> >
> > Craig McClanahan
> >
> >
==========================================================================
> > =
> > 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
> >
>
>
===========================================================================
> 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
>
===========================================================================
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
