There are a number of compelling reasons that pre-compiling JSPs are a good idea. Among the short list are:
(+) Safety: If you precompile a JSP, you *know* before putting it in production that it will compile without problems. Why do we compile .java files into .class files before releasing a product? Because we want to make as sure as we can that the application will run as intended.
(+) Source Code Privacy: Likewise, would your company release non-compiled source code for others to see? Why would you release uncompiled jsp source code for the world to see?
(+) Speed: The first time a jsp is accessed, it must be compiled. Obviously, this delay degrades the user experience.
(+) Security: Setting up your JVM to allow both execute and write access is a potential security hole.
(+) Resource Usage: There is inherent overhead caused by the process of translating a jsp request to a servlet request (which all jsp requests become). To see this, look at a stack trace for a request that came through a JSP, then compare that to one from a Servlet. If you can avoid the overhead, why not?
(+) Pre-compiling is a Deployment-time activity: Pre compiling doesn't affect developers -- it happens only at deployment time. Unless you change JSPs frequently (which won't happen is a best-practice production environment), there is no penalty to be paid by pre-compiling.
If you care about these issues, pre-compile your JSPs. If you don't care, don't spend the 30 minutes it takes to figure it out. :)
justin
At 06:38 PM 6/24/2004, you wrote:
Hi, Yes..that is what I thought, but I learned from a 'reliable' source I could accomplish this on saving overhead. So rather than looking into the whys and whats, I looked into how to do it, and look into the performance benefits later. I will provide the list with my sources reasoning, when it becomes available! A thought..and to answer a question with a question (Why would you precompile jsp files?), why is jspc there? If only to increase performance on the first hit?
Thanks
Paul.
It will increase speed on the first viewing of the jsp, but after that I
can't see how there will be any difference. How much memory can you save if any? And how would that work?
Thanks
On Fri, 25 Jun 2004 11:12:44 +1000, Paul Wallace <[EMAIL PROTECTED]> wrote:
> In an effort to increase speed/free up memory that otherwise might be > consumed by Tomcat otherwise > > Why would you precompile jsp files? > > On Fri, 25 Jun 2004 09:32:38 +1000, Paul Wallace <[EMAIL PROTECTED]> > wrote: > >> (sorry, wrong key!) >> >> Hi Jason, >> Thanks for that. Yes, it does make sense. A couple of things >> though, I just ran it with -compile - great. But my query about the > work >> directory and was more towards what I am being 'encouraged' to do from >> the powers that be. I.e not WAR the app., but put it in the work >> directory. Is this ill-advised/poor practice? >> To accomplish this, is it as simple as dragging the compiled >> source under my work directory, and modifying my web.xml as advised? >> Why does -compile work, but not appear in the usage?! >> Also, can I specify a path for the compilation, rather than the >> classes be placed in the same dirs as the source? (I tried adding a > path >> after the -compile switch, but it constructed and compiled a file with >> the same name as the class directory destination). >> >> Do I make sense?! >> >> Paul. >> >> Paul, >> >> I just use the -compile option and have jspc do the >> compilation from .java to .class for me. It seems to >> work fairly well. Once all the fully compiled (ie >> .class) files are placed in you applications >> WEB-INF/classes directory you just need to place the >> generated web.xml file in WEB-INF. There is an option >> to create a complete web.xml file that you can place >> in WEB-INF or, if you already have a web.xml file you >> want to keep, you can have jspc create an xml fragment >> that just contains the servlet definitions and >> mappings that you then add (in the appropriate place) >> to your existing web.xml. Then just war up you >> application directory in the normal way (you can even >> delete the jsps once your certain the servlet mappings >> are working). >> If you try to put the generated files in your >> working directory you won't be able to war them up and >> deploy them in the normal "put war file under webapps >> directory and tomcat will expand it when it starts" >> way. You'd have to ship a complete tomcat directory >> structure with the work directory already filled in >> with your compiled jsps. Does that make sense? >> >> Jason >> >> --- Paul Wallace <[EMAIL PROTECTED]> wrote: >>> Hello, >>> I have compiled my JSPs thus: >>> >>> jspc -webapp C:\src\site -d C:\src\site\classes -s >>> -l -uriroot >>> C:\src\site >>> >>> this builds the Java source files to the specified >>> location, but how >>> might I deploy them? >>> >>> What is a typical deployment after a JSP >>> compilation? Compilation of >>> Java source files, then WAR/JAR? Can I not define >>> the JSP compile to go >>> under my work directory? >>> >>> The purpose of my efforts is to try and speed up / >>> make TC less memory >>> consumptive. >>> >>> cheers >>> >>> Paul. >>> >>> >>> >> >> >> >> >> __________________________________ >> Do you Yahoo!? >> Yahoo! Mail Address AutoComplete - You start. We finish. >> http://promotions.yahoo.com/new_mail >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > >
-- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin (1755)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
______________________________________________ Justin Ruthenbeck Software Engineer, NextEngine Inc. justinr - AT - nextengine DOT com Confidential. See: http://www.nextengine.com/confidentiality.php ______________________________________________
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
