>
> The only feedback on the more specific proposal was from Costin
> relating to Tomcat 3.3. I'm not sure if I should interpret this
> as an overall -1 for committing any of these changes to Tomcat
It's a +1 - the feedback tries to help you with a different perspective
and a different idea. I don't mind if you just ignore it - I think it's
important for people to give feedback, and some of it may be good or bad,
you write the code and you decide.
> +1: (Implement 1,2 & 3 below) Upgrade Jasper to allow a web.xml
> servlet init parameter to enable compiling with debug info.
> Gives Jasper at least the ability to compile with debug
> information.
+1
> +2: (Implement 4 & 5 below) Add a "default JSP options" context
> attribute which in the absence of a servlet init parameter,
> could alter the built-in defaults for any boolean JSP options.
> This would allow a servlet to alter the defaults.
+1
> +3: (Implement 7, and part of 6 below) Add Context property that
> sets "default JSP options". This allows the defaults
> to be set for each individual context in server.xml.
+1
> +4: (Implement more of 6 below) Add ContextManager property that
> sets "default JSP options". This allows the defaults for
> all contexts to be set in server.xml where not overridden
> by context specific defaults.
+1
> +5: (Implement the rest of 6 below) Add a System property to
> supply "default JSP options". This allows the defaults to
> be set for all contexts outside of server.xml where not
> overridden by ContextManager or Context. Yes, this is clear
> overkill, but it helps a little in my situation. :-)
+1 ( I would rather like to not have System.properties in the core, it
would be great if you can implement this in a separate interceptor ).
BTW, another piece of feedback - would it be possible to implement part
of this as an interceptor ?
Something like <interceptor className="...JspDebug" debug="true" /> ?
The interceptor can be set per/context or global, and could set a normal
context attribute. That would mean no change is required in
core ( Context, ContextManager ). For the web.xml changes - you can use a
context attribute too. The current mechansim AFAIK is to map jsps to a
jsp servlet that is JspServlet, and set init properties - instead we can
define a context attribute ( context-param ), that would be ignored in
non-jasper containers.
If you choose to do that ( a context-param like "tomcat.jsp.debug") you'll
just have to change jasper to use it, and the JspDebug Interceptor could
just set the context param ( based on its properties and the system
properties, overriding web.xml ). A more generic solution would be to
define a "ContextParam" interceptor that will set a context property -
this way you can add context-param in server.xml too.
It's just a sugestion - one possible way to implement it with minimal
effort and fewer changes.
Costin
