Use this panel to specify options for the installation of an application onto a WebSphere Application Server deployment target. Default values for the options are used if you do not specify a value. After application installation, you can specify values for many of these options from an enterprise application settings page.
To view this administrative console panel, click Applications > Install New Application and then specify values as needed for your application on the Preparing for application installation pages.
The Select installation options panel is the same for the application installation and update wizards.
Specify whether to precompile JavaServer Pages files as a part of installation. The default is not to precompile JSP files.
For this option, install only onto a 6.1 deployment target.
If you select Precompile JavaServer Pages files and try installing your application onto an earlier deployment target such as version 5.x, the installation is rejected. You can deploy applications to only those targets that have same WebSphere version as the product. If applications are targeted to servers that have an earlier version than the product, then you cannot deploy to those targets.
Data type | Boolean |
Default | false |
Specifies the directory to which the enterprise application (EAR) file will be installed.
The default value is the value of APP_INSTALL_ROOT/cell_name, where the APP_INSTALL_ROOT variable is app_server_root/installedApps; for example, app_server_root/installedApps/cell_name.
If an installation directory is not specified when an application is installed on a single-server configuration, the application is installed in APP_INSTALL_ROOT/cell_name. When the server is made a part of a multiple-server configuration (using the addNode utility), the cell name of the new configuration becomes the cell name of the deployment manager node. If the -includeapps option is used for the addNode utility, then the applications that are installed prior to the addNode operation still use the installation directory APP_INSTALL_ROOT/cell_name. However, an application that is installed after the server is added to the network configuration uses the default installation directory APP_INSTALL_ROOT/network_cell_name. To move the application to the APP_INSTALL_ROOT/network_cell_name location upon running the addNode operation, explicitly specify the installation directory as ${APP_INSTALL_ROOT}/${CELL) during installation. In such a case, the application files can always be found under APP_INSTALL_ROOT/current_cell_name.
If you intend to export the application from one cell and later install the exported application on a different cell, specify the $(CELL) variable for the initial installation of the application. For example, specify ${APP_INSTALL_ROOT}/${CELL) for this setting. Exporting the application creates an enhanced EAR file that has the application and its deployment configuration. The deployment configuration retains the cell name of the initial installation in the destination directory unless you specify the $(CELL) variable. Specifying the $(CELL) variable ensures that the destination directory has the current cell name, and not the original cell name.
You can specify an absolute path or use a pathmap variable such as ${MY_APPS}. You can use a pathmap variable in any installation.
A pathmap variable is particularly needed when installing an application on a cluster with members on heterogeneous nodes because, in such cases, there might not be a single way to specify an absolute path. A WebSphere Application Server variable ${CELL} that denotes the current cell name can also be in the pathmap variable; for example, ${MY_APP}/${CELL}. You can define WebSphere Application Server variables on the WebSphere Variables console page, accessed by clicking Environment > WebSphere Variables.
This Directory to install application field is the same as the Location (full path) setting on an Application binaries page.
Data type | String |
Units | Full path name |
Specifies whether the product expands application binaries in the installation location during installation and deletes application binaries during uninstallation. The default is to enable application distribution. Application binaries for installed applications are expanded to the directory specified.
On single-server products, the binaries are deleted when you uninstall and save changes to the configuration.
On multiple-server products, the binaries are deleted when you uninstall and save changes to the configuration and synchronize changes.
If you disable this option, then ensure that the application binaries are expanded appropriately in the destination directories of all nodes where the application runs.
If you disable this option and you do not copy and expand the application binaries to the nodes, a later saving of the configuration or manual synchronization does not move the application binaries to the nodes for you.
This Distribute application field is the same as the Enable binary distribution, expansion and cleanup post uninstallation setting on an Application binaries page.
Data type | Boolean |
Default | true |
Specifies whether the application server uses the binding, extensions, and deployment descriptors located with the application deployment document, the deployment.xml file (default), or those located in the enterprise application resource (EAR) file. Select this setting for applications installed on 6.x deployment targets only. This setting is not valid for applications installed on 5.x deployment targets.
This Use binary configuration field is the same as the Use configuration information in binary setting on an Application binaries page.
Data type | Boolean |
Default | false |
Specifies whether the EJBDeploy tool runs during application installation. The tool generates code needed to run enterprise bean (EJB) files. You must enable this setting in the following situations:
For this option, install only onto a 6.1 deployment target.
If you select Deploy enterprise beans and try installing your application onto an earlier deployment target such as version 5.x, the installation is rejected. You can deploy applications to only those targets that have same WebSphere version as the product. If applications are targeted to servers that have an earlier version than the product, then you cannot deploy to those targets.
Also, if you select Deploy enterprise beans and specify a database type on the Provide options to perform the EJB Deploy panel, previously defined backend IDs for all of the EJB modules are overwritten by the chosen database type. To enable backend IDs for individual EJB modules, set the database type to "" (null) on the Provide options to perform the EJB Deploy panel.
The default database type is DB2UDB_V81.
Enabling this setting might cause the installation program to run for several minutes.
Data type | Boolean |
Default | true |
Specifies a logical name for the application. An application name must be unique within a cell and cannot contain an unallowed character.
An application name cannot begin with a period (.), cannot contain leading or trailing spaces, and cannot contain any of the following characters:
Unallowed characters | ||
---|---|---|
⁄ forward slash | $ dollar sign | ' single quote mark |
\ backslash | = equal sign | " double quote mark |
* asterisk | % percent sign | | vertical bar |
, comma | + plus sign | < left angle bracket |
: colon | @ at sign | > right angle bracket |
; semi-colon | # hash mark | & ampersand (and sign) |
? question mark | ]]> No specific name exists for this character combination |
This Application name field is the same as the Name setting on an Enterprise application settings page.
Data type | String |
Specifies whether to create MBeans for resources such as servlets or JSP files within an application when the application starts. The default is to create MBeans.
This field is the same as the Create MBeans for resources setting on a Startup behavior page.
Data type | Boolean |
Default | true |
Specifies whether the WebSphere Application Server run time detects changes to application classes when the application is running. If this setting is enabled and if application classes are changed, then the application is stopped and restarted to reload updated classes.
The default is not to enable class reloading.
This Enable class reloading field is the same as the Reload classes when application files are updated setting on an Class loading and update detection page.
Data type | Boolean |
Default | false |
Specifies the number of seconds to scan the application's file system for updated files. The default is the value of the reloading interval attribute in the IBM extension (META-INF/ibm-application-ext.xmi) file of the EAR file.
The reloading interval attribute takes effect only if class reloading is enabled.
To enable reloading, specify a value greater than zero (for example, 1 to 2147483647). To disable reloading, specify zero (0). The range is from 0 to 2147483647.
This Reload interval in seconds field is the same as the Polling interval for updated files setting on an Class loading and update detection page.
Data type | Integer |
Units | Seconds |
Default | 3 |
Specifies whether the Web services deploy tool wsdeploy runs during application installation.
The tool generates code needed to run applications using Web services. The default is not to run the wsdeploy tool. You must enable this setting if the EAR file contains modules using Web services and has not previously had the wsdeploy tool run on it, either from the Deploy menu choice of an assembly tool or from a command line.
For this option, install only onto a 6.1 deployment target.
If you select Deploy Web services and try installing your application onto an earlier deployment target such as version 5.x, the installation is rejected. You can deploy applications to only those targets that have same WebSphere version as the product. If applications are targeted to servers that have an earlier version than the product, then you cannot deploy to those targets.
Data type | Boolean |
Default | false |
Specifies whether WebSphere Application Server examines the application references specified during application installation or updating and, if validation is enabled, warns you of incorrect references or fails the operation.
An application typically refers to resources using data sources for container managed persistence (CMP) beans or using resource references or resource environment references defined in deployment descriptors. The validation checks whether the resource referred to by the application is defined in the scope of the deployment target of that application.
Select off for no resource validation, warn for warning messages about incorrect resource references, or fail to stop operations that fail as a result of incorrect resource references.
This Validate input off/warn/fail field is the same as the Application reference validation setting on an Enterprise Application settings page.
Data type | String |
Default | warn |
Specifies whether the embedded configuration should be processed. An embedded configuration consists of files such as resource.xml and variables.xml. When selected or true, the embedded configuration is loaded to the application scope from the .ear file. If the .ear file does not contain an embedded configuration, the default is false. If the .ear file contains an embedded configuration, the default is true.
Data type | Boolean |
Default | false |
Specifies access permissions for application binaries for installed applications that are expanded to the directory specified.
The Distribute application option must be enabled to specify file permissions.
You can specify file permissions in the text field. You can also set some of the commonly used file permissions by selecting them from the drop-down list. Drop-down list selections overwrite file permissions set in the text field.
You can set one or more of the following file permission strings in the drop-down list. Selecting multiple options combines the file permission strings.
Drop-down list option | File permission string set |
---|---|
Allow all files to be read but not written to | .*=755 |
Allow executables to execute | .*\.dll=755#.*\.so=755#.*\.a=755#.*\.sl=755 |
Allow HTML and image files to be read by everyone | .*\.htm=755#.*\.html=755#.*\.gif=755#.*\.jpg=755 |
Instead of using the drop-down list to specify file permissions, you can specify a file permission string in the text field. File permissions use a string that has the following format:
file_name_pattern=permission#file_name_pattern=permission
where file_name_pattern is a regular expression file name filter (for example, .*\\.jsp for all JSP files), permission provides the file access control lists (ACLs), and # is the separator between multiple entries of file_name_pattern and permission. If # is a character in a file_name_pattern string, use \# instead.
If multiple file name patterns and file permissions in the string match a uniform resource identifier (URI) within the application, then the product uses the most stringent applicable file permission for the file. For example, if the file permission string is .*\\.jsp=775#a.*\\.jsp=754, then the abc.jsp file has file permission 754.
Using regular expressions for file matching pattern compares an entire string URI against the specified file permission pattern. You must provide more precise matching patterns using regular expressions as defined by Java programming API. For example, suppose the following directory and file URIs are processed during a file permission operation:
1 | /opt/WebSphere/profiles/AppSrv01/installedApps/MyCell/MyApp.ear/MyWarModule.war |
2 | /opt/WebSphere/profiles/AppSrv01/installedApps/MyCell/MyApp.ear/MyWarModule.war/MyJsp.jsp |
3 | /opt/WebSphere/profiles/AppSrv01/installedApps/MyCell/MyApp.ear/MyWarModule.war/META-INF/MANIFEST.MF |
4 | /opt/WebSphere/profiles/AppSrv01/installedApps/MyCell/MyApp.ear/MyWarModule.war/WEB-INF/classes/MyClass.class |
5 | /opt/WebSphere/profiles/AppSrv01/installedApps/MyCell/MyApp.ear/MyWarModule.war/mydir/MyClass2.class |
6 | /opt/WebSphere/profiles/AppSrv01/installedApps/MyCell/MyApp.ear/MyWarModule.war/META-INF |
The file pattern matching results are:
If you specify a directory name pattern for File permissions, then the directory permission is set based on the value specified. Otherwise, the File permissions value set on the directory is the same as its parent. For example, suppose you have the following file and directory structure:
/opt/WebSphere/profiles/AppSrv01/installedApps/MyCell/MyApp.ear/MyWarModule.war/MyJsp.jspand you specify the following file pattern string:
.*MyApp.ear$=755#.*\.jsp=644The file pattern matching results are:
Regardless of the operation system, always use a forward slash (/) as a file path separator in file patterns.
Access permissions specified here are at the application level. You can also specify access permissions for application binaries in the node level configuration. The node level file permissions specify the maximum (most lenient) permissions that can be given to application binaries. Access permissions specified here at application level can only be the same as or more restrictive than those specified at the node level.
This setting is the same as the File permissions field on the Application binaries page.
Data type | String |
Specifies an uneditable string that identifies the build version of the application.
This Application build identifier field is the same as the Application build level field on the Application binaries page.
Data type | String |
Specifies whether an application can dispatch includes to resources across Web modules that are in different Java virtual machines in a managed node environment through the standard request dispatcher mechanism.
This field is the same as the Allow dispatching includes to remote resources field on the Remote request dispatch properties page.
Data type | Boolean |
Default | true |
Specifies whether an enterprise application can service an include request from an application.
This field is the same as the Allow servicing includes from remote resources field on the Remote request dispatch properties page.
Data type | Boolean |
Default | true |