> My preference would be to set the options on JspInterceptor, using the
> server.xml format.
> Context and ContextManager shouldn't know/care about what happens in
> interceptors unless it's absolutely needed. I think the biggest
> priority
> right now is to make sure all 9 core objects are "as simple as possible
> and not simpler" - i.e. we should review all existing properties and
> find
> if they are indeed of general interest.
I agree. For some reason, I seem to be having trouble actually
following the design philosophy in practice. Something must be thicker
than I realize. :-) Thanks for fixing the goof in my earlier commit.
I'm also not doing a good job of making clear the reasons for this
functionality. For the IDE we are developing here at SAS Institute,
one of my assignments is to be the "integrator of the web server".
The majority of people who will use our IDE to develop servlet's and
JSP propabably aren't interested in learning about Tomcat's server.xml.
They just want to be able to test what they develop.
SAS's IDE is not intended to compete on the open market. Its main value
is in the Java library that comes with it. I would hope that the
functionality I'm proposing would help Tomcat achieve a better
integration with other IDE's as well. I think it is a weakness of
Jasper that doesn't make it easy to get debugging information. While
making it easier to get debugging information, we might as well try to
make the other options easier to control too.
Right now, in Tomcat 3.2 I don't see a way to endable debugging info at
all in server.xml, and I really don't want to ask users to make Tomcat specific
changes to their web.xml's to achieve it. Tomcat 3.3 currently
supports enabling it in server.xml, but I would like to bring it
to the same level of functionality that I'm trying to reach in Tomcat
3.2.
As an illustration of the level of functionality I'm trying to reach,
it would be nice if you could have "keepgenerated" and "debugging info"
normally off. If a problem turns up in a JSP page, turn them on
temporarily, fix the JSP page, then turn them off again. I would like
to be able to do that, for contexts I choose to allow it, without
modifying the server.xml or needing to keep multiple server.xml's with
different options in sync.
For these JSP options, would it make sense then, if the JspInterceptor's
constructor read a System property to update the built-in defaults using
a string like I've proposed. The JspInterceptor's server.xml settings could then
override these defaults.
> Using notes is always a solution ( since it doesn't create any
> dependency), but of course if you think this is important to have them
> as
> part of the core we can do that.
>
> On the other side, using properties on JspInterceptor is very easy and
> consistent with the rest of tomcat configuration. Even now you can
> specify
>
> <Interceptor className="JspInterceptor" compiler="jikes" />, etc
>
> You can also set the JspInterceptor per context ( if you want different
> options for different contexts ).
> What do you think ?
Adding properties to the JspInterceptor sounds fine. For some reason,
I was thinking you would specify something like:
<Interceptor className="JspInterceptor" >
<Options className"TomcatOptions" keepGenerated="true" />
</Interceptor>
which would be a little more complicated than I would prefer.
Thanks.
Larry
