tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Gomez <hgo...@apache.org>
Subject Re: [VOTE] Proposed jspc refactoring
Date Thu, 07 Nov 2002 11:43:45 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 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).
> - 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 would say that we're extensively JSPC in ant tasks to generate servlet 
(.java), compile via javac and then put all the classes in a .jar which
will be included in the final .war (in lib) which include the jsp 
mapping generated by JSPC.

With this methodology, we're sure that what we deploy on our production
will works (no jsp compilation error on users browser), no time spent in
compilation at runtime, easy deployement since the WAR alleady included
everything.

So what did you means by classes which should be deployed in work 
directory ?

> - 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).

It's not my opinion, JSP are nothing more than servlet after all and
why prevent users to have then in WEB-INF/classes or WEB-INF/lib ?

Also consider massive web hosting situation with many tomcats running
the same WebApps (with differents settings and JVM owner).

Having everything in a .war (ie data + precompiled jsp in .class or 
.jar) make life easier for web admins since upgrading a version is just
to replace a .war by a new one.

With your proposed solution, they will have update the war, clean the
work directory (by hand ?) and move the new classes in the work 
directory. Also did Manager/Admin will be updated for such task ?

> <ballot>
> +1 [ ] Remove the options
> -1 [ ] Do not remove the options
> </ballot>
> 
> Note: Users may vote, but only committers have binding votes.

So I'm -1 on removing the options



--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message