You can configure a JavaServer Pages (JSP) class to be
loaded by either the JSP engine's class loader or by the web module's
class loader.
By default, a JSP class is loaded by a unique instance of the JSP
engine's class loader. The JSP engine's class loader enables reloading
at runtime of a JSP class when the JSP source or one of its dependents
is modified. This allows you to reload a single JSP class when necessary,
without affecting any other loaded JSP classes.
JSP classes are loaded by the web module's class loader under either
of the following scenarios.
- The JSP engine configuration parameter useFullPackageNames is
set to true, and the JSP file is configured as a servlet in the web.xml file
using the <servlet-class> scenario in the
table later in this topic.
- The JSP engine configuration parameters useFullPackageNames and
disableJspRuntimeCompilation are both set to true. In this case,
you do not need to configure a JSP file does as a servlet in the web.xml file.
Configuring JSP files as Servlets
You can
configure a JSP file as a servlet in the web.xml file.
There are two ways to do this. They are described in the table later
in this section.
Before you configure a JSP file as a servlet,
consider the following.
- Reloading capability - If runtime reloading of JavaServer Pages
files is desired, requests for JavaServer Pages files must be handled
by the JSP engine. The <servlet-class> scenario
in the table later in this section disables runtime JSP file reloading,
while the <jsp-file> scenario is compatible
with reloading.
- Reducing the number of class loaders - If you do not require runtime
reloading of modified JSP pages and you want to reduce the number
of class loader instances, then you can use the <servlet-class> scenario
in the table that follows. Similarly, scenario 2 in section 1 can
be used without having to configure a JSP file as a servlet.
Table 1. Example: Configure
a JSP file as a servlet in the web.xml file.. Configure a JSP file as a servletScenario |
Example |
compatible with runtime reloading |
multiple class loaders used? |
useFullPackageNames |
<jsp-file> |
<servlet> <servlet-name>jspOne</servlet-name>
<jsp-file>jspOne.jsp</jsp-file>
</servlet>
|
Yes |
Yes |
Can be true or false |
<servlet-class> |
<servlet> <servlet-name>jspTwo</servlet-name>
<servlet-class>_ibmjsp.jspTwo</servlet-class>
</servlet>
|
No |
No |
Must be true |
The JSP batch compiler tool helps you configure JavaServer
Pages files as servlets. When useFullPackageNames is true, the JSP
batch compiler generates <servlet> and <servlet-mapping> elements
for each JSP file that it successfully translates and compiles. The
elements are written to a web.xml fragment file
named generated_web.xml which is located in the
binaries WEB-INF directory of a web module processed
by the JSP file batch compiler (this directory is located within the
deployed application's ear file). You can copy and paste all or some
of these elements into the web.xml file to configure
JavaServer Pages files as servlets.
Take note of the location
of the
web.xml that is used by the application
server. The application specific configuration is obtained from either
the application binaries (the application's ear file) or from the
configuration repository. If an application is deployed into WebSphere® Application Server with the flag
Use Binary Configuration set to true, then the
WEB-INF/web.xml file
is looked for in a web module's binaries directory, not in the configuration
repository. Examples of these two locations follow:
An example of a configuration repository directory
is profile_root/config/cells/cellName/applications/enterpriseAppName/deployments/deployedName/webModuleName
An example of an application binaries directory
is: profile_root/installedApps/nodeName/EnterpriseAppName/WebModuleName/
If the JSP batch compiler is executed on a pre-deployed
application then the web.xml file is in the web
module's WEB-INF directory.