{ “passion”: [“software development”,”cloud computing”,”architecture”,”agile”, “leadership”, “machine learning” ]}

A different twist on pre-compiling JSPs

I’ve blogged about this topic earlier and expressed my frustrations as to how web containers don’t provide good support for precompiling JSP, with the exception of WebLogic. As I’ve said before, WebLogic offers great support for pre-compiling JSP by adding a few simple snippets inside the weblogic.xml file.

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN"


As you can see from the snippet of XML above, all you have to do is pass in a parameter called precompile and set it to true. You can set additional attributes like compiler (jikes or javac), package for generated source code and classes, etc. Check out the BEA documentation for more information on the additional parameters.

Now Tomcat or Jetty doesn’t support this type of functionality directly. Tomcat has a great document on how to use Ant and the JavaServer Page compiler, JSPC. The process involves setting up a task in Ant, and then running org.apache.jasper.JspC on the JSP pages to generate all the classes for the JSP pages. Once the JSP’s are compiled, you have to modify the web.xml to include a servlet mapping for each of the compiled servlet. Yuck! I know this works, but it’s just so ugly and such a hack. I like the WebLogic’s declarative way of doing this – Just specify a parameter in an XML file and your JSP’s are compiled at deploy time.

I didn’t want to use the Ant task to precompile as I thought I was just hacking ant to do what I need to do. And if I am going to just hack it, I’m going to create my own hack. :) As I started to think about how to go about doing this, I came across the rarely mentioned ‘Precompilation Protocol’. The ‘Precompilation Protocol’ is part of the JSP 2.0 specification (JSR 152) and it says that any request to a JSP page that has a request parameter with name jsp_precompile is a precompilation request. The jsp_precompile parameter may have no value, or may have values true or false. In all cases, the request should not be delivered to the JSP page. Instead, the intention of the precompilation request is that of a suggestion to the JSP container to precompile the JSP page into its JSP page implementation class. So requests like http://localhost:8080/myapp/index.jsp?jsp_precompile or http://localhost:8080/myapp/index.jsp?jsp_precompile=true or http://localhost:8080/myapp/index.jsp?jsp_precompile=false or http://localhost:8080/myapp/index.jsp?data=xyz&jsp_precompile=true are all valid requests. Anything other than true, false or nothing passed into jsp_precompile will get you an HTTP 500. This is a great feature and gave me an idea on how to precompile my JSP’s.

Taking advantage of Precompilation Protocol, I wrote a simple Servlet that was loaded at startup via a attribute in the web.xml. Once the web application is deployed, this servlet would connect to each of the JSP. I also decided to stuff in the details my servlet is going to need to precompile the JSP’s. Here’s the web.xml that defines my PreCompile servlet and all the other attributes it needs. Instead of using the web.xml, I could have use a property file or a -D parameter from the command line but this was just a proof-of-concept and so I used the web.xml.

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"





The web.xml is pretty simple and just defines the PreCompile servlet. The PreCompile servlet is a simple servlet that takes advantage of the servlet lifecycle and uses the init() method of the servlet to connect to each JSP individually and precompile them. In addition to the init() method, we are also defining that the servlet be loaded at the web application deploy time. Here’s a little snippet from the servlet that show the precompilation of the JSPs.

* Called by the servlet container to indicate to a servlet that
* the servlet is being placed into service.
@param javax.servlet.ServletConfig config
@throws javax.servlet.ServletException ServletException

public void init(ServletConfig config) throws ServletException {

log.info("Starting init() in " + CLASS_NAME);
String server_url = config.getInitParameter(SERVER_PREFIX);
String jsp_delim = config.getInitParameter(JSP_DELIMITER);
String jsps = config.getInitParameter(JSP_FILE_LIST);

if ((jsps != null) && (StringUtils.isNotBlank(jsps))) {
StringTokenizer st =
new StringTokenizer(jsps, jsp_delim);
while (st.hasMoreTokens()) {
String jsp = st.nextToken();
"Starting precompile for " + jsp);
connect(server_url + jsp + JSP_PRECOMPILE_DIRECTIVE);
"Precompiling JSP’s complete");

In digging into the JSP 2.0 specification, I learned that I can also use the sub-element in conjunction with a JSP page. Another interesting approach to solve this pre-compile issue.

Here’s the fully commented servlet (HTML | Java) that does the precompiling. I currently use this as a standalone war that’s deployed after your main application. You can also ‘touch’ the precompile.war file to reload the PreCompile servlet and precompile an application. I whipped this up just to prove a point and don’t really recommend using this in production, even though I am currently doing that. I am going to send feedback to the JSP 2.0 Expert Group and ask them to look into making precompiling a standard and mandatory option that can be described in the web.xml. If you think this is an issue as well, I’d recommend you do the same. Drop me an email or a comment if you think I am on the right track or completely off my rocker.

Comments on this entry are closed.

%d bloggers like this: