----------------------------------------------------
Please read the FAQ at <http://java.apache.org/faq/>
It has a search feature and all the answers!
----------------------------------------------------
>
> > Servlet chaining allow you to drop the thread of the previous servlet and
> > having a new one starting to handle the next step which could be formatting
> > the response according to a device.
>
> So, why not do that within your code? Why hack the server to do such a
> thing?
>
As a nit, if you are talking about Java threads when you say "drop the thread of
the previous servlet", that isn't what you really want to do. Remember, the user
is still waiting for the initial response, which was handed to the initial thread
that is handling it. From a server overhead point of view, you would really want
to avoid having to create more than one thread (either from scratch or by
allocation from a thread pool) for the same request.
>
> > Anyhow is there a place talking about
> > why it is a bad idea and how to design a solution to solve the same type of
> > problem.
>
> [EMAIL PROTECTED]
>
For what it's worth, I'll describe some of the problems that I have with "servlet
chaining":
* The servlet API is fundamentally based on the request-response
nature of the HTTP protocol. Embedded in it are assumptions that
make it easy to stay HTTP-compliant. If you do things like chaining,
you are going to have problems with these assumptions. For example,
what do you do with the headers from the earlier response? Do you
ignore them, do you combine them somehow? Other considerations
apply as well -- who is responsible for buffering the first response?
What if the first response tries to do a sendRedirect()? What do you
do about query parameters? Cookies? It is not at all obvious that
one can specify a standard that covers all of this in a manner that
suits *all* possible users.
* Chaining encourages a design model that says "everything should
be a servlet", even when that isn't necessary. In many cases where
servlet chaining looks appropriate, you can accomplish the same thing
in other ways. If you're going to post-process the output of a previous
servlet, why make that one a servlet? It could just as well output a
DOM tree, or a bunch of Java objects that are formatted by the servlet
based on the characteristics of the ultimate requestor.
* The desired behavior can be completely done at the application level
(i.e. inside one of your servlets), with no help required by the API. This
is true even if the output you are post-processing really does come from
a servlet -- all you need to do is mimic the basic lifecycle features of a
servlet engine. (By the way, this is essentially what a JSP engine does --
and it needs no assistance from the servlet engine to do so.)
* The desired behavior tends to be application specific. Generic APIs should
provide the minimum common functionality that *everyone* needs. Trying to
do this for chaining is difficult because the needs vary. This is the same
reason
you don't see much direct support for caching in the API -- the number of
different reasons that a particular servlet might decide to cache or not cache
a particular response are staggering in number.
* Servlet chaining was first introduced by some engines (i.e. outside the API,
both then and now) before it became clear where the API was headed. A lot
has been learned since then about proper designs for web-based apps.
What you see today are a variety of architectural approaches (such as
servlet-based frameworks like Dash, template systems like Webmacro and
FreeMaker, and tag-oriented systems like JSP) that are better suited to the
environment. They all leverage the fundamental object-oriented nature of Java,
and help you avoid the temptation built in to the old cliche: "when you only
have
a hammer, everything in the world looks like a nail." Don't limit your
thinking by
assuming that everything in a servlet-based app has to be a servlet.
Craig McClanahan
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
