tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Compiling JSP with debug info
Date Sat, 02 Dec 2000 20:32:55 GMT
Louis Tribble wrote:

> "Craig R. McClanahan" wrote:
> >
> > Larry Isaacs wrote:
> >
> > > Hi all,
> > >
> > > We have a need for a global way to have Jasper compile the
> > > JSP servlet source with debug information.  I would propose
> > > defining a system property such as:
> > >
> > >         jasper.compile.debug
> > >
> > > which if set to "true" would turn on the inclusion of debug
> > > info.  Any objections or alternative property names?
> > >
> >
> > Wouldn't you really want this option at the per-web-app level, rather than
> > global?  While we were at it, you'd want similar options for turning
> > optimization on and off, or (more generally) a way to set compiler options for a
> > generic compiler.
> Getting Tomcat to use the right compiler command to work with our
> debugger has been a headache, both in preparing documentation and
> in providing support. And Tomcat 3.1 and 3.2 have some differences
> besides. I would love to see this configurable in server.xml both
> globally and per context, and at a more abstract level than an
> initialization parameter to org.apache.jasper.runtime.JspServlet.
> Ideally, in fact, the configuration value would be the
> compile command string, whose meaning everybody already
> understands, for example: "javac", "jikes", "/usr/java/bin/javac -g",
> or (in our case) "mjavac -g".

Although doing this kind of thing in user terms is nice, it's not quite so easy on the
inside.  Jasper executes the Java compiler inside the same JVM as Tomcat is running
in, rather than executing it externally like you do from the command line.  This makes
compiling go a *lot* faster, but there are some fussy details with getting things like
class paths right, and it's not easy to make this generic.

Ant has the same issues, because it does something similar.  It might be instructive
to look at how they did things.

Beyond the technical details, there is a higher level strategic issue here.  There
have been several requests from people who want to use Jasper as a JSP engine for
their own servlet container.  Right now, there are only a few linkages in the Tomcat
3.2 code (and none in 4.0) between the servlet container and the JSP engine.
Configuring Jasper options from server.xml would unavoidably introduce such
dependencies, and that conflicts with the "independent Jasper" goal.

> [It may be desirable to support a separate compiler type parameter
> (which can usually be inferred from the compile command) to deal
> with differences (e.g. classpath handling) between 1.1 javac,
> 1.2 javac, and jikes.]
> Invoking javac in-process could be viewed as an under the hood
> optimization (if the command is "javac" with no path, invoke
> in-process) but it could be exposed explicitly.
> We're about to release an inexpensive Tomcat edition of our debugger:
> for now, in order to have the same instructions for Tomcat 3.1 and
> 3.2, and given that we don't want to embed Tomcat, I haven't thought
> of anything better than recommending replacing tomcat.bat/sh with a
> slightly modified one that we supply (or editing the java invocations
> by hand if it's been customized).

Note:  Tomcat 4.0 went back to the way 3.1 did global defaults for web applications
through "conf/web.xml".

> Comments?
> Louis Tribble

Craig McClanahan

View raw message