tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cmanola...@yahoo.com
Subject Re: [VOTE] Compiling JSP's with debugging info
Date Mon, 11 Dec 2000 20:57:05 GMT
> 
> 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 


 





Mime
View raw message