On Thu, 7 Nov 2002, Henri Gomez wrote:
> Date: Thu, 07 Nov 2002 12:43:45 +0100 > From: Henri Gomez <[EMAIL PROTECTED]> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]> > To: Tomcat Developers List <[EMAIL PROTECTED]> > Subject: Re: [VOTE] Proposed jspc refactoring > > 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. > An additional advantage for some folks is that you can run the resulting webapp on a JRE instead of a JDK. > 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 > > I'm -1 on removing the options unless they are replaced with equivalent functionality that *does* work correctly and *is* maintained. (Basically, this is J-F's "do not remove and fix" option. Craig -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
