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.
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 below.
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 below 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 below. Similarly,
scenario 2 in section 1 above 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 servlet
Scenario |
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. Below are examples of these two locations.
An example of a configuration repository directory
is {WAS_ROOT}/profiles/profilename/config/cells/cellname/applications/enterpriseappname/deployments/deployedname/webmodulename
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: {WAS_ROOT}/profiles/profilename/installedApps/nodename/EnterpriseAppName/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.