Slaza,
I summarised the thread already, but since you are determined to contribute
useful comments (:-), I thought a reply was in order.
>Ok, forgive my denseness: what's the difference between this design pattern
>(call it A) and the 'old way' (call it B)? It seems the only difference is
that
>(A) let's the getLM()-like code access local variables of the doGet()
method (I
>dont find the exception-handling objections tentible - see below).
yes, it's easy to share state, AND you get explicit control of when
LastModified is set.
>In general, it's probably simpler to turn off browser caching on error
pages
>(ie, response.setHeader("Cache-Control", "no-cache") whenever doGet()
returns an
>error page), than to keep server-side error caches (which get removed when
the
>error goes away).
This may work, although not setting LastModified in the first place would be
"cleaner". Seems it may be a bit browser dependent though...
You could also acheive this if it were possible to "unset" the LastModified
the service method sets for you...
>It seems to me that the service() method works fine (if browser is caching
URL
>and URL not stale, tell browser the URL's not stale; otherwise doGet()),
what we
>may need to get some buff server-side caching class(es). Say a
>javax.servlet.http.HttpLastModifiedCache which the app developer can
>configure/customize to fit their needs (vis-a-vis the above raised points)
and
>that can be used with getLM().
I was thinking we'd need additional class(es) but I don't have the spare
cycles to design them at the mo...
Thanks
Geoff
___________________________________________________________________________
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
