RE: [VOTE] Proposed jspc refactoring (how I use jspc)

[Sean Reilly <sr...@point2.com>]

For what it's worth, here's how I benefit from jspc on a regular basis.

I'm one of the principal developers of a fairly high-traffic site powered by tomcat 4.1.12.
We use jspc for correctness checking as part of our compile cycle, for two reasons:

a)To enforce valid jsp tag use (required attributes present, etc)
b)We use a jstl validator to keep over-enthusiastic web developers from using scriptlets in jsp pages

Including jsp checking in the compile cycle (and inflicting bodily harm on developers who cvs commit without compiling ;-) is a big help in keeping code quality high.

It's been mentionied in this thread (I think by Remy), that
"Efficiency is not all that important here, since precomiplation is done before deployment"
I would respectfully disagree on this point.

Not including jsp compilation, our entire build cycle, from a stock tomcat zip to a running tomcat instance with deployed webapps (including all servlet compilation and source code style checking) takes about 35 seconds.
Using ant's incremental capabilities, a non-complete build often takes less than 10 seconds.  I love that our developers can compile at the drop of a hat, and I encourage this as often as I can.

So to me, efficiency is very important; the faster, the better.  Right now, a jsp precompilation for 120 jsp pages (which we can put off until production deployment to organizational peculiarities) takes 54 seconds... longer than the rest of our build cycle put together.  I would love for jsp compile checking to be performed as part of a regular developer's build cycle, and the faster JspC gets, the easier that is.  Also, we do use incremental jsp compiles on a regular basis.

Also, I would love to deploy precompiled jsps to production, but conformance to the jsp and servlet specs is important to us, so a servlet compliant way (as opposed to the "copying to the work directory" solution) would be a positive feature for us.

So to sum up, we jspc an entire webapp at a time, but love incremental compilation (which is the only reason I can think of that someone would need to only compile a single jsp), and the faster the process is, the better.

Thanks,
Sean

PS:  Also, if you're looking for an example of the kind of performance you can get from a tomcat-powered server (as many people in the user's list seem to be), we're probably a pretty good example.  We served 52,708 page views yesterday (of definitely non-static content) from two dual p3 800mhz boxes, and when cpu usage goes over 5% on either machine, we get seriously upset.

http://usediron.point2.com

Sean Reilly
Programmer, Point2 Technologies, Inc.
(306) 955-1855
sreilly@point2.com



-----Original Message-----
From: John Trollinger [mailto:jakarta@trollingers.com]
Sent: Thursday, November 07, 2002 1:24 PM
To: 'Tomcat Developers List'
Subject: RE: [VOTE] Proposed jspc refactoring


I have to time to go through and fix all the options (including cleaning
up the code) but I would like to see what options are actually used (or
would like to be used if they work)

I also have no problems maintaining jscp as I use it a lot and have
customized it to do what I want.  

I would just like some direction to go with..

John

> -----Original Message-----
> From: news [mailto:news@main.gmane.org] On Behalf Of Costin Manolache
> Sent: Thursday, November 07, 2002 1:39 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: [VOTE] Proposed jspc refactoring
> 
> 
> Remy has a point - the current code is not very clean, and 
> doesn't seem to be tested/maintained enough.
> 
> I use the ant tasks - and I have a feeling many other users 
> of jspc are doing the same. 
> 
> Removing the CLI and keeping the basic functionality seems like 
> a good idea.
> 
> For example compiling a jsp page outside a webapp can't work
> in all cases - if it has includes, etc it needs to resolve, it 
> needs taglib definitions from WEB-INF, etc. I can't see any 
> good reason to keep it if it's half broken by definition.
> 
> Also - compiling the java files is the job of <javac>, 
> and the mapping and web.xml fragment generation can be 
> more easily done using only the ant tasks.
> 
> I would go even further - since we are already using ant to 
> compile the java to .class, it may be a good idea to make the 
> .jsp->.java task 'first class'.
> 
> In any case - the task is supported ( at least by me, it 
> seems Henri is 
> using it as well ).
> If there are people who want to support the CLI and the other 
> options - then we can keep them, but if not - I think it's 
> better to remove them or mark as unsupported.
> 
> Costin 
> 
> 
> 
> Hans Bergsten wrote:
> 
> > 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 
> > mind.
> > 
> >> - 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
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>