Geoff Soutter wrote:
> Craig R. McClanahan wrote:
> >Geoff Soutter wrote:
> >> [snip]
> >> What bugs me about this whole buffering thing is that the buffering
> scheme I
> >> have written for 2.0/2.1 servlets works just as well as the one in 2.2.
> >> However, the things that only the servlet API could do for buffering were
> >> not included... e.g. buffering a RD.include() and letting me extract the
> >> results from the buffer. :-(
> >>
> >
> >That one (post-processing included output) is a *whole* different kettle of
> >fish -- which has triggered lots of discussion and debate over the lifetime
> of
> >the servlet API. Look back in the archives at all the flamewar message
> threads
> >about "servlet chaining" to see what I mean. :-)
>
> hmmm, isn't servlet chaining where you can set the servlet engine up to
> automatically "filter" requests through multiple servlets? I always thought
> that was a crock... I'm suggesting a kind of "manual" version where it's all
> under the explicit control of the coder... certainly servlet chaining was
> around a long time before RD.include() !
>
If all you need is post-processing included text, you don't need any changes to
the servlet API to do it. There's two major variations on the theme.
To post-process static content, you can use getResource() instead of
RequestDispatcher.include() to grab the data, and do whatever is needed. Where
the data really comes from is a configuration issue for the servlet engine --
for example, with the JSWDK engine you can set the document root of a servlet
context to an http://www.mycompany.com/mydirectory type URL, so the resources
don't have to be local. If they are local, you can use a relative directory or
a file://xxx type URL instead.
To post-process dynamic output (servlets, JSP pages, CGI scripts, etc.) you can
always use a URLConnection from within your servlet. Whether there's a
significant performance hit for this or not depends on the underling
URLStreamHandler that is used -- it is entirely reasonable for a servlet engine
to include a specialized stream handler that has "insider knowlege" of the
servlet engine, so it can access servlets directly instead of through a TCP/IP
connection.
>
> Cheers
>
> Geoff
>
Craig
___________________________________________________________________________
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
