WAS v8.5 > Reference > Sets

JSP class loading settings page

We can configure a JSP class to be loaded by either...

• JSP engine's class loader
• web module's class loader.

By default, a JSP class is loaded by a unique instance of the JSP engine's class loader, which enables reloading at runtime of a JSP class when the JSP source changes, without affecting any other loaded JSP classes.

JSP classes are loaded by the web module's class loader under either of the following scenarios.

• useFullPackageNames=true
• The JSP file is configured as a servlet in web.xml using the <servlet-class> scenario

...or...

• useFullPackageNames=true
• disableJspRuntimeCompilation=true

In this case, we do not need to configure a JSP file does as a servlet in web.xml.

Configure JSP files as Servlets

Configuring a JSP file as a servlet in web.xml provides...

Reloading capability	If runtime reloading of JSP files is desired, requests for JSP files must be handled by the JSP engine. The <servlet-class> scenario disables runtime JSP file reloading. The <jsp-file> scenario is compatible with reloading.
Reducing the number of class loaders	If we do not require runtime reloading of modified JSP pages and to reduce the number of class loader instances, then we 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.

To configure a JSP file as a servlet in web.xml...

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 JSP 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 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). We can copy and paste all or some of these elements into web.xml to configure JSP files as servlets.

Take note of the location of the web.xml 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:
  {WAS_ROOT}/profiles/profilename/config/cells/cellname/applications/enterpriseappname/deployments/deployedname/webmodulename

• An example of an application binaries directory is:
  {WAS_ROOT}/profiles/profilename/installedApps/nodename/EnterpriseAppName/WebModuleName/

If the JSP batch_compiler is executed on a pre-deployed application then web.xml is in the web module's WEB-INF directory.

Related

Configure JSP engine parameters

Reference:

JSP runtime reloading settings

+

Search Tips   |   Advanced Search