Geoff Soutter wrote:
> Craig R. McClanahan wrote:
> >"Rogatkin, Dmitry M" wrote:
> >
> >> > While agreeing with Milt's reasoning, I would point out at least one
> >> > significant feature that you give up when you override the service()
> >> method --
> >> > conditional GET support. This allows your servlet (if it appropriately
> >> > implements the getLastModified() method and does *not* override the
> >> standard
> >> > service() method) to send back a NOT_MODIFIED response to the client,
> and
> >> thus
> >> > avoid having to download a page that has not changed since the last
> time
> >> it
> >> > was requested.
> >> Why calling super.service() doesn't work in this case?
> >>
> >
> >Yes, calling super.service() will perform the conditional GET support, but
> it
> >will also do everything else it already does, including call your
> >doGet()/doPost()/etc. method.
>
> Sorry to disappoint you fans of getLastModified() :-), but I actually tried
> to use the conditional GET support implemented in service() and found it to
> be be next to useless in a real environment. I ended up having to write it
> myself.
>
> Geoff
>
Geoff, I haven't used getLastModified() a lot -- it's pretty useless for 100%
dynamic content -- but it seems to do what I wanted when I used it. See
further comments below.
>
> here's a copy of the relevant stuff I sent to the API feedback...
>
> 1) it doesn't allow you to easily share state with doGet(), which you almost
> always want to do
Because getLastModified() -- getLM for short -- is passed the incoming request,
it has access to all of the attributes of that request (the request URI and
other request properties, the HTTP headers, included cookies, and the user's
session if there is one). The session can be the key to sharing things if your
needs go beyond the parameters of the individual request. You can have the
servlet that generates the actual content store things useful in making
subsequent getLM calls run faster. Likewise, you can also have getLM store
things in the session for later use in the doGet call, if they are expensive to
calculate.
Of course, if you're not using sessions, there isn't the opportunity to do
this.
>
> 2) there's no easy way co-ordinate error handling between getLM() and
> doGet() (you can't even throw a ServletException from getLM()).
If I suspect there is a problem, or run into difficulties calculating the
timestamp to return, I return -1 from getLM and let doGet() deal with it.
Of course, I never design my servlets to *purposely* throw any exception,
because the user-visible result is invariably ugly. There's always the
occasional NullPointerException and other unchecked exceptions, but those are
bugs that need to be fixed, not normal occurrences.
>
> 3) getLM() will set LastModified even if doGet() fails and throws an
> exception. This means that the client will try and cache your "error" page
> (unless you do a sendError() or somesuch).
>
I have found this to be true with static HTML pages as well. Have you ever
pressed STOP during a long page display (in Netscape Navigator), see the
"Transfer Interrupted" message, and you can't get rid of it, even by pressing
Reload? The last time I looked at this, I concluded it had to be based on
conditional GET responses because I've got Netscape configured to check for
updates "once per session".
>
> I suggested that making the logic in gLM() available to be called from
> _within_ doGet() would be much more useful in general.
>
Given that the service() method needs to call getLastModified() before calling
doGet() -- to decide whether to send a NOT MODIFIED response back -- that would
seem to defeat the purpose.
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
