NonStop Servlets for JavaServer Pages (NSJSP) 6.1 System Administrator's Guide

Configuring NSJSP
NonStop Servlets for JavaServer Pages (NSJSP) 6.1 System Administrator’s Guide—596210-006
3-57
The server.xml File
Considerations for Configuring the Attributes of the Host Element
It is important to understand the effect of the autoDeploy, unpackWARs and
deployXML attributes with regard to the security of the NSJSP servlet container
and application resources.
autoDeploy
Setting autoDeploy to true could result in the redeployment of an entire
application, if any changes are made to watched application resources. For more
information on watched application resources, see WatchedResource on
page 3-65. Setting autodeploy to false will prevent any changes made to the
deployed application from affecting the running application. The basic premise is
that, unless a change is propagated through an authorized entry point, such as the
NSJSP Manager application, no changes should be made to an already running
application. The autoDeploy attribute does not have any effect on the Manager
application. This means that irrespective of the value of the autoDeploy attribute
the Manager application can deploy/undeploy applications.
The following scenarios illustrate the effect of the autoDeploy attribute:

Scenario 1: An application is deployed using a WAR file and the WAR file is
exploded to a directory (because the unpackWARs attribute is true). In this
case, if the autoDeploy is true and if the WAR file is accidentally removed the
entire context gets undeployed. If the autoDeploy is set to false, the
context still exists and the application is still available.

Scenario 2: An application is deployed as a directory and the web.xml (or any
WatchedResource) is accidentally modified. If autoDeploy is set to true,
the entire application will need to be redeployed with the modified web.xml. If
the modified web.xml has a configuration error (syntax error), the entire
application context will be unavailable. If autoDeploy is set to false, the
modified web.xml file will not harm the running application.

Scenario 3: An application contains several JSPs and one of the JSPs is
accidentally modified. In this case, irrespective of the value of the
autoDeploy attribute, the modified JSP is effective immediately. In this
scenario, the JSP becomes not marked as a WatchedResource. If it is
marked as a WatchedResource then the entire context is reloaded.
unpackWARs
Setting unpackWARs to true will explode WAR files in the Host's appBase
directory (usually the webapps directory). This will expose application contents
such as JSPs, and properties files. Although you can prevent modifications to
these files from affecting the running application by setting autoDeploy to false,
changes will affect the application upon restart. This represents a potential threat.
Note. Although the application is still available, if there are any requests needing
any of the just deleted resources, those requests will fail.