Prepare for application installation settings

Prepare for application installation settings

+
Search Tips | Advanced Search

Use this page to install an application or module.
To view this console page, click...
Applications | Install New Application

Follow the steps on this page to install an application or module. You must complete, at minimum, the first step. You must complete some or all of the later steps, depending on whether you are installing an enterprise application (EAR file), enterprise bean (EJB) module (JAR file), Session Initiation Protocol (SIP) module (SAR file), or Web module (WAR file).
Path to the new application

Fully qualified path to the enterprise application file.
The file can be an .ear, .jar, .sar, or .war file.
On Windows machines, there is a limit of 256 characters for file paths. The application installation might fail if the path for application files in the configuration session or in the configuration repository exceeds the limit of 256 characters. To overcome such problems, make application names short in length to reduce the file path length.
Use Local file system if the browser and application files are on the same machine (whether or not the server is on that machine, too).
Use Remote file system if the application file resides on any node in the current cell context. Only .ear, .jar, .sar, or .war files are shown during the browsing.
During application installation, application files typically are uploaded from a client machine running the browser to the server machine running the console, where they are deployed. In such cases, use the Web browser running the console to select EAR, WAR, SAR, 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 Remote file system option.
Also use the Remote file system option to specify an application file already residing on the machine running the appserver. For example, the field value might be profile_root/installableApps/test.ear. If you are installing a standalone WAR module, then specify the context root as well.
After the application file is transferred, the Remote file system value shows the path of the temporary location on the server machine.

Context root

Specify the context root of the module.
This field is used only to install a standalone Web application (WAR file) or Session Initiation Protocol (SIP) module (SAR file).
The context root is combined with the defined servlet mapping (from the module file) to compose the full URL that users type to access the servlet. For example, if a WAR context root is /gettingstarted and the servlet mapping is MySession, then the URL is http://host:port/gettingstarted/MySession.

How do you want to install the application?

Specify whether to show only installation options that require you to supply information or to show all installation options.
The Prompt me only when additional information is required option enables you to install your application more because you do not need to examine all available installation options.
However, to use the Generate default bindings option, which might be the quickest and easiest option for installing your application, select the Show me all installation options and parameters and then select Generate default bindings on the next panel.

Generate default bindings

Specify 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.
You must select Show me all installation options and parameters to view this option.
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.

For EJB2.1 or EJB2.0 message-driven beans deployed as 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 as follows: 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 message-driven beans deployed against a listener ports, the 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.

We need tighter control of data source bindings for container-managed persistence (CMP) beans. 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 change 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

Specify prefixes to use for generated JNDI names.
You must select Show me all installation options and parameters to view prefix options.
Prefixes is similar to the scripting option -defaultbinding.ejbjndi.prefix.

Override

Specify whether generated bindings are to override existing bindings.
If Override existing bindings is selected, the existing bindings are overridden by the generated ones.
You must select Show me all installation options and parameters to view override options.
Override is similar to the scripting option -defaultbinding.force.

EJB 1.1 CMP bindings

Specify 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 container-managed persistence (CMP) 1.1 beans. Also specify the user ID and password for this default data source.
You must select Show me all installation options and parameters to view EJB CMP binding options.
Default bindings for EJB 1.1 CMPs is similar to the scripting option -defaultbinding.datasource.jndi.

Data source bindings for 2.0 CMP beans

Specify the default data source JNDI name for 2.0 CMP beans.
If Default data source for 2.0 CMP beans is selected, specify the JNDI name for the default data source to be used with the 2.0 CMP beans. Also specify the resource authorization.
You must select Show me all installation options and parameters to view data source binding options.
Default data source for 2.0 CMP beans is similar to the scripting option -defaultbinding.cf.jndi.

Virtual host

Specify the virtual host for the Web module.
You must select Show me all installation options and parameters to view virtual host options.
Virtual host is similar to the scripting option -defaultbinding.virtual.host.

Specific bindings file
Specify a bindings file that overrides the default binding.
You must select Show me all installation options and parameters to view this option.
Specific bindings file is similar to the scripting option -defaultbinding.strategy.file.
Change the behavior of the default binding with an XML document (a custom strategy). Custom strategies extend the default strategy so you only need to customize those areas where the default strategy is insufficient. Thus, 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>
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>
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
Example 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>
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 J2EE client JAR file
Example code for overriding a resource reference binding from a WAR file follows. Use similar code to override a resource reference 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>
Ensure that the setting for <resource-ref-name> matches the resource-ref tag in the deployment descriptor. Here 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
Example XML extract in a custom strategy file for overriding the JMS activationSpec JNDI name for an EJB 2.1 or EJB 2.0 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 message-driven bean
Example XML extract in a custom strategy file for overriding the JMS listener port name for an EJB 2.0 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
Example code for overriding an EJB reference binding from an EJB JAR file follows. 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>
Related concepts
Enterprise (J2EE) applications

Related tasks
Installing application files with the console

Related information
Administrative console buttons