Difference between revisions of "Jetty/Howto/Configure JSP"

Revision as of 12:53, 18 October 2011

Introduction

This page 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.

In versions of Jetty prior to 7.5.0, the JSP infrastructure made use of the Eclipse Java Compiler (ecj.jar) which is supplied in $JETTY_HOME/lib/jsp. For jetty-7.5.0 we upgraded the version of JSP to jsp-impl-2.1.3.b10 (from Glassfish). In this version, the JSP infrastructure ALWAYS tries to acquire a Java compiler from the JVM if the version of Java is 1.6 or above. Therefore, if you are using a JRE, JSPs are unable to compile. We are waiting on the JSP project to back port a bug fix from jsp-2.2 that will allow us to force the JSP infrastructure to look beyond the JVM for a compiler. In the meanwhile, we have patched the JSP code and are waiting on Eclipse Orbit to make a release with those patched Jars. When the Jars have been patched, we will make a Jetty release containing them. In the interim, if using jetty-7.5.x, you must use a full JDK. Alternatively, you can precompile your JSPs (which is preferable in a production deployment in any case). The Jetty JSPC Maven Plugin is helpful for precompilation.

Note that for jetty-8.x.x, you can use either a full JDK or a JRE in combination with a third party Java compiler (such as ecj). In the latter case, you need to set a SystemProperty, either in your code or in a jetty config file. Here's the snippet that you can put into jetty.xml:

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

Configuring JSP

The JSP engine has many configuration parameters. Some parameters affect only precompilation, and some affect runtime recompilation checking. Parameters also differ between the 2.0 and 2.1 release of the JSP engine. This page lists the configuration parameters, their meanings and their default settings.

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.
• Be aware that for JDK1.6, the default for keepgenerated is false, therefore .java files will only be left after compilation if a compilation error occurs.

Understanding JSP 2.1 Parameters

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

1. Check the JSP files for possible recompilation on every request:

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

2. 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>

3. 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>

4. 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 Jasper JSP servlet configuration.

Overriding webdefault.xml

You can make a copy of the webdefault.xml shipped 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.mortbay.jetty</groupId>
    <artifactId>jetty-maven-plugin</artifactId>
    <configuration>
    <webAppConfig>
      <defaultsDescriptor>src/main/resources/webdefault.xml</defaultsDescriptor>
    </webAppConfig>
    <connectors>
    ..

If you're using Jetty standalone, and you want to change the JSP settings for just one or a few of your webapps, then copy the $JETTY_HOME/etc/webdefault.xml file somewhere, modify it, and then use a context xml file to set this file as the webdefaults 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 of the webapps, then 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 Jasper JSP servlet to the web.xml file of your webapp. You can use the entry in 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

For Jetty-7.x: The JSTL tags are present in the org.apache.taglibs.standard.glassfish jar in $JETTY_HOME/lib/jsp. In order for them to be found by the Jetty/jsp integration, you need to configure a pattern that defines the names of files in the container's classpath that contain .tld files.

The pattern must be defined as a context attribute on each context that is deployed. The context attribute and pattern is:

 attribute: org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern
 value: .*/.*jsp-api-[^/]*\.jar$|.*/.*jsp-[^/]*\.jar$|.*/.*taglibs[^/]*\.jar$

If you are using the jetty deployers (ie your start.ini file contains etc/jetty-deploy.xml) then you don't need to do anything, as the pattern is pre-defined in etc/jetty-deploy.xml and the deployer will make sure the attribute is set on each and every context it deploys.

If you're NOT using the deployers, then you will need to configure the attribute on *each* context you configure. Here's an example:

<New class="org.eclipse.jetty.webapp.WebAppContext">

 <Arg>Cite error: Invalid <ref> tag;

invalid names, e.g. too many</Arg>

 <Arg><SystemProperty name="jetty.home" default="."/>/webapps/test.war</Arg>
 <Arg>/test</Arg>
  <Call name="setAttribute">
           <Arg>org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern</Arg>
           <Arg>.*/.*jsp-api-[^/]*\.jar$|.*/.*jsp-[^/]*\.jar$|.*/.*taglibs[^/]*\.jar$</Arg>
  </Call>

</New>

NOTE: the org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern can be used for more than identifying jars that contain tlds. Basically, its purpose is to supply a pattern of names of jars on the container's classpath whose /META-INF directories should be scanned - eg for resources, for fragments or for tlds.

For Jetty-8.x: The version of jsp 2.2 engine that is being used employs a Servlet 3.0 way of finding tlds (see ServletContainerInitializer, http://download.oracle.com/javaee/6/api/javax/servlet/ServletContainerInitializer.html) , and thus does *not* require the org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern to be defined.

JSF Taglibs

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