>
> 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
