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.