JSP engine configuration parameters

In WebSphere Application Server, one can configure the JavaServer Pages (JSP) engine for optimal performance in a production server environment and for the needs of developers in a development environment. The configuration parameters are described below.

The JSP engine parameters are case sensitive. If the value specified for a parameter is comprised of two or more words separated by spaces, add quotation marks around the value. Some parameters affect the Java source that is generated for a JSP or tag file. These parameters are identified by the statement "This parameter requires regeneration of Java source." This statement indicates that if the configuration parameter is modified, the new value for the parameter does not have any effect until the JSP files are retranslated and the Java sources are recompiled.

  • compileWithAssert

    Specifies whether the generated Java classes should contain support for the Developer Kit, Java Technology Edition 1.4 Assertion facility. The effect of setting this parameter to true is that the –source 1.4 option is passed to the Java compiler. The default for this parameter is false. This parameter requires regeneration of Java source.

  • classdebuginfo

    Indicates whether the compiler includes debugging information in the generated class file. When you set this parameter to true, the –g option is passed to the Java compiler. The default for this parameter is false. This parameter requires regeneration of Java source.

  • deprecation

    Specifies whether the compiler generates deprecation warnings when compiling the generated Java source. When you set this parameter to true, the -deprecation option is passed to the Java compiler. The default for this parameter is false. This parameter requires regeneration of Java source.

  • disableJspRuntimeCompilation

    If this option is set to true, the JSP engine at runtime does not translate and compile JSP files; the JSP engine loads only precompiled class files. JSP source files do not need to be present in order to load class files. When this option is set to true, install an application without JSP source, but the application must have precompiled class files. There is a Web container custom property with the same name that is used to determine the behavior of all Web modules installed in a server. If both the Web container custom property and the JSP engine option are set, the JSP engine option takes precedence. The default for this parameter is false.

  • extendedDocumentRoot

    To allow a JSP file resource to be shared across Web application archives, specify a comma delimited list of directories and/or Java Archive (JAR) files as search paths to be used if the requested resource cannot be located in the Web application archive's public document tree. If the JSP file is located inside a JAR file and reloadEnabled is true, the timestamp of the JAR file is used for isOutDated checks for recompile purposes. The default for this parameter is null.

  • ieClassID

    Indicates the Java plug-in COM class ID for Internet Explorer. The <jsp:plugin> tags use this value. The default classid is clsid:8AD9C840-044E-11D1-B3E9-00805F499D93. This parameter requires regeneration of Java source.

  • javaEncoding

    Specifies the encoding that is used when the .java file is generated, and when it is compiled by the Java compiler. Set this parameter when the page encoding of your JSP pages is not UTF-8 compatible. When javaEncoding is set, the encoding is passed to the Java compiler through the -encoding argument. Note that encoding is not supported by Jikes. The default is UTF-8. This parameter requires regeneration of Java source.

  • jspCompileClasspath

    This parameter tells the JSP engine to use a small class path for the Java compilation phase. The small class path speeds up the compilation process. This small class path is not used by default because it includes only a subset of WebSphere JAR files and excludes many WebSphere JAR files that contain WebSphere public APIs.

    If your JSP files do not use WebSphere public APIs within scriptlets, one can enable the small class path by using the jspCompileClasspath parameter with no value. See the example in Configuring JSP engine parameters If your JSP files do use WebSphere public APIs within scriptlets, then add those additional JAR files to the jspCompileClasspath option. The JAR file entries are separated by spaces, and are assumed to be relative to the WAS installation root.

    The entire WebSphere class path is used by default. This parameter requires regeneration of Java source.

  • jsp.file.extensions

    For JSP files with extensions other than the four standard extensions, *.jsp, *.jspx, *.jsw, and *.jsv, one can configure this the extensions using this parameter. These extensions are added to the standard extensions. The preferred method for doing this is to create a <jsp-property-group>in web.xml, and add a <url-pattern> tag for each extension.

    The JSP engine can handle a list of file extensions that is separated by a colon or semi-colon. For example, *.ext1;*.ext2:*.extn

  • keepgenerated

    Indicates that the Java files generated by the JSP compiler during the translation phase of the processing are retained. The default for this parameter is false. This parameter requires regeneration of Java source.

  • keepGeneratedclassfiles

    Indicates that the class files generated by the JSP compiler during the translation phase of the processing are retained. The default for this parameter is true. This parameter requires regeneration of Java source.

  • reloadEnabled

    Determines whether or not a JSP file is translated and compiled at runtime if the JSP file or its dependencies (see trackDependencies) are modified. If reloadEnabled is false, a JSP file is still compiled, if necessary, on the first request to it unless the parameter disableJspRuntimeCompilation is true. The default for this parameter is false.

    If this JSP engine parameter is not specified, the equivalent Web container parameter for Web module class reloading is used. However, for an application whose deployment descriptor is at the Servlet 2.2 level, the default is true. This is done for the support of applications being migrated from WebSphere Application Server V4.x.

  • reloadInterval

    If reloading is enabled, reloadInterval determines the delay between checks to see if a JSP file is outdated. For example, if reloadInterval is 5, the JSP engine checks to see if a JSP file is outdated only when the last such check was done more than 5 seconds prior to the current request for the JSP file. The larger the reloadInterval, the less frequently the JSP engine checks for the need to reload a JSP file. If this JSP engine parameter is not specified, the equivalent Web container parameter for Web module class reloading is used. However, for an application whose deployment descriptor is at the Servlet 2.2 level, the default is 5 seconds. This is done for the support of applications being migrated from WebSphere Application Server V4.x.

  • scratchdir

    Directory where the generated class files are created. The system property com.ibm.websphere.servlet.temp.dir is used to set the scratchdir option on a server-wide basis. The JSP engine scratchdir parameter takes precedence over the system property com.ibm.websphere.servlet.temp.dir. The default for this parameter is {WAS_ROOT}/profiles/profilename/temp. This parameter requires regeneration of Java source.

  • trackDependencies

    If reloading is enabled, trackDependencies determines whether the JSP engine tracks modifications to the requested JavaServer Pages files dependencies as well as to the JSP file itself. The dependencies tracked by the JSP engine are :

    1. files statically included in the JSP file

    2. tag files referenced in the JSP file (excluding tag files that are in JARs)

    3. TLD files referenced in the JSP file (excluding TLDs that are in JARs)

    The default is false.

  • useFullPackageNames

    If useFullPackageNames is true, the JSP engine generates and loads JSP classes using full package names. The default is to generate all JSP classes in the same package. (For more information, see Packages and directories for generated .java and .class files). The JSP engine's class loader knows how to load JSP classes when they are all in the same package.

    The default method of generating all JSP classes in the same package has the benefit of generating smaller file-system paths. Full package names has the benefit of enabling the configuration of precompiled JSP class files as servlets in the web.xml file without the use of the jsp-file attribute, resulting in a single class loader, the Web application's class loader, that is used to load all such JSP classes. Similarly, when the JSP engine's configuration attributes useFullPackageNames and disableJspRuntimeCompilation are both true, a single class loader is used to load all JSP classes, even if the JSP files are not configured as servlets in the web.xml file.

    When useFullPackageNames is set to true, the batch compiler generates a file called generated_web.xml in the Web module's WEB-INF directory. This file contains servlet configuration information for each JSP file that was successfully translated and compiled. The information can optionally be copied into the Web module's web.xml file so that the JSP files are loaded as servlets by the Web container. Note that if a JSP file is configured as a servlet in this way, no reloading of the JSP file is done at runtime if the JSP file is modified. This is because the JSP file is treated as a regular servlet and requests for it do not pass through the JSP engine. This parameter requires regeneration of Java source.

  • useImplicitTagLibs

    The JSP engine implicitly recognizes tsx and jsx as tag library prefixes for tag libraries supplied by the JSP engine. If tsx or jsx are used as prefixes for a customer’s tag library, the customer’s tag library overrides the implicit tag library. However, the implicit tag library is still cached by the JSP engine. Explicitly setting this parameter to false tells the engine not to cache the implicit tag library, and save resources. The default for this parameter is true.

  • useJikes

    Specifies whether Jikes is used for compiling Java sources. NOTE: Jikes is not shipped with WebSphere Application Server. The default for this parameter is false. This parameter requires regeneration of Java source.

  • usePageTagPool

    *Enables or disables the reuse of custom tag handlers on an individual JavaServer Pages basis. The default for this parameter is false. This parameter requires regeneration of Java source.

  • useThreadTagPool

    *When thread-level tag handler pooling is used, tag handlers may be reused among separate occurrences of a custom action across all JSP pages in a single Web module across separate requests. The default for this parameter is false. This parameter requires regeneration of Java source.

  • verbose

    Indicates that the compiler generates verbose output when compiling the generated Java source code. The effect of setting this parameter to true is that the -verbose option is passed to the Java compiler. The default for this parameter is false. This parameter requires regeneration of Java source.

*Enabling custom tag handler reuse might reveal problems in the tag handler code with regard to the tag's ability to be reused. A custom tag handler should always do two things:

  • The release method of the tag handler should reset its state and release any private resources that it might have used. The JSP engine ensures the release method is called before the tag handler is garbage collected.

  • In the doEndTag method, all instance states associated with this instance must be reset.

 

Related Tasks


Configuring JSP engine parameters

 

See Also


Configuring JSP runtime reloading