Chapter 8. Configuring JSP Support

Chapter 8. Configuring JSP Support
Prev	Part II. Jetty Configuration Guide	Next

Table of Contents

Configuring JSP

Configuring JSP

Compiling JSPs
Configuring JSP for Jetty
Modifying the Configuration
Using JSTL Taglibs
Using JSF Taglibs

This document provides information about configuring JSP.

Compiling JSPs

To compile .jsp files into Java classes, you need a Java compiler. You can acquire a Java compiler from the JVM if you are using a full JDK, or from a third party Jar.

By default, the jsp engine used by Jetty will try to use the compiler that is part of the JDK.

If you do not have a full JDK, then you can configure the jsp engine to use the Eclipse Java Compiler that Jetty ships in the distro in $JETTY_HOME/lib/jsp/org.eclipse.jdt.core-3.7.1.jar. You will need to define a SystemProperty that prevents the jsp engine from defaulting to the in-JVM compiler.

Here's the property definition to add to $JETTY_HOME/start.ini:


 -Dorg.apache.jasper.compiler.disablejsr199=true

Alternatively, you can define this SystemProperty in a $JETTY_HOME/etc/jetty.xml file:


  <Call class="java.lang.System"  name="setProperty">
    <Arg>org.apache.jasper.compiler.disablejsr199</Arg>
    <Arg>true</Arg>
  </Call>

If you are using the Maven Jetty Plugin, then you have a number of options:

define the SystemProperty inside the pom.xml of your webapp using either the Properties Maven Plugin or the Maven Jetty Plugin's own system properties configuration
add a jetty.xml config file and define the SystemProperty in there
add the SystemProperty definition to maven's MAVEN_OPTS environment variable

Configuring JSP for Jetty

The JSP engine has many configuration parameters. Some parameters affect only precompilation, and some affect runtime recompilation checking. Parameters also differ between the various versions of the JSP engine. This page lists the configuration parameters, their meanings and their default settings. All parameters are set on the org.apache.jasper.JspServlet instance defined in the webdefault.xml file.

Note

Be careful: for all of the parameters below, if the value you set doesn't take effect, try using all lower case instead of camel case, as JSP is inconsistent in its parameter naming strategy.

Table 8.1. Understanding JSP Parameters

init param	Description	Default	webdefault.xml
development	`development=true`, recompilation checks occur on each request. See also `modificationTestInterval`.	TRUE	–
fork	Should Ant fork its java compiles of JSP pages?	TRUE	FALSE
keepgenerated	Do you want to keep the generated Java files around?	FALSE	–
saveByteCode	If class files are generated as byte arrays, should they be saved to disk at the end of compilations?	FALSE	–
trimSpaces	Should white spaces between directives or actions be trimmed?	FALSE	–
enablePooling	Determines whether tag handler pooling is enabled.	TRUE	–
mappedFile	Support for mapped Files. Generates a servlet that has a print statement per line of the JSP file./	TRUE	–
sendErrorToClient	If false, stack traces, etc., are sent to std error instead of the client's browser.	FALSE	–
classdebuginfo	Include debugging info in class file.	TRUE	–
checkInterval	Interval in seconds between background recompile checks. Only relevant if `development=false`.	0	–
suppressSmap	Generation of SMAP info for JSR45 debugging.	FALSE	–
dumpSmap	Dump SMAP JSR45 info to a file.	FALSE	–
genStrAsCharArray	Option for generating Strings.	FALSE	–
genStrAsByteArray	Option for generating Strings.	TRUE	–
defaultBufferNone		FALSE	–
errorOnUseBeanInvalidClassAttribute		FALSE	–
scratchDir	Directory where servlets are generated. Jetty sets this value according to the [/display/JETTY/Temporary+Directories work dir] settings for the webapp.	–	–
compiler	Determined at runtime. For Jetty this is the Eclipse jdt compiler.	–	–
compilerTargetVM	Target vm to compile for.	1.5	–
compilerSourceVM	Sets source compliance level for the jdt compiler.	1.5	–
javaEncoding	Pass through the encoding to use for the compilation.	UTF8	–
modificationTestInterval	If `development=true`, interval between recompilation checks, triggered by a request.	0	–
xpoweredBy	Generate an X-Powered-By response header.	FALSE	FALSE
usePrecompiled/use-precompiled		FALSE	–
validating/enableTldValidation	Whether or not to validate tag files against the schema.	FALSE	–
reload-interval	If `reload-interval=0`, then no runtime checking of JSP, otherwise sets the checking interval for both `development=true` and `development=false`.	–	–
initial-capacity/initialCapacity	The initial capacity of the hash maps mapping the name of the JSP to class and JSP file.	–	–

Much confusion generally ensues about the development, checkInterval and modificationTestInterval parameters and JSP runtime recompilation. Here is a factoring out of the various options:

Check the JSP files for possible recompilation on every request:


<init-param>
        <param-name>development></param-name>
        <param-value>true></param-value>
</init-param>

Only check approximately every N seconds, where a request will trigger the time-lapse calculation. This example checks every 60 seconds:


<init-param>
        <param-name>development></param-name>
        <param-value>true></param-value>
</init-param>
<init-param>
        <param-name>modificationTestInterval></param-name>
        <param-value>60></param-value>
</init-param>

Do no checking whatsoever, but still compile the JSP on the very first hit. (Note: this ''reload-interval'' parameter is shorthand for a ''development=false'' and ''checkInterval=0'' combination.):
```
<init-param>
        <param-name>reload-interval></param-name>
        <param-value>-1></param-value>
</init-param>

        
```

Don't do any request-time checking, but instead start a background thread to do checks every N seconds. This example checks every 60 seconds:


<init-param>
        <param-name>development></param-name>
        <param-value>false></param-value>
 </init-param>
 <init-param>
         <param-name>checkInterval></param-name>
         <param-value>60></param-value>
</init-param>

Modifying the Configuration

There are several options for modifying the JspServlet configuration.

Overriding `webdefault.xml`

You can make a copy of the $JETTY_HOME/etc/webdefault.xml that ships with Jetty, apply your changes, and use it instead of the shipped version. The example below shows how to do this when using the Jetty Maven plugin.


  <plugin>
    <groupId>org.eclipse.jetty</groupId>
    <artifactId>jetty-maven-plugin</artifactId>
    <configuration>
      <webApp>
        <defaultsDescriptor>src/main/resources/webdefault.xml</defaultsDescriptor>
      </webApp>
  </plugin>

If you're using the Jetty distro, and you want to change the JSP settings for just one or a few of your webapps, copy the $JETTY_HOME/etc/webdefault.xml file somewhere, modify it, and then use a context xml file to set this file as the defaultsDescriptor for your webapp. Here's a snippet:


 <Configure class=>"org.eclipse.jetty.webapp.WebAppContext">
 
   <Set name=>"contextPath">/foo</Set>
   <Set name=>"war"><SystemProperty name=>"jetty.home" >default=>"."/>/webapps/foobar.war</Set>
   <Set name=>"defaultsDescriptor">/home/smith/dev/webdefault.xml</Set>
  
 </Configure>

If you want to change the JSP settings for all webapps, edit the $JETTY_HOME/etc/webdefaults.xml file directly instead.

Configuring the JSP Servlet in `web.xml`

Another option is to add an entry for the JSPServlet to the WEB-INF/web.xml file of your webapp. You can use the entry in $JETTY_HOME/etc/webdefault.xml as a starting point.


 <servlet id=>"jsp">
     <servlet-name>jsp</servlet-name>
     <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
     <init-param>
         <param-name>logVerbosityLevel</param-name>
         <param-value>DEBUG</param-value>
     </init-param>
     <init-param>
         <param-name>fork</param-name>
         <param-value>>false</param-value>
     </init-param>
     <init-param>
         <param-name>keepgenerated</param-name>
         <param-value>>true</param-value>
     </init-param>
     ...
     
     <load-on-startup>0</load-on-startup>
   </servlet>
 
   <servlet-mapping>
     <servlet-name>jsp</servlet-name>
     <url-pattern>*.jsp</url-pattern>
     <url-pattern>*.jspf</url-pattern>
     <url-pattern>*.jspx</url-pattern>
     <url-pattern>*.xsp</url-pattern>
     <url-pattern>*.JSP</url-pattern>
     <url-pattern>*.JSPF</url-pattern>
     <url-pattern>*.JSPX</url-pattern>
     <url-pattern>*.XSP</url-pattern>
   </servlet-mapping>
   
   <servlet id=>"my-servlet">
     <servlet-name>myServlet</servlet-name>
     <servlet-class>com.acme.servlet.MyServlet</servlet-class>
      ...

Using JSTL Taglibs

The JavaServer Pages Standlard Tag Library (JSTL) is part of the jetty distribution (in $JETTY_HOME/lib/jsp) and is automatically on the classpath.

Using JSF Taglibs

The following sections provide information about using JSF taglibs with Jetty Standalone and the Jetty Maven Plugin.

Using JSF Taglibs with Jetty Distribution

If you want to use JSF with your webapp, you need to copy the jsf implementation Jar (whichever Jar contains the META-INF/*.tld files from your chosen JSF implementation) into $JETTY_HOME/lib/jsp. This is because the version of the jsp engine from Glassfish that we are using requires that the JSF tags are on the container's classpath, and not on the webapp's classpath.

Using JSF Taglibs with Jetty Maven Plugin

The version of the JSP engine from Glassfish that we are using requires that the JSF tags be on the container classpath, and not on the webapp classpath, so you need to make your JSF jars dependencies of the plugin and not the webapp itself. For example:


   <plugin>
    <groupId>org.eclipse.jetty</groupId>
    <artifactId>jetty-maven-plugin</artifactId>
    <configuration>
       <webApp>
         <contextPath>/jetty-documentation</contextPath>
       </webApp>
       <scanIntervalSeconds>5</scanIntervalSeconds>
    </configuration>
    <dependencies>
      <dependency>
        <groupId>com.sun.faces</groupId>
        <artifactId>jsf-api</artifactId>
        <version>2.0.8</version>
      </dependency>
      <dependency>
        <groupId>com.sun.faces</groupId>
        <artifactId>jsf-impl</artifactId>
        <version>2.0.8</version>
     </dependency>
    </dependencies>
  </plugin>

Prev	Up	Next
Deployment Architecture	Home	Chapter 9. Jetty Logging

Contact the core Jetty developers at www.webtide.com

DRAFT