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.

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:

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 a short hand 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 (in the example below, every 60 sec):

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