tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Bergsten <>
Subject Re: [VOTE] Proposed jspc refactoring
Date Thu, 07 Nov 2002 17:32:10 GMT
Remy Maucherat wrote:
> Hi,
> jspc is IMO overly complex, with many features nobody knows how to use, 
> and nobody cares to test (hence sometimes some of them are randomly 
> broken during Jasper refactorings).

I will not formally vote on this, because I've been inactive in this
project for so long I feel I need to familiarize myself with the
current code base before I can exercise my voting priviledges. But I
do have some comments, see below.

> I propose that:
> - In Tomcat 5, all jspc options are removed, in favor of allowing only 
> the webapp mode (with its relevant options). This webapp mode would 
> generate code and classes which should be deployed in the work 
> directory, exactly the same as if they were dynamically compiled by 
> Jasper (which has the big advantage of using only one big operation mode 
> for everything). Single file mode is IMO useless (dynamic compilation 
> works fine).

I agree with you regading single file mode, but not with the rest.

> - In Tomcat 4.1, the options will stay in for compatibility, but the 
> usage help will be modified to be the same as Tomcat 5.

I'm not sure what you mean by this proposal. Are you saying that the
TC 4.1.x version would have a usage message (documentation) that doesn't
match its features? If so, why? If there will be differences between the
TC 4.1.x and TC 5 versions, I assume we will maintain a separate code
base for each version, each with documentation that correctly reflects
their features.

> It has to be noted that:
> - The JSP runtime is now very efficient. The old webapp mode (with its 
> static web.xml) is a hack (and a 100% proprietary one at that).

Efficiency is not all that important here, since precomiplation is
done before deployment (that's the whole idea, right ;-)

Not sure what you mean with "100% proprietary". The web.xml file (or
fragment) that is generated is defined by the servlet spec.

> - Precompilation should only occur at webapp deployment time in the 
> general case (the generated code is closely tied to the Jasper runtime 
> release).

I don't agree. It's very handy to be able to generate a JAR file with
all JSP pages for an application and deploy it to many different
container instances (Tomcat or others, as long as jasper-runtime.jar
is included). There are many users that want to keep the production
environment as simple (and small in embedded systems, for instance) as
possible, and deploying precompiled JSP pages lets me use a production
environment without the JSP compiler and use JRE instead of the JDK.

> - Additional features could be added to the manager servlet to, for 
> example, cause precompilation of the deployed webapp in a separate process.

That's a separate thing, more of a container feature than JSPC in my

> - I am -1 to returning to the old "webapp" option behavior (ie, the 
> generated files should by default be deployed in the work directory, not 
> /WEB-INF/classes).

Why not discuss what the problems with the current options are, and
try to find a solution instead? Like I've said, it's been a while since
I was actively involved with Tomcat development, but I know that in
Tomcat 4.0.4, JSPC seemed to work fine with all options available at
the time. How did Jasper2 break things? If I understand what the main
problem is, I can help find a solution (primarily for Tomcat 4.1.x; I'm
afraid I don't have enough cycles to get into Tomcat 5 at the moment).

Hans Bergsten
Gefion Software
JavaServer Pages

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message