Table of Contents
This document provides information about configuring JSP.
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 uses the Eclipse Java Compiler (
ecj.jar
) which is supplied in $JETTY_HOME/lib/jsp
. For jetty-7.5.0 and later 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, so you must use a full JDK. Alternatively, you can
precompile your JSPs (which is preferable in a production deployment in any case). The
[[Jetty/Feature/Jetty_Jspc_Maven_Plugin|Jetty JSPC Maven Plugin]] TODO xref// is helpful for precompilation.
If you are using jetty-7.5.5 or later (including jetty-8.x), you can use either a full
JDK or a JRE in combination with a third party Java compiler (such as ecj which we distribute
in $JETTY_HOME/lib/jsp
). To use the ecj compiler, you need to set a
SystemProperty
. You can do this 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>
Alternatively, you can put this SystemProperty
into start.ini
:
-Dorg.apache.jasper.compiler.disablejsr199=true
For jetty-7.5.0 and later 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, so you must use a
full JDK.
We hope to be able to introduce a patch to allow the use of third party Jars in an upcoming release of the plugin. We will update this page when we have more information.
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:
.java
files are left after compilation only if a compilation
error occurs.Table 6.1. Understanding JSP 2.1 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:
<init-param> <param-name>development></param-name> <param-value>true></param-value> </init-param>
<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>
<init-param> <param-name>reload-interval></param-name> <param-value>-1></param-value> </init-param>
<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>
There are several options for modifying the Jasper JSP servlet configuration.
You can make a copy of the [[Jetty/Reference/webdefault.xml|webdefault.xml]] //TODO xref//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.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, copy the $JETTY_HOME/etc/webdefault.xml
file somewhere, modify it, and then use a
[[Jetty/Feature/ContextDeployer|context xml]] //TODO xref// 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, edit the
$JETTY_HOME/etc/webdefaults.xml
file directly instead.
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 [[Jetty/Reference/webdefault.xml|webdefault.xml]]//TODO xref// 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> ...
There are some differences in how you use JSTL taglibs in Jetty 7 and Jetty 8.
The JSTL tags are present in the org.apache.taglibs.standard.glassfish
Jar in
$JETTY_HOME/lib/jsp
. For the Jetty/JSP integration to find them, you need to configure a pattern that
defines the names of files in the container's classpath that contain .tld
files. You must
define the pattern as a context attribute on each context that you deploy. 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 (that is, your start.ini
file contains
etc/jetty-deploy.xml
), you don't need to do anything, as the pattern is pre-defined in
etc/jetty-deploy.xml
, and the deployer makes sure the attribute is set on each and every context it
deploys. If you are NOT using the deployers, you need to configure the attribute on
each context you set. Here's an example:
<New class="org.eclipse.jetty.webapp.WebAppContext"> <Arg><Ref id="Contexts"/></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>
org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern
for more
than identifying Jars that contain tlds. Its purpose is to supply a pattern of names of Jars on the container's
classpath whose /META-INF directories should be scanned for resources, for fragments, or for TLDs.The version of JSP 2.2 engine that Jetty uses employs a Servlet 3.0 way of finding TLDs (
ServletContainerInitializer), and thus does not require that you define
org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern
.
The following sections provide information about using JSF taglibs with Jetty Standalone and the Jetty Maven Plugin.
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.
If you are using Jetty 7.x, add the JSF implementation Jar to the set of container Jars that are scanned
for TLDs. The set of Jars is specified as a Java Pattern as the value of the ContextAttribute
org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern
. You must add a pattern that matches the name
of the implementation Jar.
You can set this ContextAttribute
on just a particular webapp, or for all webapps.
To set it on just one webapp, create or edit a [[Jetty/Feature/ContextDeployer|context xml]] //TODO xref//
file that describes your webapp. For example, assuming the implementation Jar is called
javax.faces-2.1.6.jar
:
<Configure class="org.eclipse.jetty.webapp.WebAppContext"> <Call name="setAttribute"> <Arg>org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern</Arg> <Arg>.*/.*javax.faces-[^/]*\.jar$|.*/.*jsp-api-[^/]*\.jar$|.*/.*jsp-[^/]*\.jar$|.*/.*taglibs[^/]*\.jar$</Arg> </Call> </Configure>
If you're deploying via code, the equivalent is to call the
WebAppContext.setAttribute(String name, String value)
method.
If you want to use JSF with all of your webapps, Using the Deployment Manager, edit
$JETTY_HOME/etc/jetty-deploy.xml
. For example, assuming the implementation Jar is named
javax.faces-2.1.6.jar
:
<New id="DeploymentManager" class="org.eclipse.jetty.deploy.DeploymentManager"> <Set name="contexts"> <Ref id="Contexts" /> </Set> <Call name="setContextAttribute"> <Arg>org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern</Arg> <Arg>.*/.*javax.faces-[^/]*\.jar$|.*/.*jsp-api-[^/]*\.jar$|.*/.*jsp-[^/]*\.jar$|.*/.*taglibs[^/]*\.jar$</Arg> </Call>
If you are using Jetty 8.x you do not need to add this pattern because Servlet Spec. 3.0 uses a different method to find TLD descriptors.
For Jetty versions prior to 7.5.0, your JSF Jars should be normal webapp dependencies. You do not need to do anything else to use Jetty with JSF.
From versions 7.5.0 and later, 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.mortbay.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <configuration> <webAppConfig> <contextPath>/jetty-documentation</contextPath> </webAppConfig> <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>
For versions 7.5.0 to 7.6.1, the Jetty Maven plugin does not scan the JSF dependency Jars for the TLDs
containing the startup listeners. If you are using these versions, we recommend you upgrade to a more recent
version. If this is not possible, you should define the relevant listener in your
web.xml
:
For MyFaces:
<listener> <listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class> </listener>
For Mojarra:
<listener> <listener-class>com.sun.faces.config.ConfigureListener</listener-class> </listener>
For version 7.6.2 and later, the Jetty Maven plugin ensures that the TLDs containing the startup listeners from the two most common JSF implementations (Mojarra and MyFaces) are automatically detected.