> For Tomcat 3.3 > > In Tomcat 3.3, I could apply the jasper changes for compatibility. However, > JSP compilation occurs differently. Instead of using a JSP servlet, it > uses an interceptor that calls Jasper with its own options and then > calls the compiler itself. Thus, any options string would have to specify > "the" options instead of "default" options. I think there would be > a benefit to implementing a jspOptions property on Context and > ContextManager, as well as a "tomcat.jsp.options" System property that > override JspInterceptor options. In addition to providing JSP options > at the context level, it makes it easier to change. You don't have > to be familiar with the TomcatOptions class and its properties. :-) 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. 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 ? Costin
