Jetty has moved!
Jetty is a project at the Eclipse Foundation.
Homepage:http://www.eclipse.org/jetty
Downloads: http://download.eclipse.org/jetty/
Documentation:http://www.eclipse.org/jetty/documentation/current/
About:http://www.eclipse.org/jetty/about.php
Jetty Powered:http://www.eclipse.org/jetty/powered/
Contact the core Jetty developers at www.webtide.com
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Jsp Configuration

There are many configuration parameters for the jsp engine. Some parameters only affect pre-compilation, 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 meaning and their default settings.

Be Careful

Icon

For all of the parameter names below, if its not working, then try using all lower case instead of camel case, as the implementation is quite inconsistent in its parameter naming strategy.

Also be aware that for JDK1.6, the default for "keepgenerated" is "false", therefore .java files will only be left after compilation if there is a compilation error.

Jsp 2.1

init param

Description

Default

webdefault.xml

development

If development=true, recompilation checks are made 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 clients 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. Set by Jetty according to the work dir settings for the webapp.

-

-

compiler

Determined at runtime. For Jetty 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 jsps, 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:

  1. Check the jsp files for possible recompilation on every request:
  2. Only check approximately every N seconds, where a request will trigger the time-lapse calculation. This example checks every 60 seconds:
  3. Do no checking whatsoever, but still compile the jsp on the very first hit. (Note: this "reload-interval" parameter is a short hand for a "development=false" and "checkInterval=0" combination):
  4. Don't do any request-time checking, but instead start a background thread to do checks every N seconds (in the example below, every 60 sec):
  • No labels
Contact the core Jetty developers at www.webtide.com
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery