Prepare for application installation binding settings

Prepare for application installation binding settings

Select whether to view all installation options and to change the existing bindings for the application or module during installation. We can choose to generate default bindings for any incomplete bindings in the application or module or to assign specific bindings during installation.

This page is the second Preparing for the application installation page.

From the admin console, click...
Applications > New application > New Enterprise Application, specify the path for the application or module to install> Next.

The console page might not display all of the binding options listed in this topic. The contents of the application or module that we are installing determines which options are displayed on the console page. Also, the Specify bindings to use option displays only when updating an installed application.

How do we want to install the application?

Specifies whether to show only installation options that require you to supply information or to show all installation options.

Option Description
Fast Path - Prompt only when additional information is required Displays only those options that require your attention, based on the contents of the application or module. Use the fast path to install the application more easily because we do not need to examine all available installation options.
Detailed - Show all installation options and parameters Display all available installation options.

Specify bindings to use

Specifies whether to merge bindings when you update applications or to use new or existing bindings.

This setting is shown only when you update an installed application, and not when we install a new application.

Option Description
Merge new and existing bindings The binding information from the updated application or modules is preferred over the corresponding binding information from the installed version. If any element of the binding is missing in the updated version, the corresponding element from the installed version is used. If both the installed and the updated application or module does not have a binding value, the default value is used. The product assigns a default value only if we select the Generate default bindings option.
Use new bindings The binding information in the updated application or module is used. The binding information from the updated version of the application or module is preferred over the corresponding binding information in the installed version. The binding information from the installed version of the application or module is ignored.
Use existing bindings The binding information from the installed version of the application or module is preferred over the corresponding binding information from the updated version. If any element of the binding information does not exist in the installed version, the element from the updated version is used. That is, bindings from the updated version of the application or module are ignored if a binding exists in the installed version. Otherwise, the new bindings are honored and not ignored.

Generate default bindings

Specifies whether to generate default bindings and mappings. To view this setting, expand Choose to generate default bindings and mappings. If we select Generate default bindings, then the product completes any incomplete bindings in the application with default values. The product does not change existing bindings.

After selecting Generate default bindings, we can advance directly to the Summary step and install the application if none of the steps have a red asterisk (*). A red asterisk denotes that the step has incomplete data and requires a valid value. On the Summary page, verify the cell, node, and server on which the application is installed.

For transitioning users: We do not need to specify JNDI values for EJB bean, local home, remote home, or business interfaces of EJB 3.0 or later modules. The product assigns container default values during run time. Similarly, for any EJB reference within an EJB 3.0, EJB 3.1, Web 2.4, or Web 2.5 module, we do not need to specify JNDI values because the product resolves the targets automatically during run time. Even when we select Generate default bindings, the product does not generate default values for those JNDI values but it does generate default values for other bindings such as virtual host.trns
If we select Generate default bindings, the product generates bindings as follows:

Enterprise bean (EJB) JNDI names are generated in 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 or in its corresponding annotation for EJB 3.0 or later modules. The product does not generate default values for enterprise beans in an EJB 3.0 or later module because the run time provides container default values.
EJB references are bound if an <ejb-link> is found. 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. The product does not generate default values for EJB reference in an EJB 3.0, EJB 3.1, Web 2.4, or Web 2.5 module because the run time provides container default values or automatically resolves the target references.
Resource reference bindings are derived from the <res-ref-name> tag or its corresponding annotation for Java EE 5 or 6 modules. 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 and EJB 2.1 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 and EJB 2.1 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 and password options. This action results in default data source settings for each JAR file. No bean-level data source bindings are generated.
For EJB 2.0 or later message-driven beans deployed as Java EE Connector Architecture (JCA) 1.5-compliant resources, the JNDI names corresponding to activationSpec instances are generated in the form eis/MDB_ejb-name. Message destination references are bound if a <message-destination-link> is found, then the JNDI name is set to ejs/message-destination-linkName. Otherwise, the JNDI name is set to eis/message-destination-refName.
For EJB 2.0 or later message-driven beans deployed against listener ports, the listener ports are derived from the message-driven bean <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, if we experience errors:

Control the global JNDI names of one or more EJB files.
Control data source bindings for container-managed persistence (CMP) beans. That is, we have multiple data sources and need more than one global data source.
Map resource references to global resource JNDI names that are different from the java:comp/env name.

In such cases, we can change the behavior with an XML document, which is a custom strategy. Use the Specific bindings file setting to specify a custom strategy and see the setting description in this help file for examples.

Override existing bindings

Specifies whether generated bindings are to replace existing bindings.

The default is to not override existing bindings. Select Override existing bindings to have generated bindings replace existing bindings.

Override existing bindings is similar to the -defaultbinding.force scripting option.

Use Java EE default bindings

Specifies whether generated bindings are to use the preconfigured default resources option for Java EE bindings.

The default is to not use preconfigured default resources for Java EE bindings. Select Use Java EE default bindings to have generated bindings be Java EE defaults.

Use Java EE default bindings is similar to the -defaultbinding.ee.defaults scripting option.

Specific bindings file

Specifies a bindings file that overrides the default binding.

Specific bindings file is similar to the -defaultbinding.strategy.file scripting option.

Change the behavior of the default binding with an XML document, which is a custom strategy. Custom strategies extend the default strategy so we only need to customize those areas where the default strategy is insufficient. Thus, we only need to describe how we want to change the bindings generated by the default strategy; we do not have to define bindings for the entire application.

Use the following examples to override various aspects of the default bindings generator:
Control 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>
Remember: Ensure that the setting for <ejb-name> matches the ejb-name entry in the EJB JAR deployment descriptor. Here the setting is <ejb-name>HelloEjb</ejb-name>.
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>
Restriction: Ensure that the setting for <ejb-name> matches the ejb-name tag in the deployment descriptor. Here the setting is <ejb-name>YourCmp20</ejb-name>.
Setting the message destination reference JNDI for a specific enterprise bean
This example shows an XML extract in a custom strategy file for setting message-destination-refs for a specific enterprise bean.
<?xml version="1.0">
 <!DOCTYPE dfltbndngs SYSTEM "dfltbndngs.dtd">
 <dfltbndngs>
  <module-bindings>
   <ejb-jar-binding>
    <jar-name>yourEjb21.jar</jar-name>
    <ejb-bindings>
     <ejb-binding>
      <ejb-name>YourSession21</ejb-name> 
      <message-destination-ref-bindings>
       <message-destination-ref-binding>
        <message-destination-ref-name>jdbc/MyDataSrc</message-destination-ref-name>
        <jndi-name>eis/somAO</jndi-name>
       </message-destination-ref-binding>
      </message-destination-ref-bindings>
     </ejb-binding>
    </ejb-bindings>
   </ejb-jar-binding>
  </module-bindings>
 </dfltbndngs>
Restriction: Ensure that the setting for <ejb-name> matches the ejb-name tag in the deployment descriptor. Here the setting is <ejb-name>YourSession21</ejb-name>. Also ensure that the setting for <message-destination-ref-name> matches the message-destination-ref-name tag in the deployment descriptor. Here the setting is <message-destination-ref-name>jdbc/MyDataSrc</message-destination-ref-name>.
Overriding a resource reference binding from a WAR, EJB JAR file, or Java EE client JAR file
This example shows code for overriding a resource reference binding from a WAR file. Use similar code to override a resource reference binding from an enterprise bean (EJB) JAR file or a Java EE 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>
Restriction: Ensure that the setting for <resource-ref-name> matches the resource-ref tag in the deployment descriptor. In the previous example, the setting is <resource-ref-name>jdbc/MyDataSrc</resource-ref-name>.
Overriding the JNDI name for a message-driven bean deployed as a JCA 1.5-compliant resource
This example shows an XML extract in a custom strategy file for overriding the Java Message Service (JMS) activationSpec JNDI name for an EJB 2.0 or later message-driven bean deployed as a JCA 1.5-compliant resource.
<?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>
        <activationspec-jndi-name>activationSpecJNDI</activationspec-jndi-name>
      </ejb-binding>
     </ejb-bindings>
   </ejb-jar-binding>
  </module-bindings>
 </dfltbndngs>
Overriding the JMS listener port name for an EJB 2.0, 2.1, or 3.0 message-driven bean
This example shows an XML extract in a custom strategy file for overriding the JMS listener port name for an EJB 2.0 or later message-driven bean deployed against a listener port.
<?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>
Overriding an EJB reference binding from an EJB JAR, WAR file, or EJB file
This example shows code for overriding an EJB reference binding from an EJB JAR file. Use similar code to override an EJB reference binding from a WAR file or an EJB file.
<?xml version="1.0"?>
<!DOCTYPE dfltbndngs SYSTEM "dfltbndngs.dtd">
<dfltbndngs>
  <module-bindings>
    <ejb-jar-binding>
      <jar-name>YourEjbJar.jar</jar-name>
      <ejb-ref-bindings>
        <ejb-ref-binding>
          <ejb-ref-name>YourEjb</ejb-ref-name>
          <jndi-name>YourEjb/JNDI</jndi-name>
        </ejb-ref-binding>
      </ejb-ref-bindings>
    </ejb-jar-binding>
  </module-bindings>
</dfltbndngs>
Specify unique prefix for beans

Specifies a string that the product applies to the beginning of generated enterprise bean JNDI names. The prefix must be unique within the cell or node.

The default is to not specify a unique prefix for beans.

Specify unique prefix for beans is similar to the scripting option -defaultbinding.ejbjndi.prefix.

Default bindings for EJB 1.1 CMP beans

Default data source JNDI name and other bindings for container-managed persistence (CMP) 1.1 beans.

The default is to not use default bindings for EJB 1.1 CMP beans.

If we select Default bindings for EJB 1.1 CMP beans, specify the JNDI name for the default data source to be used with the CMP 1.1 beans. Also specify the user name and password for this default data source.

Default bindings for EJB 1.1 CMP beans is similar to the scripting option -defaultbinding.datasource.jndi.

Default connection factory bindings

Default connection factory JNDI name.

The default is to not use default connection factory bindings. Select Default connection factory bindings to specify bindings for connection factories.

If we select Default connection factory bindings, specify the JNDI name for the default connection factory to be used. Also specify whether the resource authorization is for the application or container-wide.

Default connection factory bindings is similar to the scripting option -defaultbinding.cf.jndi.

Use default virtual host name for web and SIP modules

Virtual host for the web module (WAR file) or SIP module (SAR file).

The default is to not use default virtual host name for web or SIP modules. If we select Use default virtual host name for web and SIP modules, specify a default host name.

Use default virtual host name for Web and SIP modules is similar to the scripting option -defaultbinding.virtual.host.

Related:

Application bindings
Enterprise (Java EE) applications
Example: Installing an EAR file using the default bindings
Install enterprise application files with the console
Prepare for application installation settings

Option	Description
Fast Path - Prompt only when additional information is required	Displays only those options that require your attention, based on the contents of the application or module. Use the fast path to install the application more easily because we do not need to examine all available installation options.
Detailed - Show all installation options and parameters	Display all available installation options.

Option	Description
Merge new and existing bindings	The binding information from the updated application or modules is preferred over the corresponding binding information from the installed version. If any element of the binding is missing in the updated version, the corresponding element from the installed version is used. If both the installed and the updated application or module does not have a binding value, the default value is used. The product assigns a default value only if we select the Generate default bindings option.
Use new bindings	The binding information in the updated application or module is used. The binding information from the updated version of the application or module is preferred over the corresponding binding information in the installed version. The binding information from the installed version of the application or module is ignored.
Use existing bindings	The binding information from the installed version of the application or module is preferred over the corresponding binding information from the updated version. If any element of the binding information does not exist in the installed version, the element from the updated version is used. That is, bindings from the updated version of the application or module are ignored if a binding exists in the installed version. Otherwise, the new bindings are honored and not ignored.