> BTW, another piece of feedback - would it be possible to implement part
> of this as an interceptor ?
I was assuming for Tomcat 3.3 the JSP option properties would be
implemented in JspInterceptor since it is tied to Jasper anyway. Do you
have more general plans for JspInterceptor that would suggest these
options go in a separate interceptor?
> For the web.xml changes - you can use
> a
> context attribute too.
Since JspInterceptor provides a way to specify these options in
server.xml, I don't have a real need for a context attribute. I would
add a debugInfo property to Jasper's Options.java and with it
EmbeddedServletOptions.java. Rather than ignore the debugInfo property,
I would add a "debuginfo" init parameter to EmbeddedServletOptions.java
just so it can be controlled in web.xml, but I wouldn't anticipate using
it. I think server.xml is a more appropriate place for configuring these
options.
In addition to specifying these JSP options, I'm looking for a way to
alter the defaults that get used when these options aren't specified in
server.xml. My target is to be able run Tomcat in debugging and
non-debugging situations using the same server.xml and without modifying
server.xml to switch. Not having to ask the user to modify server.xml
helps avoid a potential source of errors and avoids the need to document
it for someone who might not be familiar with Tomcat.
So far, my best guess is to support a JSP defaults string like that
described in the earlier e-mail and obtain this string from a System
property, or perhaps a command line argument. My preference would be
as a System property.
Cheers,
Larry
