On Tue, 27 Mar 2001, Craig R. McClanahan wrote:
> > The glass is half-full as well - because at least with
> > the servlet api it is _possible_ to implement those
> > services portably and thus provide a portable JSP
> > compiler.
> >
>
> When Tomcat 4.0 was created, one of the goals was to eliminate all the
> Jasper dependencies on servlet container code (with the goal of a portable
> JSP environment). We were completely successful except for two
> (initially) and now only one issue: specifying a classpath for the Java
> compiler.
> ...
> The portability goal is definitely achievable in a Java2 world.
The only problem is that maybe trying to make jasper independent of the
container is the wrong goal...
The price is ugly ( or at least complex ) and inefficient code ( not only
because of the overhead, but also because of the missed oportunities for
optimizations ).
A quick test is very simple - in 3.3 compare the speed of
running jsps via JspServlet and JspInterceptor. ( or with the JspServlet
in 4.0 if you think the 3.x JspServlet is bad ).
I'm not saying that having a JSP implementation packaged as a servlet and
reimplementing functions of the servlet container is bad or impossible -
just that a solution where the container does servlet management and
jasper deals with converting jsps to servlets may result in cleaner code
and better performance.
I don't remember reading anywhere in the JSP spec that jasper must be
implemented as a servlet, or that it must be independent of the servlet
container. And I don't think having a good design for jasper's API that
allows it to take advantage of the container would make it less portable -
and JspServlet can still be used to plug jasper in un-cooperating
containers.
So far jasper has been one of the most stable pieces on tomcat ( most bugs
I know about are related with the interfacing between jasper and the
container ). And it has a huge potential for performance improvement - if
we do the right refactoring and provide the right internal APIs.
Costin
