Introduction

This chapter covers two means of working with JSPs that fall slightly outside the norm. The first method precompiles JSPs and turns them into servlet source code. The second develops JSPs as XML documents.

Precompiling JSPs

Precompiling a JSP involves using a server-provided command-line tool to convert the JSP page into a servlet class file. A JSP is converted into a servlet, often called a JavaServer Page implementation class , before it handles any HTTP requests . The JSP specification refers to the stage by which the JSP container converts JSP page syntax into a servlet as the translation phase . In Tomcat, if you want to examine what the JSP page implementation class looks like after this conversion, go to this directory:

   Tomcat-install-directory   /work/Standalone/   name-of-host   /   name-of-web-app   

name-of-host could be localhost , or any other hostname that refers to the server Tomcat is installed on. The name of the web application is also the name of the context; this is usually something like examples , ROOT , or storefront .

The indicated directory contains .java files, such as default_jsp.java . These are the Java source files that are compiled into class files, and then executed as servlets to respond to requests.

The reasons why a JSP developer may want to precompile a JSP page include:

1. Avoiding the perceptible delay caused when a JSP is first requested from the web container, during which the JSP compiler converts the JSP's source code into a servlet.

2. Allowing the developer to examine the Java source code for the JSP page implementation class, and optionally work on the code with their servlet IDE's sourcecode editor.

In both Tomcat and WebLogic, a command-line tool can be used to precompile a JSP. Recipe 5.4 covers the mapping in web.xml of a JSP page to its servlet implementation class.

JSPs as XML Documents

The later recipes in this chapter describe creating JSPs as XML files. Both the JSP specifications v1.2 and 2.0 describe the generation and use of JSPs as pure XML documents. This means that rather than create JSPs in typical JSP page syntax, they are instead coded as well- formed XML documents. According to the JSP specification, a JSP document is a namespace-aware XML document. The JSP container differentiates JSP documents from traditional JSP pages in at least one of three ways.

1. A jsp-property- group element in web.xml specifies a JSP document with the is-xml child element. (The jsp-property-group element is one of the JSP configuration elements that the JSP 2.0 specification has proposed adding to web.xml .)

2. The file has a .jspx extension.

3. The JSP page has a root element of jsp:root .

Recipe 5.5 shows what these files look like.

The JSP specification describes an XML view as a description of a JSP page in XML form. An XML view is generated by the JSP container during the translation phase. A subclass of javax.servlet.jsp. tagext .TagLibraryValidator can use the XML view to parse a JSP in order to validate that custom tags have been used correctly, before the container finally converts the JSP into its page implementation class (a servlet). Recipe 5.6 shows how to generate XML views for a JSP, and how to save the resulting XML files.

JSPs can be created as XML files for the following reasons, among others:

• Web containers can accept JSP documents in web applications, meaning that the web application can contain XML files instead of the pages in traditional JSP syntax. JSP documents can thus be integrated with other XML content, such as XHTML files, Scalable Vector Graphics (SVG), and the XML files that are part of web services transactions.

• You can use XML editors to work with JSP documents.

• You can use other XML technologies with JSP documents, such as XSLT, Simple Object Access Protocol (SOAP), SAX, and DOM.