Jsp init-params working

[Robert Quillen <ro...@fastforms.com>]

I've managed to get jsp init parameters working with some modifications to 
JspInterceptor and ServletWrapper.  It's very ugly right now, so I'm going
to
do a bit of refactoring before submitting the patch.

BTW, why was most of the web.xml properties moved from ServletWrapper
into Handler?  Handler is the base class of several other classes that don't
have anything to do with web.xml.  FileHandler and DirHandler from 
StaticInterceptor come immediately to mind.  I don't see any reason to
inflict
those member variables on them.  The only reason I can think of is that
were moved there as a refactoring in anticipation of a JspHandler, but
that's
not needed.  After JspInterceptor does it's bit, all jsps reduce to servlets
that ServletWrapper handles just fine.  So does anyone mind if I pull these
members back down into ServletWrapper?

I also removed the default addition of JspServlet and the *.jsp ->
JspServlet
mapping to the Context in WebXmlReader.  JspInterceptor didn't work out
of the box in this configuration.  It didn't check the request for the *.jsp
mapping.

Removing JspServlet caused a few problems with AccessInterceptor as well.
It was doing some inappropriate stuff in it's addContainer hook.  If a web
app's
web.xml file does not contain at least one <servlet> entry, the addContainer
hook will not ever be called.  The bug was masked because the default
addition of the JspServlet causes addContainer to be called even when the
web.xml doesn't specify any servlets.  I have a patch for this as well.  I
just
needed to rearrange a few lines.

Other interceptors may have similar bugs due to depending on addContainer
being called being called before web.xml is read.

I'm going to submit a patch with these changes in a few days.  I need to add
a jsp init param test to watchdog, and make sure watchdog is passes
everything
else first.  

Robert Quillen