JspC: Switching from Tomcat to Glassfish

21 07 2008

The Ant build script that I use for all of my projects includes, for web-applications, translating and compiling any JSP files. For my purposes this is just to validate the JSPs and report any syntax and compilation errors as part of the build, rather than to put pre-compiled class files into the finished web-app.

I’ve just quickly switched from using Tomcat’s JSP compiler to using Glassfish V2’s JSP compiler, and it seems worth documenting the changes involved and some of the similarities and differences.

Note that I was previously using the Tomcat 5 JSP compiler, and it didn’t seem worth upgrading this to Tomcat 6 just in order to ditch it for Glassfish, so this isn’t a like-for-like comparison – some of the fixes/changes noted might also be present in Tomcat 6.

The actual change-over was relatively painless. It’s basically the same JSP compiler – which I understand is known as “Apache Jasper 2” – so the general nature of it and the options available are essentially the same.

In Tomcat this is provided via a “JspC” Ant task, and needs to be supplied with a classpath that includes the relevant Tomcat libraries. In contrast, Glassfish provides a “jspc” script that supplies the appropriate classpath and invokes Glassfish’s JSP compiler, passing it any supplied command-line arguments.

So switching over basically just consisted of taking out the invocation of the Tomcat-supplied “JspC” Ant task (and the corresponding set-up of its classpath), and replacing it with an Ant “exec” of the Glassfish “jspc” script with equivalent command-line arguments.

However, the Glassfish documentation for this seems a bit on the weak side. At least, I didn’t find it particularly easy to locate any definitive documentation on the command-line options for the Glassfish V2 “jspc” script. Maybe I just didn’t look in the right places. The program itself supports a “-help” option that lists its command-line options, but without much explanation. There’s a more detailed explanation of the options in the Sun Application Server 9.1 Update 2 reference manual at http://docs.sun.com/app/docs/doc/820-4046/jspc-1m, but this doesn’t entirely match the current Glassfish release (e.g. it doesn’t include the recently-added “ignoreJspFragmentErrors” option). Nevertheless, it’s the best documentation I’ve found so far. In any case, the options haven’t yet diverged much from those of Tomcat JspC, so much of the Tomcat documentation remains relevant.

I’m also a bit unsure of the exact relationship between the Tomcat and Glassfish code. They both appear to be “Apache Jasper 2”, but this doesn’t seem to exist as a product in its own right, only as a component within Tomcat. The Glassfish code is presumably a copy or fork of the Tomcat code, but with its own bug-fixes and new features, and maintained and developed as part of Glassfish. With Glassfish being the reference implementation for new JSP versions, I assume the Glassfish implementation is now the main branch going forward, even if some of the changes get incorporated into both.

To add to my uncertainty, I’m also rather confused as to whether Glassfish does or doesn’t also provide an Ant task for invoking its JSP compiler. There is an “asant” script that invokes Glassfish’s internal copy of Ant with a suitable classpath, with various targets and supporting Ant tasks. There’s also documention for previous releases of the “Sun Application Server” that show a “sun-appserv-jspc” Ant task. But the current Glassfish V2 documention doesn’t seem to list any such task amongst its “asant” targets, nor otherwise document a “jspc” or “sun-appserv-jspc” Ant task. Maybe I just didn’t find the right document. I guess I should just hunt around the Glassfish libraries for the relevant class, or try invoking it based on the previous release’s documentation. But for the moment, invoking the “jspc” script is perfectly adequate for my purposes, so I’m sticking with that unless and until I get a chance to look at this again.

A few other findings:

  • When given a complete web-application, the Tomcat 5 JspC compiler seems to process precisely those files that have a “.jsp” or “.jspx” extension. Maybe someone can enlighten me, but I can’t see anything in the Ant task’s attributes that allow it to be configured to process other file extensions. In contrast, Glassfish’s jspc script seems to automatically process all file types that are identified by the web.xml as being JSPs.
  • With the Tomcat JspC task, the JSP translation had to be followed by a separate run of “javac” to compile the resulting java source code. In contrast, the Glassfish jspc script supports a “-compile” option that carries out the compilation as part of its own processing. What’s more, I gather this uses the JSR 199 Java Compiler API for “in process” compilation if this is available (i.e. when running on JDK 6 or higher), and seems much faster as a result.
  • A slight limitation of the Glassfish jspc “-compile” option is that there doesn’t seem to be any control over where the resulting class files are written. Instead, they just get written into the same directory as the java source files. For my purposes this doesn’t matter, but if you wanted to put the class files into a specific location, or deploy them without the source code, you’d have to follow the jspc run with your own moving/copying/filtering of files as necessary.
  • I’m not particularly concerned with the exact performance of this, but subjectively the builds do seem noticeably faster since switching over to the Glassfish JspC and using its “built-in” compile instead of a separate “javac” run.
  • The Glassfish jspc script also supports a “-validate” option, which validates “.tld” and “web.xml” files against their schemas and DTDs. However, I don’t currently use this, and instead use a separate run of Glassfish’s verifier script to verify the finished web-application archive as whole.

I wonder if anyone can clarify the exact relationship between the Tomcat and Glassfish JspC implementations and the underlying “Jasper 2”? Or the exact status (and maybe classname, location, documentation etc) of any Glassfish “jspc” Ant task?



4 responses

21 07 2008
Eduardo Pelegri-Llopart

Hi Mike. The Jasper compiler was led by Sun while at Apache and that continues to be the case at Java.Net. A good place to ask your questions is webtier@glassfish.dev.java.net; I’ll forward a heads-up to them and point to your blog. – eduard/o

21 07 2008

Hi Eduardo. Thanks for the reply, that does explain the history of Jasper.

1 08 2008

I’ve posted a response to this blog at http://forums.java.net/jive/thread.jspa?messageID=291014&#291014

2 08 2008

Thanks. That clears up the situation re Ant script. For info, I do often use the jspc run purely as a validation check, in builds that don’t do an actual “deploy” (e.g. put the .war into auto-deploy directory, or deliver copies of it to other places for archiving). Also to check the JSP before proceeding with other, sometimes lengthy, pre-deployment steps. I can’t speak for anyone else, but those are some of my own reasons for sometimes wanting “manual” JSP translation, separate from actual deployment. (Out-of-container testing of JSP code might be another reason in the near future…).

As for the “-d” option, I do use this already. The issue is that it controls the destination of both the resulting Java source code and the class files produced from them. The (very minor) limitation is that there doesn’t seem any way to generate the source code into one location and the class files into another. I can’t immediately see any real problems from this, it’s just another case of a tool unnecessarily imposing its own decision on where everything is put. Fine until you have multiple such tools with conflicting ideas, or other reasons to organize things differently. Just a little pet hate of mine!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: