tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cmanola...@yahoo.com
Subject Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
Date Tue, 27 Mar 2001 19:20:03 GMT
> 
> 1) I don't off-hand know of any other generalized way to make a portable JSP
> compiler that can be plugged into any servlet 2.2 engine other than as a
> servlet.  I'm not sure how that limits us feature-wise, other than the fact
> that it adds a layer of indirection between the request on the container and
> the actual ultimate jsp servlet.  A small performance price to pay for
> portability.

The only problem is that the price is much higher that that:

- JspServlet must manage the servlet lifecycle - the container can no
longer treat jsp-generate-servlets the same as regular servlets

- initialization - how can you pass init parameters to the jsp ? This is
one of the worst hacks and source of counteless problems ( AFAIK - I
couldn't find any clean way to do that )

- class loader problems - again, the JspServlet must duplicate and
override the class loading decisions of the container - other problems and
issues


My point is that the servlet abstraction may not provide enough API
support for what jasper need - in order to make it work you have to
duplicate services that should be ofered by containers ( class loading,
init, reloading, admin, etc ).

I don't want to discourage you from doing that - any refactoring will help
and we badly need that. I just want to give you an alternate view, based
on my experience - before you repeat mistakes we've already done :-)




> 2) One major point of the refactoring is to minimize the role that the
> JspServlet plays.  In the model I'm advocating it only does a couple of
> things: initializes jasper (i.e., creates the JspFactory) and maintain a
> cache of JspPageHandlers to which it passes the requests.  Given this, the
> same role could be played by other entry mechanisms.

+1 


Costin


Mime
View raw message