Select installation options settings


 

+

Search Tips   |   Advanced Search

 

To specify options for the installation of a Java EE application onto a WAS deployment target. Default values for the options are used if we do not specify a value. After application installation, we can specify values for many of these options from an enterprise application settings page.

To view this admin console page, click...

Applications | New application | New Enterprise Application

...and then specify values as needed for the application on the Preparing for application installation pages.

The Select installation options page is the same for the application installation and update wizards.

Precompile JSPs

Specify whether to precompile JSPs as a part of installation. The default is not to precompile JSPs.

For this option, install only onto a V6.1 or later deployment target.

If we select Precompile JSPs and try installing the application onto an earlier deployment target such as Version 5.x, the installation is rejected. We can deploy applications to only those deployment targets that have same version as WAS ND. If applications are targeted to servers that have an earlier version than WAS ND, then we cannot deploy to those targets.

Data type Boolean
Default false

Directory to install application

Directory to which the EAR file will be installed.

By default, the EAR file is installed in...

$PROFILE_ROOT/installedApps/cell_name/application_name.ear

Set options include the following:

  • Do not specify a value and leave the field empty.

    The default value is...

    ${APP_INSTALL_ROOT}/cell_name

    A directory having the EAR file name of the application being installed is appended. Thus, if we do not specify a directory, the EAR file is installed in...

    $PROFILE_ROOT/installedApps/cell_name/application_name.ear

  • Specify a directory.

    If we specify a directory for Directory to install application, the application is installed in...

    specified_path/application_name.ear

    A directory having the EAR file name of the application being installed is appended to the path specified for Directory to install application. For example, if we are installing Clock.ear and specify C:/myapps on Windows machines, the application is installed in...

    myapps/Clock.

  • Specify ${APP_INSTALL_ROOT}/${CELL} for the initial installation of the application.

    If we 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 specify the ${CELL} variable. Specifying the ${CELL} variable ensures that the destination directory has the current cell name, and not the original 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 dmgr 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...

    ${APP_INSTALL_ROOT}/network_cell_name

    ...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 the application has been exported and we are installing the exported EAR file in a different cell or location, specify...

    ${APP_INSTALL_ROOT}/cell_name/application_name.ear

    ...if we did not specify...

    ${APP_INSTALL_ROOT}/${CELL}

    ...for the initial installation.

    The exported EAR file is an enhanced EAR file that has the application and its deployment configuration. The deployment configuration retains the value for Directory to install application that was used for the previous installation of the application. Unless you specify a different value for Directory to install application for this installation, the enhanced EAR file will be installed to the same directory as for the previous installation.

    If we did not specify the ${CELL} variable during the initial installation, the deployment configuration uses the cell name of the initial installation in the destination directory. If installing on a different cell, specify...

    ${APP_INSTALL_ROOT}/cell_name/application_name.ear

    If we do not designate the current cell name, cell_name will be the original cell name even though we are installing the enhanced EAR file on a cell that has a different name.

  • Specify an absolute path or a use pathmap variable.

    We can specify an absolute path or use a pathmap variable such as ${MY_APPS}. 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 WAS variable ${CELL} that denotes the current cell name can also be in the pathmap variable; for example, ${MY_APP}/${CELL}. We can define WAS 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

Distribute application

Whether WAS 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 we disable this option, then verify the application binaries are expanded appropriately in the destination directories of all nodes where the application runs.

Avoid trouble: If we 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

Use binary configuration

Whether the appserver uses the binding, extensions, and deployment descriptors located with the application deployment document, deployment.xml (default), or those located in the EAR file. Select this setting for applications installed on V6.0 or later deployment targets only. This setting is not valid for applications installed on 5.x deployment targets.

The default (false) is not to use the binding, extensions, and deployment descriptors located in deployment.xml. To use the binding, extensions, and deployment descriptors located in the EAR file, enable this setting (true).

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

Deploy enterprise beans

Whether the EJBDeploy tool runs during application installation. The tool generates code needed to run EJB files. You must enable this setting in the following situations:

  • The EAR file was assembled using an assembly tool such as Rational Application Developer and the EJBDeploy tool was not run during assembly.

  • The EAR file was not assembled using an assembly tool such as Rational Application Developer.

  • The EAR file was assembled using versions of the Application Assembly Tool (AAT) previous to V5.0.

The EJB deployment tool runs during installation of EJB 1.x or 2.x modules. The EJB deployment tool does not run during installation of EJB 3.0 modules.

For this option, install only onto a V6.1 or later deployment target.

If we select Deploy enterprise beans and try installing the application onto an earlier deployment target such as V6.0, the installation is rejected. We can deploy applications to only those targets that have same WebSphere version as WAS ND. If applications are targeted to servers that have an earlier version than WAS ND, then we cannot deploy to those targets.

If we select Deploy enterprise beans and specify a database type on the Provide options to perform the EJB Deploy page, 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 page.

Enable this setting might cause the installation program to run for several minutes.

Data type Boolean
Default true (false for EJB 3.0 modules)

Application name

Logical name for the application. An application name must be unique within a cell and cannot contain an unsupported character.

An application name cannot begin with a period (.), cannot contain leading or trailing spaces, and cannot contain any of the following characters:

Unsupported 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 ]]>

This Application name field is the same as the Name setting on an Enterprise application settings page.

Data type String

Create MBeans for resources

Whether to create MBeans for resources such as servlets or JSPs 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

Override class reloading settings for Web and EJB modules

Whether WAS 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 field is the same as the Override class reloading settings for Web and EJB modules setting on an Class loading and update detection page.

Data type Boolean
Default false

Reload interval in seconds

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

...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 a Class loading and update detection page.

Data type Integer
Units Seconds
Default 3

Deploy Web services

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 V6.1 or later deployment target.

If we select Deploy Web services and try installing the application onto an earlier deployment target such as V5.x, the installation is rejected. We can deploy applications to only those targets that have same version as WAS ND. If applications are targeted to servers that have an earlier version than WAS ND, then we cannot deploy to those targets.

Data type Boolean
Default false

Validate input off/warn/fail

Whether WAS 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

Process embedded configuration

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.

This setting affects installation of enhanced EAR files. An enhanced EAR file results when you export an installed application.

When false, an enhanced EAR file is installed like any other application and WAS ignores its embedded configuration.

If we exported the application from a cell other than the current cell and did not specify the $(CELL) variable for Directory to install application when first installing the application, deselect this setting (false) to expand the enhanced EAR file in the $PROFILE_ROOT/installedApps/current_cell_name directory. Otherwise, if this setting is selected (true), the enhanced EAR file is expanded in the $PROFILE_ROOT/installedApps/original_cell_name directory, where original_cell_name is the cell on which the application was first installed. If we specified the $(CELL) variable for Directory to install application when you first installed the application, installation expands the enhanced EAR file in the $PROFILE_ROOT/installedApps/current_cell_name directory.

Data type Boolean
Default false (deselected)

File permission

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.

We can specify file permissions in the text field. We can also set some of the commonly used file permissions by selecting them from the multiple-selection list. List selections overwrite file permissions set in the text field.

We can set one or more of the following file permission strings in the list. Selecting multiple options combines the file permission strings.

Multiple-selection 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 multiple-selection list to specify file permissions, we 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 JSPs), 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 WAS ND 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.

Best practice: 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:bprac

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:

  • MyWarModule.war does not match any of the URIs

  • .*MyWarModule.war.* matches all URIs

  • .*MyWarModule.war$ matches only URI 1

  • .*\\.jsp=755 matches only URI 2

  • .*META-INF.* matches URIs 3 and 6

  • .*MyWarModule.war/.*/.*\.class matches URIs 4 and 5

If we 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 we have the following file and directory structure: 

/opt/WebSphere/profiles/AppSrv01/installedApps/MyCell/MyApp.ear/MyWarModule.war/MyJsp.jsp
and specify the following file pattern string: 

.*MyApp.ear$=755#.*\.jsp=644
The file pattern matching results are:

  • Directory MyApp.ear is set to 755

  • Directory MyWarModule.war is set to 755

  • Directory MyWarModule.war is set to 755

Best practice: Regardless of the operation system, always use a forward slash (/) as a file path separator in file patterns

(Windows) We cannot unset read permission on a file on Windows platforms. With POSIX style permission bits, the bit for denoting readable on a file is 4, writable is 2, and executable is 1. Thus, permission of a file on a Windows platform is either 5 or 7. Also, in POSIX style there are user, group and world permissions. We can only set the user permission for a file on Windows platforms. The group and world permission bits are ignored.

Access permissions specified here are at the application level. We 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

Application build identifier

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

Allow dispatching includes to remote resources

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 false

Allow servicing includes from remote resources

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 false

Business-level application name

Whether WAS creates a new business-level application with the enterprise application that we are installing or makes the enterprise application a composition unit of an existing business-level application.

The default is to create a new business-level application with a setting value of WebSphere:blaname=Anyasset,blaedition=BASE. When you select to create a new business-level application from the drop-down list, WAS creates a business-level application that has the same name as the enterprise application.

To add the enterprise application to an existing business-level application, select an existing business-level application from the drop-down list. The product makes the enterprise application a composition unit of the existing business-level application.

Data type String
Default Create a new business-level application that has the same name as the enterprise application that we are installing.

WebSphere:blaname=Anyasset,blaedition=BASE

Asynchronous request dispatch type

Whether Web modules can dispatch requests concurrently on separate threads and, if so, whether the server or client dispatches the requests. Concurrent dispatching can improve servlet response time.

If operations are dependant on each other, do not enable asynchronous request dispatching. Select Disabled. Concurrent dispatching might result in errors when operations are dependant.

Select Server side to enable the server to dispatch requests concurrently. Select Client side to enable the client to dispatch requests concurrently.

Data type String
Default Disabled

Allow EJB reference targets to resolve automatically

Whether WAS assigns default JNDI values for or automatically resolves incomplete EJB reference targets.

Select this option to enable EJB reference targets to resolve automatically if the references are from EJB 2.1 or earlier modules or from Web 2.3 or earlier modules. If we enable this option, the runtime container provides a default value or automatically resolves the EJB reference for any EJB reference that does not have a binding.

If we selected Generate default bindings on the Preparing for application installation page, then you do not need to select this option. WAS ND v7.0 generates default values.

If we select Allow EJB reference targets to resolve automatically, all modules in the application must share one deployment target. If we select this option and all of the application modules do not share a common server, after you click Finish on the Summary page, WAS ND displays a warning message and does not install the application. You must deselect this setting before you click Finish to install the application.

Data type Boolean
Default false




Related concepts

Enterprise (Java EE) applications
Installable enterprise module versions
Assembly tools

 

Related tasks

Install enterprise application files with the console
Exporting enterprise apps

 

Related

Preparing for application installation settings
Enterprise application settings
Application binary settings
Startup behavior settings
Class loading and update detection settings
Remote dispatcher property settings
Object names: What the name string cannot contain
wsdeploy