I was recently tasked with installing JavaServer Pages (JSP) on an Apache webserver in order to support some vendor-supplied software. I now find myself trying to figure out just what niche JSP is supposed to be addressing. While I can't be sure, it appears to represent an effort to compete with Microsoft's Active Server Pages (ASP) and products like Allaire's ColdFusion. I've written previously on how this class of products is leading to a "dumbing-down" of application developers, but this software is even more convoluted than most.
A number of products have appeared recently with the goal of simplifying the creation of dynamic web content. The idea is to use various back-end data stores to generate dynamic HTML which is then integrated with static HTML. The programming languages are intended to be relatively simple and hide the complexity of access to a DBMS. Interestingly enough, training for these products is astronomically expensive. Quick sample: ColdFusion Server Enterprise V4.5, course number 10039476 from Software Express will run you $4,555.95. Then again, if you want to pay a junior person $30K a year, pay for the training and expect production-quality code, you will likely get what you deserve.
As with other products in this genre, code is embedded in the source HTML, identified with the appropriate tags. The code is then either interpreted or compiled when users access the page and the appropriate operation is executed. In the case of JSP, the embedded code is Java and is compiled down to a servlet which is then interpreted by the Java Virtual Machine. Am I the only one who sees the irony in this architecture? Since you have to write Java code anyway, why wouldn't you just write the servlet natively and wrap the output in the corresponding HTML?
JSP seems to me to be a case of the tail wagging the dog. You start off writing the HTML code but have to encapsulate Java source code. I would rather have the Java code read the file names for the header and trailer HTML code from the initialization parameters and serve up everything on the fly. Of course, one of the claims made is that you can separate the HTML creation (performed by graphic artists) from the Java code development. That's the way that content creation should be done in any case; I don't claim to be a graphics artist!
Even though JSP was defined by Sun Microsystems, the reference implementation is being written under the auspices of the Jakarta group within Apache. It appears that Sun is defining the specifications but is leaving the job of implementation up to others. This is curious to me since I don't recall any other Java core or extension classes being farmed out to others. If Sun isn't willing to put the effort into implementing JSP themselves, on a wide variety of common web servers, I have to question the commitment they've made to this architecture.
The Jakarta-Tomcat software is a mess, as far as I'm concerned. I don't mean to denigrate the efforts of anyone involved, but even the documentation admits that the software is "not as robust as Apache." (ref: "Tomcat - A Minimalistic User's Guide.") The documentation in general is poor with numerous spelling and grammar mistakes. Even that could be overlooked if there was only an overall architecture document. Too many elements are either poorly addressed or not addressed at all! Trying to glean the processing flow would currently require digging into the source code, totally unacceptable for this kind of software.
Tomcat is completely inconsistent, using properties files in some some cases and XML documents in others. This is what could be called "extraneous use of XML." While XML certainly has some appropriate applications, using it for configuration files is superfluous and irresponsible. Utilization of a new technology in this manner seems gratuitous. Application of appropriate technology should be the key, not merely incorporating a technology because it happens to the the "latest and greatest."
Tomcat uses some of the JServ code (albeit with a different version of the protocol) for the adapter to Apache. If you've already installed JServ, replacing it with the Tomcat code requires downloading and compiling the mod-jserv.so loadable module. I was unable to find coherent documentation for performing this change and one of the steps which was found was just plain wrong! To return to the Sun commitment to JSP, why are there pre-compiled versions available for Linux and Win32 but not for Solaris?
It should also be noted that if you need to compile mod-jserv.so then you'll also have to download Jakarta-Ant; yet another step in a convoluted process. Finally, Tomcat requires JDK 1.2, which means yet another download if you're running version 1.1.7 on a Solaris platform. I be remiss if I didn't add that the pathname configuration is extremely complicated and even the documentation warns against trying to use a traditional (JServ) directory architecture with Tomcat.
By now you've no doubt deduced that the installation and configuration of Jakarta-Tomcat was an exercise in frustration, particularly on the Solaris platform. The documentation is abysmal and the software is fragile and has many prerequisites. Given that the JSP architecture itself is of questionable value, I would strongly dissuade others from pursuing this approach. Even if the Tomcat implementation becomes more stable in the future, the lack of consistency within the package causes me considerable unease.
Copyright (c) 2000 by Phil Selby