JSPBatchCompiler command

JSPBatchCompiler command

The batch compiler validates the syntax of JSP, translates the JSP pages into Java source files, and compiles the Java source files into Java Servlet class files. The batch compiler also validates tag files and generates their Java implementation classes. Use this function to batch compile the JSP files and thereby enable faster responses to the initial client requests for the JSP files on the production web server.
The batch compiler can be executed against compressed or expanded EAR files and WAR files, as well as enterprise applications and web modules that have been deployed into WebSphere Application Server. When the target is a deployed enterprise application, the server does not need to be running to execute the batch compiler. If the batch compiler is executed while the target sever is running, the server is not aware of an updated class file and does not load that class file unless the enterprise application is restarted. When the target is a compressed EAR file or WAR file, the batch compiler must expand it before executing.

Processing of web modules

The batch compiler operates on one web module at a time. If the target is either an EAR file or an installed enterprise application containing more than one web module, the batch compiler operates on each web module individually. This is done because JSP pages are configured on a web module basis, through the web module's web.xml deployment descriptor file. Within a web module, the batch compiler processes one directory at a time. It validates and translates each JSP page individually, and then invokes the Java compiler for the entire group of generated Java sources files in that directory. If one JSP page fails during the Java compilation phase, the Java compiler might not create class files for most or all of the JSP pages that successfully compiled in that directory.

JSP file extensions

The batch compiler uses four things to determine what file extensions it should process:

Standard JSP file extensions

*.jsp

*.jspx

*.jsw

*.jsv

The url-pattern property of the jsp-property-group elements in the deployment descriptor file in Servlet 2.4 web modules

The jsp.file.extensions JSP engine configuration parameter (for pre-Servlet 2.4 web modules)

The batch compiler configuration parameter jsp.file.extensions

The standard extensions are always used by the batch compiler. If the web module contains a Servlet 2.4 deployment descriptor, the batch compiler also processes any url-patterns found within the jsp-config element. If the batch compiler target contains the JSP engine configuration parameter jsp.file.extensions, then those extensions are also processed. If the batch compiler configuration parameter jsp.file.extensions is present, the extensions given are also processed and will override the JSP engine configuration parameter jsp.file.extensions.
It is a good idea to give JSP 'fragments' an extension that is not processed by the batch compiler. Statically-included fragments that do not stand alone generate translation or compilation errors if processed. The JSP 2.0 Specification suggests that you use the extension .jspf for such files.

Batch compiler command

Both a Windows batch file, JspBatchCompiler.bat and UNIX shell script JspBatchCompiler.sh for running the batch compiler from the command line are found in the {WAS_ROOT}/bin directory. An Ant task is also available for executing the batch compiler using Ant. See the topic, Batch Compiler Ant Task for additional information.
The JspBatchCompiler script for running the batch compiler from the Qshell command line is found in the app_server_root/bin directory. An Ant task is also available for executing the batch compiler using Ant. See the topic, Batch Compiler Ant Task for additional information.
The batch compiler target is the only required parameter. The target is one of -ear.path, -war.path or -enterpriseapp.name.
JspBatchCompiler -ear.path | -war.path | -enterpriseapp.name <name>
   [-response.file <filename>]
   [-webmodule.name <name>]
   [-filename <jsp name | directory name>
   [-recurse <true | false>]
   [-config.root <path>]
   [-cell.name <name>]
   [-cluster.name <name>]   [-node.name <name>]
   [-server.name <name>]
   [-profileName <name>]
   [-extractToDir <path>]
   [-compileToDir <path>]
   [-compileToWebInf <true | false>]
      [-compileToWebInf <true | false>]
      [-compileAfterFailure <true | false>]
   [-translate <true | false>]
   [-compile <true | false>]
   [-removeTempDir <true | false>]
   [-forceCompilation <true | false>]
   [-useFullPackageNames <true | false>]
   [-trackDependencies <true | false>]
   [-createDebugClassfiles <true | false>]
   [-keepgenerated <true | false>]
   [-keepGeneratedclassfiles <true | false>]
   [-usePageTagPool <true | false>]
   [-useThreadTagPool <true | false>]
   [-classloader.parentFirst <true | false>]
   [-classloader.singleWarClassloader <true | false>]
   [-additional.classpath <classpath to additional JAR files and classes>]
         [-verbose <true | false>]
   [-deprecation <true | false>]
   [-javaEncoding <encoding>
   [-jdkSourceLevel <13 | 14 | 15 | 16 | 17>]       [-compilerOptions <space-separated list of java compiler options>]
   [-useJikes <true | false>]
   [-jsp.file.extensions <file extensions to process>]
   [-log.level <SEVERE | WARNING | INFO | CONFIG | FINE | FINER | FINEST | OFF>]
   *** See batchcompiler.properties.default in WAS_ROOT/bin for more information. ***
   *** See JspCBuild.xml in WAS_ROOT/bin for information about the public WebSphere Ant task JspC. ***
   *** See batchcompiler.properties.default in app_server_root/bin for more information. ***
   *** See JspCBuild.xml in app_server_root/bin for information about the public WebSphere Ant task JspC. ***
The batch compiler is aware of three groups of configuration parameters:

JSP engine configuration parameters for a web module.
Refer to the JSP engine configuration parameters topic.

Batch compiler response file configuration parameters.
These are the parameters found in a batch compiler response file. See -response.file.

Batch compiler command line configuration parameters.
These are the parameters entered on the command line when running the batch compiler.

The batch compiler looks at all three groups of configuration parameters in order to determine which value for a parameter is used when compiling JSP pages. When resolving the value for a given parameter, the precedence is:

If the parameter is found on the command line, its value is used.

If the parameter is not found on the command line, the batch compiler looks for the parameter in a response file named on the command line.

If no response file is named, or if the parameter is not found therein, the batch compiler looks for the parameter in the web module's JSP engine configuration parameters.

If a configuration parameter is not found among these three groups, then a default value is used. The default values for the configuration parameters are given along with the description of the parameters.
With one exception, these parameters are not case sensitive; -profileName is case sensitive. If the values specified for these arguments are comprised of two or more words separated by spaces, add quotation marks around the values.
The batch compiler does not create, or set the values of, equivalent JSP engine parameters. This means that if a JSP page in a deployed Web module is modified and is recompiled by the JSP engine at run time, the JSP engine's configuration parameters will determine the engine's behavior. For example, if you use the batch compiler to compile a web module and you use the -useFullPackageNames true option, the JSP files will be compiled to support that option. But the JSP engine parameter useFullPackageNames must also be set to true in order for the JSP runtime to be able to load the compiled JSP pages. If JSP pages are modified in a deployed web module, then the engine's parameters should be set to the same values used in batch compilation.
To use the JSP batch compiler, enter one of the following commands on a single line at an operating system command prompt.:

ear.path | war.path | enterpriseapp.name
Represents the full path to a single compressed or expanded EAR file or WAR file, or the name of the deployed enterprise application to compile. For example:

JspBatchCompiler -ear.path c:\myproject\sampleApp.ear

JspBatchCompiler -ear.path /myhfs/myprojects/sampleApp.ear

JspBatchCompiler -war.path c:\myWars\examples.war

JspBatchCompiler -enterpriseapp.name myEnterpriseApp -webmodule.name my.war -filename aDir/main.jsp

JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear

JspBatchCompiler -war.path /home/wasuser/wars/examples.war

JspBatchCompiler -enterpriseapp.name myEnterpriseApp -webmodule.name my.war -filename mydirectory/main.jsp

response.file
Path to a file containing configuration parameters used by the batch compiler. The response.file is used only if it is given on the command line; it is ignored if it is present in a response file.
In a default installation, the template response file, batchcompiler.properties.default, is found in the {WAS_ROOT}/bin directory. Copy this template to create our own response files containing defaults for the parameters in which we are interested. All the required and optional parameters (except response.file) can be configured in a response file. For example: JspBatchCompiler -response.file c:\myproject\batchc.props
The template response file, batchcompiler.properties.default, is found in the app_server_root/properties directory. Copy this template to create our own response files containing defaults for the parameters in which we are interested. We can configure all the required and optional parameters, except the response.file in a response file.For example: JspBatchCompiler -response.file /home/wasuser/myproject/batchc.props
Default : null

webmodule.name
Represents the name of the specific web module to batch compile. If this argument is not set, all web modules in the enterprise application are compiled. This parameter is used only when ear.path or enterpriseapp.name is given. This parameter is useful when JSP pages in a specific web module within a deployed enterprise application need to be regenerated, because all shared library dependencies are picked up.
Example: JspBatchCompiler -enterpriseApp.name sampleApp -webmodule.name myWebModule.war
Default: All web modules in an EAR file or enterprise application are compiled if this parameter is not given.

filename
Represents the name of a single JSP file to compile. If this argument is not set, all files in the web module are compiled. Alternatively, if filename is set to the name of a directory, only the JSP files in that directory and that directory's child directories are complied. The name is relative to the context root of the web module.
Example 1: To compile the file, myTest.jsp, and it is found in /subdir/myJSPs, you would enter -filename /subdir/myJSPs/myTest.jsp.
Example 2: To compile all JSP files in /subdir/myJSPs and its child directories, you would enter -filename subdir/myJSPs.
Default: All JSP files in the web module are compiled. Entering -filename / is equivalent to the default.

recurse
Determines whether subdirectories beneath the target directory are processed. This parameter is used only when the filename parameter is given. Set value to false to process only the directory named filename parameter; and not its subdirectories.
Example: JspBatchCompiler -enterpriseApp.name sampleApp -filename /subdir1 -recurse false.
Default: true; All directories beneath the target directory are processed.

config.root
Location of the WebSpehere Application Server configuration directory. This parameter is used only when enterpriseapp.name is given.
Default: {WAS_ROOT}/profiles/profilename/config
Default: profile_root/config

cell.name
Name of the cell in which the application is deployed. This parameter is used only when enterpriseapp.name is given.
Default: The default is obtained from the profile script used. The symbolic name of this variable is WAS_CELL.

cluster.name
Name of the cluster in which the application is deployed. This parameter provides the batch compiler with access to cluster scoped shared libraries, and is used only when enterpriseapp.name is given.
Default: The default is obtained from the profile script used. The symbolic name of this variable is WAS_CLUSTER.

node.name
Name of the node in which the application is deployed. This parameter is used only when enterpriseapp.name is given.
Default: The default is obtained from the profile script used. The symbolic name of this variable is WAS_NODE.

server.name
Represents the name of the server in which the application is deployed. This parameter is used only when enterpriseapp.name is given.
Default: server1

profileName
Name of the profile to use. This parameter is used only when the enterpriseapp.name or -ear. path is given.
Example: JspBatchCompiler -enterpriseApp.name sampleApp -profileName AppServer-3
Default: The default profile is used. This is obtained from the file setupCmdLine script in the install_root/bin directory. The symbolic name is DEFAULT_PROFILE_SCRIPT.
Default: The default profile is used. This is obtained from the setupCmdLine script in the app_server_root/bin directory. The symbolic name is DEFAULT_PROFILE_SCRIPT.

extractToDir
Directory into which predeployed EAR files and WAR files will be extracted before the batch compiler operates on them. This parameter is ignored when enterpriseapp.name is given. The extractToDir parameter is used as described in the table .
Example: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -extractToDir c:\myTempDir.
Example: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -extractToDir /home/wasuser/mytempdir.
Use-case: We must extract a compressed archive before it is batch compiled. We can also extract an expanded archive to a new directory as well. In both cases, extraction leaves the original archive untouched, which may be useful while development is underway.

Expanded archive Compressed archive
extractToDir supplied The batch compiler extracts the archive to extractToDir before operating on it. If a file or directory of the same name as the archive already exists in the extractToDir, the batch compiler removes the archive completely before extracting that archive. If the batch compiler exits with no errors, it compresses the archive in place in the extractToDir, even if the original EAR file or WAR file was expanded. If errors are encountered during compilation, the EAR file or WAR file is left in the expanded state even if the original EAR file or WAR file was compressed.
extractToDir not supplied The batch compiler operates on the EAR file or WAR file in place (does not extract it to another directory) and the archive remains expanded after the batch compiler finishes. The batch compiler extracts the archive to the directory returned by the JVM property "java.io.tmpdir". The rest of the behavior described , when extractToDir is supplied, is the same in this case.

The default is server1.

compileToDir
Directory into which JSP pages are translated into Java source files and compiled into class files. This directory can be anywhere on the filesystem, but the batch compiler's default behavior is usually adequate. The batch compiler's behavior when compiling class files is described in the table
Example:: JspBatchCompiler -enterpriseApp.name sampleApp -compileToDir c:\myTargetDir
Example:: JspBatchCompiler -enterpriseApp.name sampleApp -compileToDir /home/wasuser/myTargetDir
Use-case: This parameter enables you to generate the Java and class files into a directory outside of the target, which may be useful to compare the newly generated files with their previous versions which remain untouched within the target.

ear.path or war.path supplied enterpriseApp.name supplied
compileToDir not supplied; compileToWebInf not supplied, or is true The class files are compiled into the web module's WEB-INF/classes directory The class files are compiled into the web module's WEB-INF/classes directory.
compileToDir not supplied; compileToWebInf is false The class files are compiled into the web module's WEB-INF/classes directory. The class files are compiled into the WAS temp directory (usually {WAS_ROOT}/temp).
compileToDir is supplied; compileToWebInf not supplied, or is either true or false The class files are compiled into the directory indicated by compileToDir. The class files are compiled into the directory indicated by compileToDir.

ear.path or war.path supplied enterpriseApp.name supplied
compileToDir not supplied; compileToWebInf not supplied, or is true The class files are compiled into the web module's WEB-INF/classes directory The class files are compiled into the web module's WEB-INF/classes directory.
compileToDir not supplied; compileToWebInf is false The class files are compiled into the web module's WEB-INF/classes directory. The class files are compiled into the WAS temp directory (usually profile_root/temp).
compileToDir is supplied; compileToWebInf not supplied, or is either true or false The class files are compiled into the directory indicated by compileToDir. The class files are compiled into the directory indicated by compileToDir.

compileToWebInf
Whether the target directory for the compiled JSP class files should be the web module's WEB-INF/classes directory. This parameter is used only when enterpriseApp.name is given, and it is overridden by compileToDir if compileToDir is given.
The batch compiler's default behavior is to compile to the web module's WEB-INF/classes directory. The batch compiler's behavior when compiling class files is described in the table .
Example: JspBatchCompiler -enterpriseApp.name sampleApp -compileToWebInf false.
Use-case: Set this parameter to false when enterpriseApp.name is supplied and we want the class files to be compiled to the WAS temp directory instead of the web module's WEB-INF/classes directory. Recommendation: if this parameter is set to false, set forceCompilation to true if there are any JSP class files in the WEB-INF/classes directory.
Default: true; see the table .

compileAfterFailure
Whether the JDK JSP batch compiler continues to compile the other JSP (JSP) files in the current directory if one or more of the JSP (JSP) files in that directory cannot be complied. Typically when one of the files cannot be compiled, the JSP batch complier skips all of the remaining JSPs in that directory, and starts to compile the files in the next directory.
If we set this parameter to true, you must also specify the useJDKCompiler parameter and set that parameter to true.
Example: JspBatchCompiler -enterpriseApp.name sampleApp -useJDKCompiler true -compileAfterFailure false.
Use-case: Set this parameter to true if we want the JSP batch compiler compile the other JSP (JSP) files in the current directory even if one or more of the JSP files in that directory cannot be complied.
Default: false

forceCompilation
Whether the batch compiler is forced to recompile all JSP resources regardless or whether the JSP page is outdated.
Example: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -forceCompilation true.
Example: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -forceCompilation true.
Use-case: Especially useful when creating an archive for deployment, to make sure all JSP classes are up to date.
Default: false

useFullPackageNames
Whether the batch compiler generates full package names for JSP classes. The default is to generate all JSP classes in the same package. The JSP engine's class loader knows how to load JSP classes when they are all in the same package. The default has the benefit of generating smaller file-system paths. Full package names have the benefit of enabling the configuration of precompiled JSP class files as servlets in web.xml without use of the jsp-file attribute, resulting in a single class loader (the web application's class loader) being 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 pages are not configured as servlets in web.xml.
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 page that is successfully translated and compiled. The information can optionally be copied into the web module's web.xml file so that the JSP pages are loaded as servlets by the web container. Note that if a JSP page is configured as a servlet in this way, no reloading of the JSP page is done at run time if the JSP page is modified. This is because the JSP page is treated as a regular servlet and requests for it do not pass through the JSP engine.
Example: JspBatchCompiler -enterpriseApp.name sampleApp -useFullPackageNames true
Use-case: Enables JSP classes to be loaded by a single class loader.
Default: false

removeTempDir
Whether the web module's temp directory is removed. The batch compiler by default generates JSP class files into a web module's WEB-INF/classes directory. JSP class files are generated into the temp directory at run time if a JSP page is modified and JSP reloading is enabled. By batch compiling all the JSP pages in a web module and also removing the temp directory, disk resources are preserved. We can only use the removeTempDir parameter when -enterpriseApp.name is given.
Example: JspBatchCompiler -enterpriseApp.name sampleApp -removeTempDir true.
Use-case: Free up disk space by clearing out a web application's temp directory.
Default: false

translate
Whether JSP pages are translated and compiled. Set translate to false if we do not want JSP pages to be translated and compiled. We must use this option in conjunction with -removeTempDir to tell the batch compiler to remove only the temp directory and to do no further processing.
Example: JspBatchCompiler -enterpriseApp.name sampleApp -translate false -removeTempDir true.
Use-case: Free up disk space by clearing out a web application's temp directory, without invoking JSP processing.
Default: true

compile
Whether JSP pages go through the Java compilation phase. Set compile to false if we do not want JSP pages to go through the Java compilation phase.
Example: JspBatchCompiler -enterpriseApp.name sampleApp -compile false
Use-case: If we only want JSP pages to be syntax-checked, set -compile to false. We can set -keepgenerated to true to see the .java files that are generated during the translation phase.
Default: true

trackDependencies
Whether the batch compiler recompiles a JSP page when any of its dependencies have changed, even if the JSP page itself has not changed. Tracking dependencies incurs a significant runtime performance penalty because the JSP Engine checks the filesystem on every request to a JSP page to see if any of its dependencies have changed. The dependencies tracked by WebSphere Application Server are :

Files statically included in the JSP page

Tag files used by the JSP page (excluding tag files that are in JAR files)

TLD files used by the JSP page (excluding TLD files that are in JAR files)

Example: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -trackDependencies true.
Example: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -trackDependencies true.
Use-case: Useful in a development environment.
Default: false

createDebugClassfiles
Whether the batch compiler generates class files containing SMAP information, as per JSR 45, Debugging support for Other Languages.
Example: JspBatchCompiler -enterpriseApp.name sampleApp -createDebugClassfiles true
Use-case: Use this parameter when to be able to debug JSP pages in the JSR 45-compliant IDE.
Default: false

keepgenerated
Whether the batch compiler saves or erases the generated Java source files created during the translation phase.
If set to true, WebSphere Application Server saves the generated .java files used for compilation on the server. By default, this argument is set to false and the .java files are erased after the class files have compiled.
Example: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -keepgenerated true
Example: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -keepgenerated true
Use-case: Use this parameter when to review the Java code generated by the batch compiler.
Default: false

keepGeneratedclassfiles
Whether the batch compiler saves or erases the class files generated during the compilation of Java source files.
Example: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -keepGeneratedclassfiles false -keepgenerated false
Example: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -keepGeneratedclassfiles false -keepgenerated false
Use-case: Set this parameter to false if you only want to see if there are any translation or compilation errors in the JSP pages. If paired with -keepgenerated false, this parameter results in all generated files being removed before the batch compiler completes.
Default: true

usePageTagPool
Enables or disables the reuse of custom tag handlers on an individual JSP page basis.
Example: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -usePageTagPool true
Example: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -usePageTagPool true
Use-case: Use this parameter to enable JSP-page-based reuse of tag handlers.
Default: false

useThreadTagPool
Enables or disables the reuse of custom tag handlers on a per request thread basis per web module.
Example: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -useThreadTagPool true
Example: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -useThreadTagPool true
Use-case: Use this parameter to enable web module-based reuse of tag handlers.
Default: false

classloader.parentFirst
Specifies the search order for loading classes by instructing the batch compiler to search the parent class loader prior to application class loader. This parameter is only used when ear.path or enterpriseApp.name is given.
Example: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -classloader.parentFirst false
Example: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -classloader.parentFirst false
Use-case: Set this parameter to false when the web module contains a JAR file that is also found in the server lib directory, and we want the web module's JAR file to be picked up first.
Default: true

classloader.singleWarClassloader
Whether to use one class loader per EAR file or one class loader per WAR file. Used only when ear.path or enterpriseApp.name is given.
Example: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -classloader.singleWarClassloader true
Example: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -classloader.singleWarClassloader true
Use-case: Set this parameter to true when a Web module depends on JAR files and classes in another web module in the same enterprise application.
Default: false; One class loader is created per WAR file with no visibility of classes in other web modules.

additional.classpath
Specifies additional class path entries to be used when parsing and compiling JSP pages. This parameter is used only when war.path is given. When war.path is the target, WebSphere Shared Libraries are not picked up by the batch compiler. If your WAR file relies on, for example, a JAR file configured in WebSphere Application Server as a shared library, then use this option to point to that JAR file. In addition, if you give war.path and also use the -extractToDir parameter, then any JAR files that are in the WAR file's manifest class-path is not added to the class path (since the WAR file has now been extracted by itself outside the EAR file in which it resides). Use -additional.classpath in this case to point to the necessary JAR files. Add the full path to needed resources, separated by the system-dependent path separator.
Example: JspBatchCompiler -war.path c:\myproject\examples.war -additional.classpath c:\myJars\someJar.jar;c:\myClasses
Example: JspBatchCompiler -war.path /home/wasuser/myproject/examples.war -additional.classpath /home/wasuser/myJars/someJar.jar:/home/wasuser/myClasses
Use-case: Use this parameter to add to the class path JAR files and classes outside of the WAR file. At run time, these same JAR files and classes have to be made available through the standard WebSphere Application Server configuration mechanisms.
Default: null

verbose
Whether the batch compiler should generate verbose output while compiling the generated sources.
Example: JspBatchCompiler -war.path c:\myproject\examples.war -verbose true
Example: JspBatchCompiler -war.path /home/wasuser/myproject/examples.war -verbose true
Use-case: Set this parameter to true when to see Java compiler class loading and other messages.
Default: false

deprecation
Indicates the compiler should generate deprecation warnings while compiling the generated sources.
Example: JspBatchCompiler -war.path c:\myproject\examples.war -deprecation true
Example: JspBatchCompiler -war.path /home/wasuser/myproject/examples.war -deprecation true
Use-case: Set this parameter to true when to see Java compiler deprecation messages.
Default: false

javaEncoding
Encoding that will be used when the .java file is generated, and when it is compiled by the Java compiler. When -javaEncoding is set, that encoding is passed to the java compiler via the -encoding argument. Note that encoding is not supported by Jikes.
Example: JspBatchCompiler -war.path c:\myproject\examples.war -javaEncoding Shift-JIS
Example: JspBatchCompiler -war.path/home/wasuser/myproject/examples.war -javaEncoding Shift-JIS
Use-case: Set this parameter when the page encoding of the JSP pages is not UTF-8 compatible.
Default value: UTF-8.

jdkSourceLevel
This JSP engine parameter was introduced in WebSphere Application Server version 6.1 to support JDK 5. Use this parameter instead of the compileWithAssert parameter, although compile WithAssert still works in version 6.1.
The default value for this parameter is 16. This parameter requires regeneration of Java source. The following are jdkSourceLevel paramater values:

13 - This value will disable all new language features of JDK 1.4, JDK 5.0, JDK 6.0, and JDK 7.0.

14 - This value will enable the use of the assertion facility and will disable all new language features of JDK 5.0, JDK 6.0, and JDK 7.0.

15 - This value will enable the use of the assertion facility and will disable all new language features of JDK 6.0 and JDK 7.0.

16 - This value will enable the use of the assertion facility and will disable all new language features of JDK 7.0.

17 - This value will enable the use of the new features of JDK 7.0.

Example: JspBatchCompiler -war.path c:\myproject\examples.war -jdkSourceLevel 14
Use-case: Set this parameter when to enable or disable the language features of JDK 1.4 , JDK 5.0, JDK 6.0, and JDK 7.0
Default value: 16

compilerOptions
List of strings to be passed on the Java compiler command. This is a space-separated list of the form "arg1 arg2 argn".
Example: JspBatchCompiler -war.path c:\myproject\examples.war -compilerOptions "-bootclasspath <path>"
Example: JspBatchCompiler -war.path /home/wasuser/myproject/examples.war -compilerOptions "-bootclasspath <path>"
Use-case: Use this parameter if we need Java compiler arguments other than verbose, deprecation and Assert facility support.
Default: null

useJikes
Whether Jikes should be used for compiling Java sources. NOTE: Jikes is not shipped with WebSphere Application Server.
Example: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -useJikes true
Example: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -useJikes true
Use-case: Set this parameter to true in order for the batch compiler to use Jikes as the Java compiler.
Default value: false

jsp.file.extensions
File extensions to be processed by the batch compiler. This is a semicolon- or colon-separated list of the form "*.ext1;*.ext2:*.extn". Note that this parameter is not necessary for Servlet 2.4 web applications because the url-pattern property of the jsp-property-group elements in the deployment descriptor can be used to identify extensions that should be treated as JSP pages.
Example: JspBatchCompiler -enterpriseApp.name sampleApp -jsp.file.extensions *jspz;*.jspt
Use-case: Use this parameter to add additional extensions to the be processed by the batch compiler.
Default: null. See section, "JSP file extensions", in this topic for additional information.

log.level
Level of logging that is directed to the console during batch compilation. Values are SEVERE | WARNING | INFO | CONFIG | FINE | FINER | FINEST | OFF
Example: JspBatchCompiler -enterpriseApp.name sampleApp -log.level FINEST
Use-case: Set this parameter higher or lower to control logging output. FINEST generates the most output useful for debugging.
Default: CONFIG

Related concepts

JSP

Related tasks

Configure JSP engine parameters

Batch compiler ant task
Web applications: Resources for learning

Related information:

JSP engine configuration parameters Reference topic

	Expanded archive	Compressed archive
extractToDir supplied	The batch compiler extracts the archive to extractToDir before operating on it. If a file or directory of the same name as the archive already exists in the extractToDir, the batch compiler removes the archive completely before extracting that archive. If the batch compiler exits with no errors, it compresses the archive in place in the extractToDir, even if the original EAR file or WAR file was expanded. If errors are encountered during compilation, the EAR file or WAR file is left in the expanded state even if the original EAR file or WAR file was compressed.
extractToDir not supplied	The batch compiler operates on the EAR file or WAR file in place (does not extract it to another directory) and the archive remains expanded after the batch compiler finishes.	The batch compiler extracts the archive to the directory returned by the JVM property "java.io.tmpdir". The rest of the behavior described , when extractToDir is supplied, is the same in this case.

	ear.path or war.path supplied	enterpriseApp.name supplied
compileToDir not supplied; compileToWebInf not supplied, or is true	The class files are compiled into the web module's WEB-INF/classes directory	The class files are compiled into the web module's WEB-INF/classes directory.
compileToDir not supplied; compileToWebInf is false	The class files are compiled into the web module's WEB-INF/classes directory.	The class files are compiled into the WAS temp directory (usually {WAS_ROOT}/temp).
compileToDir is supplied; compileToWebInf not supplied, or is either true or false	The class files are compiled into the directory indicated by compileToDir.	The class files are compiled into the directory indicated by compileToDir.