You can think of this answer as the same reason why Apache doesn't support ASP pages directly.

----------
From: James Davidson James.Davidson@Eng.Sun.COM
To: SERVLET-INTEREST@JAVA.SUN.COM
Subject: Re: can anyone answer this?
Date: Fri, Aug 13, 1999, 12:25 PM

Servlet chaining is non-portable between servers -- it's not even part of the
servlet specification. Use request dispatchers instead, or better yet, refactor
your application.

Remember that servlets should be an "entry point" into your application -- just
like `public static void main(String[] args)`. You wouldn't call component
through their public static void main methods in most cases, why should your
servlets be any different? Food for thought.

.duncan

----------
From: "Craig McClanahan" cmcclanahan@mytownnet.com
To: Java Apache Users java-apache-users@list.working-dogs.com
Subject: Re: WAS: forcing apache to interpret servlet tags
Date: Tue, Oct 12, 1999, 2:47 PM

> > 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.
>
> servlet-feedback@java.sun.com

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