Never mind -- solved this by leaving the JSP & java files in the build directory after processing them in chunks with the forked java processes, and then calling JSPC one more time using the taskdef. Previously completed steps are not repeated, so essentially, the taskdef invocation just sees that all of the .JSP & .java files are up to date and merely generates and merges the servlet mappings into web.xml.
-----Original Message----- From: Karen Koch [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 5:11 PM To: users@tomcat.apache.org Subject: JspC precompilation dilemma I am using JspC to precompile a large number of JSPs (1000ish). I want to take advantage of the servlet-mapping generation/merge into web.xml that is available using the <taskdef classname="org.apache.jasper.JspC" name="jasper2"> syntax; however, I have been unsuccessful in my efforts to fork a new JVM (since there is apparently no exposed command-line argument for this). I consistently run out of memory using this method, despite ample available memory and Jvm tunings. I have solved the out of memory errors by instead using a straight <java> call, which allows me to fork a new JVM. I break up the overall number of JSPs into smaller batches, and as each batch is completed, memory is appropriately reclaimed. However, though I still can generate the servlet-mappings I need for the web.xml, I am not aware of a way to automatically merge the result into the webapp's web.xml file. Have others found a way to have your cake (fork a new JVM for JSP precompilation) and eat it too (automatically merge the generated servlet mappings into the webapp's web.xml)? Thanks in advance for any advice. Karen Koch --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
