Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

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

< Jetty‎ | Howto
 
(20 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
{{Jetty Howto
 
{{Jetty Howto
 
| introduction =
 
| introduction =
 +
 +
{{Jetty Redirect|http://www.eclipse.org/jetty/documentation/current/configuring-jsp.html}}
  
 
This page provides information about configuring JSP.
 
This page provides information about configuring JSP.
Line 6: Line 8:
 
==Compiling JSPs==
 
==Compiling JSPs==
  
In order to compile .jsp files into java classes, a java compiler is required. A java compiler can either be acquired from the jvm (if using a full JDK) or from a 3rd party jar.  
+
To compile <tt>.jsp</tt> 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 <tt>jsp-impl-2.1.3.b10</tt> (from Glassfish). In this version, the JSP infrastructure will ALWAYS try and 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 will not be able to be compiled. 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 will need to use a full JDK. Or alternatively, you can precompile your jsps (which is preferable in a production deployment in any case). You may find the jetty jspc maven plugin helpful for precompilation.
+
In versions of Jetty prior to 7.5.0, the JSP infrastructure made use of the Eclipse Java Compiler (<tt>ecj.jar</tt>) which is supplied in <tt>$JETTY_HOME/lib/jsp</tt>. For jetty-7.5.0 we upgraded the version of JSP to <tt>jsp-impl-2.1.3.b10</tt> (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]] 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 3rd party java compiler (such as ecj). In the latter case, you will 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:
+
If using jetty-7.5.5 and beyond (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 <tt>jetty.xml</tt>:
  
 
<source lang="xml">
 
<source lang="xml">
    <Call class="java.lang.System"  name="setProperty">
+
  <Call class="java.lang.System"  name="setProperty">
      <Arg>org.apache.jasper.compiler.disablejsr199</Arg>
+
    <Arg>org.apache.jasper.compiler.disablejsr199</Arg>
      <Arg>true</Arg>
+
    <Arg>true</Arg>
    </Call>
+
  </Call>
 
</source>
 
</source>
 +
 +
Or alternatively, you can put this System property into <tt>start.ini</tt>:
 +
 +
<source lang="text">
 +
-Dorg.apache.jasper.compiler.disablejsr199=true
 +
</source>
 +
 +
=== Jetty Maven Plugin ===
 +
 +
Since jetty-7.5.0 we upgraded the version of JSP to <tt>jsp-impl-2.1.3.b10</tt> (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 3rd party jars in an upcoming release of the plugin. This page will be updated when we have more information.
 +
  
 
==Configuring JSP==
 
==Configuring JSP==
Line 26: Line 41:
  
 
* 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.
 
* 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.}}
+
* Be aware that for JDK1.6, the default for ''keepgenerated'' is ''false'', therefore <tt>.java</tt> files will only be left after compilation if a compilation error occurs.}}
 
}}
 
}}
  
Line 41: Line 56:
 
|-
 
|-
 
| development
 
| development
| If <tt>development=true</tt>, recompilation checks are made on each request. See also <tt>modificationTestInterval</tt>.
+
| If <tt>development=true</tt>, recompilation checks occur on each request. See also <tt>modificationTestInterval</tt>.
 
| TRUE
 
| TRUE
 
| -
 
| -
Line 127: Line 142:
 
|-
 
|-
 
| compiler
 
| compiler
| Determined at runtime. For Jetty this is the eclipse jdt compiler.
+
| Determined at runtime. For Jetty this is the Eclipse jdt compiler.
 
|-
 
|-
 
| compilerTargetVM
 
| compilerTargetVM
Line 172: Line 187:
 
| The initial capacity of the hash maps mapping the name of the JSP to class and JSP file.
 
| The initial capacity of the hash maps mapping the name of the JSP to class and JSP file.
 
|
 
|
 +
|
 +
|-
 +
| httpMethods
 +
| List of names of http methods which the JSP servlet will service (there is no requirement that these names are restricted to the set defined by rfc2616). Null or a value of "*" means any and all methods. Names should be comma, tab or newline delimited.
 +
| Null
 
|
 
|
 
|}
 
|}
Line 181: Line 201:
 
<li>Check the JSP files for possible recompilation on every request:  
 
<li>Check the JSP files for possible recompilation on every request:  
  
<source lang="java">
+
<source lang="xml">
 
<init-param>
 
<init-param>
 
         <param-name>development></param-name>
 
         <param-name>development></param-name>
Line 188: Line 208:
 
</source>
 
</source>
 
<li>Only check approximately every N seconds, where a request will trigger the time-lapse calculation. This example checks every 60 seconds:
 
<li>Only check approximately every N seconds, where a request will trigger the time-lapse calculation. This example checks every 60 seconds:
<source lang="java">
+
<source lang="xml">
 
<init-param>
 
<init-param>
 
         <param-name>development></param-name>
 
         <param-name>development></param-name>
Line 198: Line 218:
 
</init-param>
 
</init-param>
 
</source>
 
</source>
<li>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):   
+
<li>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.):   
<source lang="java">
+
<source lang="xml">
 
<init-param>
 
<init-param>
 
         <param-name>reload-interval></param-name>
 
         <param-name>reload-interval></param-name>
Line 205: Line 225:
 
</init-param>
 
</init-param>
 
</source>
 
</source>
<li>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):   
+
<li>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:   
<source lang="java">
+
<source lang="xml">
 
<init-param>
 
<init-param>
 
         <param-name>development></param-name>
 
         <param-name>development></param-name>
Line 216: Line 236:
 
</init-param>
 
</init-param>
 
  </source>
 
  </source>
</ol>
 
  
  
Line 223: Line 242:
 
There are several options for modifying the Jasper JSP servlet configuration.  
 
There are several options for modifying the Jasper JSP servlet configuration.  
  
===Overriding webdefault.xml===
+
=== Overriding <tt>webdefault.xml</tt> ===
  
 
You can make a copy of the [[Jetty/Reference/webdefault.xml|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.
 
You can make a copy of the [[Jetty/Reference/webdefault.xml|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.
Line 254: Line 273:
 
If you want to change the JSP settings for all of the webapps, then edit the <tt>$JETTY_HOME/etc/webdefaults.xml</tt> file directly instead.
 
If you want to change the JSP settings for all of the webapps, then edit the <tt>$JETTY_HOME/etc/webdefaults.xml</tt> file directly instead.
  
===Configuring the JSP Servlet in web.xml===
+
===Configuring the JSP Servlet in <tt>web.xml</tt>===
  
 
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]] as a starting point.
 
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]] as a starting point.
Line 268: Line 287:
 
     <init-param>
 
     <init-param>
 
         <param-name>fork</param-name>
 
         <param-name>fork</param-name>
         <param-value>>false</param-value>
+
         <param-value>false</param-value>
 
     </init-param>
 
     </init-param>
 
     <init-param>
 
     <init-param>
 
         <param-name>keepgenerated</param-name>
 
         <param-name>keepgenerated</param-name>
         <param-value>>true</param-value>
+
         <param-value>true</param-value>
 
     </init-param>
 
     </init-param>
 
     ...
 
     ...
Line 297: Line 316:
  
 
</source>
 
</source>
 +
 +
== Using JSTL Taglibs for Jetty 7.x and 8.x ==
 +
-------------------
 +
=== Jetty 7.x===
 +
The JSTL tags are present in the <tt>org.apache.taglibs.standard.glassfish</tt> Jar in <tt>$JETTY_HOME/lib/jsp</tt>. 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 <tt>.tld</tt> 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 <tt>start.ini</tt> file contains <tt>etc/jetty-deploy.xml</tt>), you don't need to do anything, as the pattern is pre-defined in <tt>etc/jetty-deploy.xml</tt>, 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:
 +
 +
<source lang = "xml">
 +
<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>
 +
</source>
 +
 +
{{note|Note|You can use the <tt>org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern</tt> 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.}}
 +
 +
===Jetty 8.x===
 +
 +
The version of JSP 2.2 engine that jetty uses employs a Servlet 3.0 way of finding tlds (see [http://download.oracle.com/javaee/6/api/javax/servlet/ServletContainerInitializer.html ServletContainerInitializer.html]) , and thus does ''not'' require that you define <tt>org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern</tt>.
 +
 +
==Using JSF Taglibs==
 +
 +
===Jetty Standalone===
 +
If you want to use JSF with your webapp, you need to copy the jsf implementation jar (ie whichever Jar contains the <tt>META-INF/*.tld</tt> files from your chosen JSF implementation) into <tt>$JETTY_HOME/lib/jsp</tt>. 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''', then you will need to 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 <tt>org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern</tt>. You need to 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 on just one webapp, create or edit a [[Jetty/Feature/ContextDeployer|context xml]] file that describes your webapp. Assuming the implementation jar is called <tt>javax.faces-2.1.6.jar</tt>:
 +
<source lang = "xml">
 +
<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>
 +
</source>
 +
 +
If you're deploying via code, the equivalent is to call the [http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/webapp/WebAppContext.html WebAppContext.setAttribute(String name, String value)] method.
 +
 +
If you'd like to use jsf with all of your webapps, then assuming you're using the [[Jetty/Feature/Deployment_Manager|DeploymentManager]], edit <tt>$JETTY_HOME/etc/jetty-deploy.xml</tt>. Assuming the implementation jar is named <tt>javax.faces-2.1.6.jar</tt>:
 +
<source lang = "xml">
 +
 +
<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>
 +
</source>
 +
 +
If you are using '''jetty-8.x''' you do not need to add this pattern because Servlet Spec. 3.0 uses a different method of finding TLD descriptors.
 +
 +
===Jetty Maven Plugin===
 +
 +
For versions prior to 7.5.0, then your jsf jars ''should be normal webapp dependencies''. You do not need to do anything else to configure jetty for use with jsf.
 +
 +
From versions 7.5.0 onwards, 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, so you need to make your jsf jars dependencies of the ''plugin'' and ''not'' the webapp itself, eg:
 +
<source lang = "xml">
 +
  <plugin>
 +
    <groupId>org.mortbay.jetty</groupId>
 +
    <artifactId>jetty-maven-plugin</artifactId>
 +
    <configuration>
 +
      <webAppConfig>
 +
        <contextPath>/${artifactId}</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>
 +
</source>
 +
 +
From versions 7.5.0 to 7.6.1, the maven jetty plugin will 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, then you should define the relevant listener in your web.xml:
 +
 +
For MyFaces:
 +
<source lang="xml">
 +
<listener>
 +
    <listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
 +
</listener>
 +
</source>
 +
 +
For Mojarra:
 +
<source lang="xml">
 +
  <listener>
 +
      <listener-class>com.sun.faces.config.ConfigureListener</listener-class>
 +
    </listener>
 +
</source>
 +
 +
From version 7.6.2 onwards the jetty plugin will ensure that the tlds containing the startup listeners from the 2 most common jsf implementations (Mojarra and MyFaces) will be automatically detected.

Latest revision as of 14:40, 23 April 2013



Introduction

Warning2.png
Jetty 7 and Jetty 8 are now EOL (End of Life)




THIS IS NOT THE DOCUMENTATION YOU ARE LOOKING FOR!!!!!






All development and stable releases are being performed with Jetty 9 and Jetty 10.






This wiki is now officially out of date and all content has been moved to the Jetty Documentation Hub






Direct Link to updated documentation: http://www.eclipse.org/jetty/documentation/current/configuring-jsp.html


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 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 JSPC Maven Plugin is helpful for precompilation.

If using jetty-7.5.5 and beyond (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>

Or alternatively, you can put this System property into start.ini:

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

Jetty Maven Plugin

Since 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 so you must use a full JDK.

We hope to be able to introduce a patch to allow the use of 3rd party jars in an upcoming release of the plugin. This page will be updated when we have more information.


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.

Important.png
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

init param Description Default webdefault.xml
development If 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.
httpMethods List of names of http methods which the JSP servlet will service (there is no requirement that these names are restricted to the set defined by rfc2616). Null or a value of "*" means any and all methods. Names should be comma, tab or newline delimited. Null


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 and 8.x


    Jetty 7.x

    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>
    Note.png
    Note
    You can use the 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.


    Jetty 8.x

    The version of JSP 2.2 engine that jetty uses employs a Servlet 3.0 way of finding tlds (see ServletContainerInitializer.html) , and thus does not require that you define org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern.

    Using JSF Taglibs

    Jetty Standalone

    If you want to use JSF with your webapp, you need to copy the jsf implementation jar (ie 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, then you will need to 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 need to 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 on just one webapp, create or edit a context xml file that describes your webapp. 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'd like to use jsf with all of your webapps, then assuming you're using the DeploymentManager, edit $JETTY_HOME/etc/jetty-deploy.xml. 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 of finding TLD descriptors.

    Jetty Maven Plugin

    For versions prior to 7.5.0, then your jsf jars should be normal webapp dependencies. You do not need to do anything else to configure jetty for use with jsf.

    From versions 7.5.0 onwards, 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, so you need to make your jsf jars dependencies of the plugin and not the webapp itself, eg:

       <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>jetty-maven-plugin</artifactId>
        <configuration>
           <webAppConfig>
             <contextPath>/${artifactId}</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>

    From versions 7.5.0 to 7.6.1, the maven jetty plugin will 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, then 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>
    From version 7.6.2 onwards the jetty plugin will ensure that the tlds containing the startup listeners from the 2 most common jsf implementations (Mojarra and MyFaces) will be automatically detected.

Back to the top