Preparing for application installation settings: WAS v5.1

Preparing for application installation settings

To install a new application EAR, JAR or WAR file, go to..
administrative console | Applications | Install | New Application.

On the "Preparing for application installation" page, choose...

Path Specifies the fully qualified path to the .ear, .jar, or .war file for the enterprise application.
Use Local path if the browser and application files are on the same machine (whether or not the server is on that machine, too).
Use Server path if the application file resides on any node in the current cell context. Only .ear, .jar, or .war files are shown during the browsing.
During application installation, application files are typically uploaded from a client machine running the browser to the server machine running the administrative console, where they are deployed. In such cases, the Web browser running the administrative console is used to select EAR, WAR, or JAR modules to upload to the server machine.
In some cases, however, the application files reside on the file system of any of the nodes in a cell. To have the appserver install these files, use the Server path option.
You can also use this option to specify an application file already residing on the machine running the appserver. For example, the field value on Windows NT might be C:\WebSphere\AppServer\installableApps\test.ear. If you are installing a stand-alone WAR module, then you also must specify the context root.

Context Root Specifies the context root of the web application (.war) (WAR).
This field is used only to install a stand-alone WAR file. The context root is combined with the defined servlet mapping (from the WAR file) to compose the full URL that users type to access the servlet. For example, if the context root is /gettingstarted and the servlet mapping is MySession, then the URL is http://host:port/gettingstarted/MySession.

Generate Default Bindings Specifies whether to generate default bindings. If you place a check mark in the check box, then any incomplete bindings in the application are filled in with default values. Existing bindings are not altered.
By choosing this option, you can directly jump to the Summary step and install the application if none of the steps have a red asterisk (*) next to them. A red asterisk denotes that the step has incomplete data and requires a valid value. On the Summary panel, verify the cell, node and server on which the application is installed.
Bindings are generated as follows...

EJB JNDI names are generated of the form prefix/ejb-name. The default prefix is ejb, but can be overridden. The ejb-name is as specified in the deployment descriptors <ejb-name> tag.
EJB references are bound as follows: If an <ejb-link> is found, it is honored. Otherwise, if a unique enterprise bean is found with a matching home (or local home) interface as the referenced bean, the reference is resolved automatically.
Resource reference bindings are derived from the <res-ref-name> tag. Note that this action assumes that the java:comp/env name is the same as the resource global JNDI name.
Connection factory bindings (for EJB 2.0 JAR files) are generated based on the JNDI name and authorization information provided. This action results in default connection factory settings for each EJB 2.0 JAR file in the application being installed. No bean-level connection factory bindings are generated.
Data source bindings (for EJB 1.1 JAR files) are generated based on the JNDI name, data source user name password options. This results in default data source settings for each EJB JAR file. No bean-level data source bindings are generated.
Message-driven bean (MDB) listener ports are derived from the MDB <ejb-name> tag with the string Port appended.
For .war files, the virtual host is set as default_host unless otherwise specified.

The default strategy suffices for most applications or at least for most bindings in most applications. However, it does not work if...

You want to explicitly control the global JNDI names of one or more EJB files.
You need tighter control of data source bindings for CMPs. That is, you have multiple data sources and need more than one global data source.
You must map resource references to global resource JNDI names that are different from the java:comp/env name.

In such cases, you can alter the behavior with an XML document (a custom strategy). Use the Specific bindings file field to specify a custom strategy and see the field's help for examples.

Prefixes Specifies prefixes to use for generated JNDI names.

Override Specifies whether to override existing bindings.
If this check box is checked, the existing bindings are overridden by the generated ones.

EJB 1.1 CMP bindings Specifies the default data source JNDI name.
If the Default Bindings for EJB 1.1 CMPs radio button is selected, specify the JNDI name for the default data source to be used with the CMP 1.1 beans. Also specify the user ID and password for this default data source.

Connection Factory Bindings Specifies the default data source JNDI name.
If the Default connection factory bindings radio button is selected, specify the JNDI name for the default data source to be used with the bindings. Also specify the resource authorization.

Virtual Host Specifies the virtual host for WAR modules.

Specific bindings file Specifies a bindings file that overrides the default binding.
Alter the behavior of the default binding with an XML document (aka custom strategy). Custom strategies extend the default strategy so you only need to customize those areas where the default strategy is insufficient. That is, you only need to describe how you want to change the bindings generated by the default strategy; you do not have to define bindings for the entire application.
Brief examples of how to override various aspects of the default bindings generator follow...
Controlling an EJB JNDI name
<?xml version="1.0"?> <!DOCTYPE dfltbndngs SYSTEM "dfltbndngs.dtd"> <dfltbndngs> <module-bindings> <ejb-jar-binding> <jar-name>helloEjb.jar</jar-name>  <ejb-bindings> <ejb-binding> <ejb-name>HelloEjb</ejb-name>  <jndi-name>com/acme/ejb/HelloHome</jndi-name> </ejb-binding> </ejb-bindings> </ejb-jar-binding> </module-bindings> </dfltbndngs>

Setting the connection factory binding for an EJB JAR file
<!DOCTYPE dfltbndngs SYSTEM "dfltbndngs.dtd"> <dfltbndngs> <module-bindings> <ejb-jar-binding> <jar-name>yourEjb20.jar</jar-name> <connection-factory> <jndi-name>eis/jdbc/YourData_CMP</jndi-name> <res-auth>Container</res-auth> </connection-factory> </ejb-jar-binding> </module-bindings> </dfltbndngs>

Setting the connection factory binding for an EJB file
<?xml version="1.0"> <!DOCTYPE dfltbndngs SYSTEM "dfltbndngs.dtd"> <dfltbndngs> <module-bindings> <ejb-jar-binding> <jar-name>yourEjb20.jar</jar-name> <ejb-bindings> <ejb-binding> <ejb-name>YourCmp20</ejb-name>  <connection-factory> <jndi-name>eis/jdbc/YourData_CMP</jndi-name> <res-auth>PerConnFact</res-auth> </connection-factory> </ejb-binding> </ejb-bindings> </ejb-jar-binding> </module-bindings> </dfltbndngs>

Overriding a Resource Ref Binding from a WAR, EJB JAR file, or J2EE client JAR file
Example code for overriding a Resource Ref Binding from a WAR file follows. Use similar code to override a Resource Ref Binding from an enterprise bean (EJB) JAR file or a J2EE client JAR file.
<?xml version="1.0"?> <!DOCTYPE dfltbndngs SYSTEM "dfltbndngs.dtd"> <dfltbndngs> <module-bindings> <war-binding> <jar-name>hello.war</jar-name> <resource-ref-bindings> <resource-ref-binding>  <resource-ref-name>jdbc/MyDataSrc</resource-ref-name> <jndi-name>war/override/dataSource</jndi-name> </resource-ref-binding> </resource-ref-bindings> </war-binding> </module-bindings> </dfltbndngs>

Overriding MDB JMS listener ports
<?xml version="1.0"?> <!DOCTYPE dfltbndngs SYSTEM "dfltbndngs.dtd"> <dfltbndngs> <module-bindings> <ejb-jar-binding> <jar-name>YourEjbJar.jar</jar-name> <ejb-bindings> <ejb-binding> <ejb-name>YourMDB</ejb-name> <listener-port>yourMdbListPort</listener-port> </ejb-binding> </ejb-bindings> </ejb-jar-binding> </module-bindings> </dfltbndngs>

See Also
Enterprise applications
Install a new application
Administrative console buttons

Path	Specifies the fully qualified path to the .ear, .jar, or .war file for the enterprise application. Use Local path if the browser and application files are on the same machine (whether or not the server is on that machine, too). Use Server path if the application file resides on any node in the current cell context. Only .ear, .jar, or .war files are shown during the browsing. During application installation, application files are typically uploaded from a client machine running the browser to the server machine running the administrative console, where they are deployed. In such cases, the Web browser running the administrative console is used to select EAR, WAR, or JAR modules to upload to the server machine. In some cases, however, the application files reside on the file system of any of the nodes in a cell. To have the appserver install these files, use the Server path option. You can also use this option to specify an application file already residing on the machine running the appserver. For example, the field value on Windows NT might be C:\WebSphere\AppServer\installableApps\test.ear. If you are installing a stand-alone WAR module, then you also must specify the context root.
Context Root	Specifies the context root of the web application (.war) (WAR). This field is used only to install a stand-alone WAR file. The context root is combined with the defined servlet mapping (from the WAR file) to compose the full URL that users type to access the servlet. For example, if the context root is /gettingstarted and the servlet mapping is MySession, then the URL is http://host:port/gettingstarted/MySession.
Generate Default Bindings	Specifies whether to generate default bindings. If you place a check mark in the check box, then any incomplete bindings in the application are filled in with default values. Existing bindings are not altered. By choosing this option, you can directly jump to the Summary step and install the application if none of the steps have a red asterisk (*) next to them. A red asterisk denotes that the step has incomplete data and requires a valid value. On the Summary panel, verify the cell, node and server on which the application is installed. Bindings are generated as follows... EJB JNDI names are generated of the form prefix/ejb-name. The default prefix is ejb, but can be overridden. The ejb-name is as specified in the deployment descriptors <ejb-name> tag. EJB references are bound as follows: If an <ejb-link> is found, it is honored. Otherwise, if a unique enterprise bean is found with a matching home (or local home) interface as the referenced bean, the reference is resolved automatically. Resource reference bindings are derived from the <res-ref-name> tag. Note that this action assumes that the java:comp/env name is the same as the resource global JNDI name. Connection factory bindings (for EJB 2.0 JAR files) are generated based on the JNDI name and authorization information provided. This action results in default connection factory settings for each EJB 2.0 JAR file in the application being installed. No bean-level connection factory bindings are generated. Data source bindings (for EJB 1.1 JAR files) are generated based on the JNDI name, data source user name password options. This results in default data source settings for each EJB JAR file. No bean-level data source bindings are generated. Message-driven bean (MDB) listener ports are derived from the MDB <ejb-name> tag with the string Port appended. For .war files, the virtual host is set as default_host unless otherwise specified. The default strategy suffices for most applications or at least for most bindings in most applications. However, it does not work if... You want to explicitly control the global JNDI names of one or more EJB files. You need tighter control of data source bindings for CMPs. That is, you have multiple data sources and need more than one global data source. You must map resource references to global resource JNDI names that are different from the java:comp/env name. In such cases, you can alter the behavior with an XML document (a custom strategy). Use the Specific bindings file field to specify a custom strategy and see the field's help for examples.
Prefixes	Specifies prefixes to use for generated JNDI names.
Override	Specifies whether to override existing bindings. If this check box is checked, the existing bindings are overridden by the generated ones.
EJB 1.1 CMP bindings	Specifies the default data source JNDI name. If the Default Bindings for EJB 1.1 CMPs radio button is selected, specify the JNDI name for the default data source to be used with the CMP 1.1 beans. Also specify the user ID and password for this default data source.
Connection Factory Bindings	Specifies the default data source JNDI name. If the Default connection factory bindings radio button is selected, specify the JNDI name for the default data source to be used with the bindings. Also specify the resource authorization.
Virtual Host	Specifies the virtual host for WAR modules.
Specific bindings file	Specifies a bindings file that overrides the default binding. Alter the behavior of the default binding with an XML document (aka custom strategy). Custom strategies extend the default strategy so you only need to customize those areas where the default strategy is insufficient. That is, you only need to describe how you want to change the bindings generated by the default strategy; you do not have to define bindings for the entire application. Brief examples of how to override various aspects of the default bindings generator follow... Controlling an EJB JNDI name <?xml version="1.0"?> <!DOCTYPE dfltbndngs SYSTEM "dfltbndngs.dtd"> <dfltbndngs> <module-bindings> <ejb-jar-binding> <jar-name>helloEjb.jar</jar-name> <!-- this name must match the module name in the .ear file --> <ejb-bindings> <ejb-binding> <ejb-name>HelloEjb</ejb-name> <!-- this must match the <ejb-name> entry in the EJB jar DD --> <jndi-name>com/acme/ejb/HelloHome</jndi-name> </ejb-binding> </ejb-bindings> </ejb-jar-binding> </module-bindings> </dfltbndngs> Setting the connection factory binding for an EJB JAR file <!DOCTYPE dfltbndngs SYSTEM "dfltbndngs.dtd"> <dfltbndngs> <module-bindings> <ejb-jar-binding> <jar-name>yourEjb20.jar</jar-name> <connection-factory> <jndi-name>eis/jdbc/YourData_CMP</jndi-name> <res-auth>Container</res-auth> </connection-factory> </ejb-jar-binding> </module-bindings> </dfltbndngs> Setting the connection factory binding for an EJB file <?xml version="1.0"> <!DOCTYPE dfltbndngs SYSTEM "dfltbndngs.dtd"> <dfltbndngs> <module-bindings> <ejb-jar-binding> <jar-name>yourEjb20.jar</jar-name> <ejb-bindings> <ejb-binding> <ejb-name>YourCmp20</ejb-name> <!-- this matches the ejb-name tag in the DD --> <connection-factory> <jndi-name>eis/jdbc/YourData_CMP</jndi-name> <res-auth>PerConnFact</res-auth> </connection-factory> </ejb-binding> </ejb-bindings> </ejb-jar-binding> </module-bindings> </dfltbndngs> Overriding a Resource Ref Binding from a WAR, EJB JAR file, or J2EE client JAR file Example code for overriding a Resource Ref Binding from a WAR file follows. Use similar code to override a Resource Ref Binding from an enterprise bean (EJB) JAR file or a J2EE client JAR file. <?xml version="1.0"?> <!DOCTYPE dfltbndngs SYSTEM "dfltbndngs.dtd"> <dfltbndngs> <module-bindings> <war-binding> <jar-name>hello.war</jar-name> <resource-ref-bindings> <resource-ref-binding> <!-- the following must match the resource-ref in the DD --> <resource-ref-name>jdbc/MyDataSrc</resource-ref-name> <jndi-name>war/override/dataSource</jndi-name> </resource-ref-binding> </resource-ref-bindings> </war-binding> </module-bindings> </dfltbndngs> Overriding MDB JMS listener ports <?xml version="1.0"?> <!DOCTYPE dfltbndngs SYSTEM "dfltbndngs.dtd"> <dfltbndngs> <module-bindings> <ejb-jar-binding> <jar-name>YourEjbJar.jar</jar-name> <ejb-bindings> <ejb-binding> <ejb-name>YourMDB</ejb-name> <listener-port>yourMdbListPort</listener-port> </ejb-binding> </ejb-bindings> </ejb-jar-binding> </module-bindings> </dfltbndngs>