Options for the AdminApp object install, installInteractive, edit, editInteractive, update, and updateInteractive commands using wsadmin scripting

This topic lists the available options for the install, installInteractive, edit, editInteractive, update, and updateInteractive commands of the AdminApp object.

You can use the commands for the AdminApp object to install, edit, update, and manage your application configurations. This topic provides additional options to use with the install, installInteractive, edit, editInteractive, update, and updateInteractive commands to administer your applications. The options listed in this topic apply to all of these commands except where noted.

You can set or update a configuration value using options in batch mode. To identify which configuration object is to be set or updated, the values of read only fields are used to find the corresponding configuration object. All the values of read only fields have to match with an existing configuration object, otherwise the command fails.

You can use pattern matching to simplify the task of supplying required values for certain complex options. Pattern matching only applies to fields that are required or read only.

Attention: If an application is running, changing an application setting causes the application to restart. On stand-alone servers, the application restarts after you save the change. On multiple-server products, the application restarts after you save the change and files synchronize on the node where the application is installed. To control when synchronization occurs on multiple-server products, deselect Synchronize changes with nodes on the Console preferences page.
The following options are available for the install, installInteractive, edit, editInteractive, update, and updateInteractive commands:

ActSpecJNDI

The ActSpecJNDI option binds Java™ 2 Connector (J2C) activation specifications to destination Java Naming and Directory Interface (JNDI) names. You can optionally bind J2C activation specifications in your application or module to a destination JNDI name. You can assign a value to each of the following elements of the ActSpecJNDI option: RARModule, uri, j2cid, and j2c.jndiName fields. The contents of the option after running default bindings include:
  • RARModule: <rar module name>
  • uri: <rar name>,META-INF/ra.xml
  • Object identifier: <messageListenerType>
  • JNDI name: null
To use this option, you must specify the Destination property in the ra.xml file and set the introspected type of the Destination property as javax.jms.Destination

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are either missing information, or requiring an update.

Batch mode example usage

Using Jacl:
$AdminApp install $embeddedEar {-ActSpecJNDI
 {{"FVT Resource Adapter" jca15cmd.rar,META-INF/ra.xml javax.jms.MessageListener jndi5}
 {"FVT Resource Adapter" jca15cmd.rar,META-INF/ra.xml javax.jms.MessageListener2 jndi6}}} 
Using Jacl with pattern matching:
$AdminApp install $embeddedEar {-ActSpecJNDI
 {{.* .*.rar,.* javax.jms.MessageListener jndi5}
 {.*  .*.rar,.*  javax.jms.MessageListener2 jndi6}}} 
Using Jython:
AdminApp.install(embeddedEar, ['-ActSpecJNDI',
 [["FVT Resource Adapter", 'jca15cmd.rar,META-INF/ra.xml', 'javax.jms.MessageListener', 'jndi5'],
 ["FVT Resource Adapter", 'jca15cmd.rar,META-INF/ra.xml', 'javax.jms.MessageListener2', 'jndi6']]]) 
Using Jython with pattern matching:
AdminApp.install(embeddedEar, ['-ActSpecJNDI',
 [['.*', '.*.rar,.*', 'javax.jms.MessageListener', 'jndi5'],
 ['.*', '.*.rar,.*', 'javax.jms.MessageListener2', 'jndi6']]]) 

allowDispatchRemoteInclude

The allowDispatchRemoteInclude option enables an enterprise application to 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.

Batch mode example usage

Using Jacl:
set deployments [$AdminConfig getid /Deployment:RRDEnabledAppname/]
set deploymentObject [$AdminConfig showAttribute $deployments deployedObject]
set rrdAttr [list allowDispatchRemoteInclude true]
set attrs [list $rrdLocalAttr]
$AdminConfig modify $deploymentObject $attrs
Using Jython:
deployments = AdminConfig.getid ('/Deployment:RRDEnabledAppname/')
deploymentObject = AdminConfig.showAttribute (deployments, 'deployedObject')
rrdAttr = ['allowDispatchRemoteInclude', 'true']
attrs = [rrdLocalAttr]
AdminConfig.modify (deploymentObject, attrs)

allowPermInFilterPolicy

The allowPermInFilterPolicy option specifies that the application server should continue with the application deployment process even when the application contains policy permissions that are in the filter policy. This option does not require a value.

allowServiceRemoteInclude

The allowServiceRemoteInclude option enables an enterprise application to service an include request from an enterprise application with the allowDispatchRemoteInclude option set to true.

Batch mode example usage

Using Jacl:
set deployments [$AdminConfig getid /Deployment:RRDEnabledAppname/]
set deploymentObject [$AdminConfig showAttribute $deployments deployedObject]
set rrdAttr [list allowServiceRemoteInclude true]
set attrs [list $rrdAttr]
$AdminConfig modify $deploymentObject $attrs
Using Jython:
deployments = AdminConfig.getid ('/Deployment:RRDEnabledAppname/')
deploymentObject = AdminConfig.showAttribute ('deployments', 'deployedObject')
rrdAttr = ['allowServiceRemoteInclude', 'true']
attrs = [rrdAttr] 
AdminConfig.modify (deploymentObject, attrs) 

appname

The appname option specifies the name of the application. The default value is the display name of the application.

BackendIdSelection

The BackendIdSelection option specifies the backend ID for the enterprise bean Java archive (JAR) modules that have container-managed persistence (CMP) beans. An enterprise bean JAR module can support multiple backend configurations as specified using an application assembly tool. Use this option to change the backend ID during installation.

Batch mode example usage

Using Jacl:
$AdminApp install myapp.ear {-BackendIdSelection 
 {{Annuity20EJB Annuity20EJB.jar,META-INF/ejb-jar.xml DB2UDBNT_V72_1}}} 
Using Jacl with pattern matching:
$AdminApp install myapp.ear {-BackendIdSelection 
 {{.* Annuity20EJB.jar,.* DB2UDBNT_V72_1}}} 
Using Jython:
AdminApp.install('myapp.ear', '[-BackendIdSelection 
 [[Annuity20EJB Annuity20EJB.jar,META-INF/ejb-jar.xml DB2UDBNT_V72_1]]]')
Using Jython with pattern matching:
AdminApp.install('myapp.ear', ['-BackendIdSelection',
 [['.*', 'Annuity20EJB.jar,.*', 'DB2UDBNT_V72_1']]])

BindJndiForEJBBusiness

The BindJndiForEJBBusiness option binds EJB modules with business interfaces to JNDI names. Ensure that each EJB module with business interfaces is bound to a JNDI name.

The current contents of the option after running default bindings include:
  • Module: Ejb1
  • Bean: MessageBean
  • URI: sample.jar,META-INF/ejb-jar.xml
  • Business interface: com.ibm.sample.business.bnd.LocalTargetOne
  • JNDI name: []: ejblocal:ejb/LocalTargetOne

If you specify the target resource JNDI name using the BindJndiForEJBNonMessageBinding option, do not specify a business interface JNDI name in the BindJndiForEJBBusiness option. If you do not specify the target resource JNDI name, specify a business interface JNDI name. If you do not specify a business interface JNDI name, the run time provides a container default.

For a no-interface view, the business interface value is an empty string ("").

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are either missing information, or requiring an update.

Batch mode example usage

Using Jacl:
$AdminApp install $ear {-BindJndiForEJBBusiness {{ ejb_1.jar ejb1 
  ejb_1.jar,META-INF/ejb-jar.xml test.ejb1 jndi1 }}}
Using Jacl with pattern matching:
$AdminApp install $ear {-BindJndiForEJBBusiness {{ .* .* .*.jar,.* test.ejb1 jndi1 }}}
Using Jython:
AdminApp.install(ear, '[-BindJndiForEJBBusiness [[ejb_1.jar ejb1 
  ejb_1.jar,META-INF/ejb-jar.xml test.ejb1 jndi1 ]]]')
Using Jython with pattern matching:
AdminApp.install(ear, '[-BindJndiForEJBBusiness [[.* .* .*.jar,.* test.ejb1 jndi1]]]')

BindJndiForEJBMessageBinding

The BindJndiForEJBMessageBinding option binds message-driven enterprise beans to listener port names or to activation specification Java Naming and Directory Interface (JNDI) names. Use this option to provide missing data or update a task. When a message-driven enterprise bean is bound to an activation specification JNDI name, you can also specify the destination JNDI name and authentication alias.

Each element of the BindJndiForEJBMessageBinding option consists of the following fields: EJBModule, EJB, uri, listenerPort, JNDI, jndi.dest, and actspec.auth. Some of these fields can be assigned values: listenerPort, JNDI, jndi.dest, and actspec.auth.

The current contents of the option after running default bindings include:
  • Module: Ejb1
  • Bean: MessageBean
  • URI: ejb-jar-ic.jar,META-INF/ejb-jar.xml
  • Listener port: [null]:
  • JNDI name: [eis/MessageBean]:
  • Destination JNDI Name: [jms/TopicName]:
  • ActivationSpec Authentication Alias: [null]:

If a destinationLookup activation configuration property is not provided as an annotation or in the deployment descriptor and a destination JNDI name is not in the IBM binding file, the default Destination JNDI Name is collected from the corresponding message reference.

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are either missing information, or requiring an update.

Batch mode example usage

Using Jacl:
$AdminApp install $ear {-BindJndiForEJBMessageBinding {{Ejb1 MessageBean 
 ejb-jar-ic.jar,META-INF/ejb-jar.xml myListenerPort jndi1 jndiDest1 actSpecAuth1}}} 
Using Jacl with pattern matching:
$AdminApp install $ear {-BindJndiForEJBMessageBinding {{.*  .*
  .*.jar,.* myListenerPort jndi1 jndiDest1 actSpecAuth1}}}
Using Jython:
AdminApp.install( ear, ['-BindJndiForEJBMessageBinding',
 [['Ejb1', 'MessageBean', 'ejb-jar-ic.jar,META-INF/ejb-jar.xml', 'myListenerPort',
 'jndi1', 'jndiDest1', 'actSpecAuth1']]]) 
Using Jython with pattern matching:
AdminApp.install( ear, ['-BindJndiForEJBMessageBinding',
 [['.*', '.*', '.*.jar,.*', 'myListenerPort', 'jndi1', 'jndiDest1', 'actSpecAuth1']]])

BindJndiForEJBNonMessageBinding

The BindJndiForEJBNonMessageBinding option binds enterprise beans to Java Naming and Directory Interface (JNDI) names. Ensure each non message-driven enterprise bean in your application or module is bound to a JNDI name. Use this option to provide missing data or update a task.

The current contents of the option after running default bindings include:
  • Module: Ejb1
  • Bean: MessageBean
  • URI: ejb-jar-ic.jar,META-INF/ejb-jar.xml
  • Target Resource JNDI Name: [com.acme.ejbws.AnnuityMgmtSvcEJB2xJAXRPC]
  • Local Home JNDI Name: [null]
  • Remote Home JNDI Name: [null]

Special constraints exist for Enterprise JavaBeans (EJB) 3.0 and later modules. If you specify the target resource JNDI name, do not specify the local home or remote home JNDI names. You also cannot specify the JNDI for business interfaces field in the BindJndiForEJBBusiness option. If you do not specify the target resource JNDI name, then the local and remote home JNDI name fields are optional. If you do not specify local and remote JNDI names, the run time provides a container default.

If you do not use EJB 3.0 modules, you must specify the target resource JNDI name.

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are either missing information, or requiring an update.

Batch mode example usage

Using Jacl:

[Windows]
$AdminApp install c:/myapp.ear {-BindJndiForEJBNonMessageBinding {{Ejb1 MessageBean 
  ejb-jar-ic.jar,META-INF/ejb-jar.xml com.acme.ejbws.AnnuityMgmtSvcEJB2xJAXRPC ""  ""}}}
[Linux][AIX][HP-UX][IBM i][Solaris]
$AdminApp install /myapp.ear {-BindJndiForEJBNonMessageBinding {{Ejb1 MessageBean 
  ejb-jar-ic.jar,META-INF/ejb-jar.xml com.acme.ejbws.AnnuityMgmtSvcEJB2xJAXRPC ""  ""}}}
Using Jacl with pattern matching:
$AdminApp install app_server_rootapps/myapps/installableApps/JobbankTargetEJBApp.ear
 {-BindJndiForEJBNonMessageBinding {{.* .* ResumeBankAppEJB.jar,META-INF/ejb-jar.xml
 ejb/com/app/ResumeBank/ResumeBank "" "" }}}

Using Jython:

[Windows]
AdminApp.install('C:/myapp.ear', '[-BindJndiForEJBNonMessageBinding [[Ejb1 MessageBean
  ejb-jar-ic.jar,META-INF/ejb-jar.xml com.acme.ejbws.AnnuityMgmtSvcEJB2xJAXRPC "" ""]]]')
[Linux][AIX][HP-UX][IBM i][Solaris]
AdminApp.install('myapp.ear', '[-BindJndiForEJBNonMessageBinding [[Ejb1 MessageBean 
  ejb-jar-ic.jar,META-INF/ejb-jar.xml com.acme.ejbws.AnnuityMgmtSvcEJB2xJAXRPC "" ""]]]')
Using Jython with pattern matching:
AdminApp.install('app_server_root/apps/myapps/installableApps/JobbankTargetEJBApp.ear',
 '[ -BindJndiForEJBNonMessageBinding [[ .* .* ResumeBankAppEJB.jar,META-INF/ejb-jar.xml
 ejb/com/app/ResumeBank/ResumeBank "" "" ]] ]' )

blaname

Use the blaname option to specify the name of business level application under which the system creates the Java EE application. This option is optional. If you do not specify a value, the system sets the name as the Java EE application name. This option is available only with the install command.

buildVersion

The buildVersion option displays the build version of an application EAR file. You cannot modify this option because it is read-only. This option returns the build version information for an application EAR if you have specified the build version in the MANIFEST.MF application EAR file.

cell

The cell option specifies the cell name to install or update an entire application, or to update an application in order to add a new module. If you want to update an entire application, this option only applies if the application contains a new module that does not exist in the installed application.

Batch mode example usage

Using Jacl:

[Windows]
$AdminApp install "C:/apps/myapps/installableApps/JobbankTargetEJBApp.ear" {-cell cellName}
[Linux][AIX][HP-UX][IBM i][Solaris]
$AdminApp install "/apps/myapps/installableApps/JobbankTargetEJBApp.ear" {-cell cellName}

Using Jython:

[Windows]
AdminApp.install('C:/apps/myapps/installableApps/JobbankTargetEJBApp.ear', '[-cell cellName]')
[Linux][AIX][HP-UX][IBM i][Solaris]
AdminApp.install('/apps/myapps/installableApps/JobbankTargetEJBApp.ear', '[-cell cellName]')

clientMode

The clientMode option specifies whether to deploy client modules to an isolated deployment target (isolated), a federated node of a deployment manager (federated), or an application server (server_deployed). If you specify this option, install the client modules only onto a Version 8.0 or later deployment target.

The default value is isolated.

The choice of client deployment mode affects how java: lookups are handled. All Java URL name spaces (global, application, module, and component) are local in isolated client processes. The name spaces reside on a server in federated and server deployed client processes. The server chosen as a target for a client module determines where those name spaces are created. All java: lookups for federated or server deployed client modules are directed to the target server. The client module does not actually run in the target server. Multiple instances of the same client module will all share the component name space in the federated and server deployed modes. Choosing the federated mode is simply a declaration of intent to launch the client module using Java Network Launching Protocol (JNLP), but the Java Naming and Directory Interface (JNDI) mechanics of federated and server deployed modes are the same.

contents

The contents option specifies the file that contains the content that you want to update. For example, depending on the content type, the file could be an EAR file, a module, a partial zip, or a single file. The path to the file must be local to the scripting client. The contents option is required unless you have specified the delete option.

contenturi

The contenturi option specifies the URI of the file that you are adding, updating, or removing from an application. This option only applies to the update command. The contenturi option is required if the content type is file or modulefile. This option is ignored for other content types.

contextroot

The contextroot option specifies the context root that you use when installing a stand-alone web application archive (WAR) file.

CorrectOracleIsolationLevel

The CorrectOracleIsolationLevel option specifies the isolation level for the Oracle type provider. Use this option to provide missing data or to update a task. The last field of each entry specifies the isolation level. Valid isolation level values are 2 or 4.

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You only need to provide data for rows or entries that are either missing information, or requiring an update.

Batch mode example usage

Using Jacl:
$AdminApp install myapp.ear {-CorrectOracleIsolationLevel
 {{AsyncSender jms/MyQueueConnectionFactory jms/Resource1 2}}
Using Jacl with pattern matching:
$AdminApp install myapp.ear {-CorrectOracleIsolationLevel
  {{.*  jms/MyQueueConnectionFactory jms/Resource1 2}}
Using Jython:
AdminApp.install('myapp.ear', '[-CorrectOracleIsolationLevel
 [[AsyncSender jms/MyQueueConnectionFactory jms/Resource1 2]]]')
Using Jython with pattern matching:
AdminApp.install('myapp.ear', ['-CorrectOracleIsolationLevel',
 [['.*', 'jms/MyQueueConnectionFactory', 'jms/Resource1', 2]]])

CorrectUseSystemIdentity

The CorrectUseSystemIdentity option replaces RunAs System to RunAs Roles. The enterprise beans that you install contain a RunAs system identity. You can optionally change this identity to a RunAs role. Use this option to provide missing data or update a task.

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are either missing information, or requiring an update.

Batch mode example usage

Using Jacl:
$AdminApp install myapp.ear {-CorrectUseSystemIdentity {{Inc "Increment Bean Jar"
 Increment.jar,META-INF/ejb-jar.xml getValue() RunAsUser2 user2 password2} 
 {Inc "Increment Bean Jar" Increment.jar,META-INF/ejb-jar.xml Increment()
 RunAsUser2 user2 password2}}}
Using Jacl with pattern matching:
$AdminApp install myapp.ear {-CorrectUseSystemIdentity
 {{.*  .*  .*  getValue() RunAsUser2 user2 password2}
 {.*  .*  .*  Increment() RunAsUser2 user2 password2}}}
Using Jython:
AdminApp.install('myapp.ear', '[-CorrectUseSystemIdentity
 [[Inc "Increment Bean Jar" Increment.jar,META-INF/ejb-jar.xml getValue()
 RunAsUser2 user2 password2] 
 [Inc "Increment Bean Jar" Increment.jar,META-INF/ejb-jar.xml Increment()
 RunAsUser2 user2 password2]]]')
Using Jython with pattern matching:
AdminApp.install('myapp.ear', ['-CorrectUseSystemIdentity',
 [['.*', '.*', '.*', 'getValue()', 'RunAsUser2', 'user2', 'password2'],
 ['.*', '.*', '.*', 'Increment()', 'RunAsUser2', 'user2', 'password2']]])

createMBeansForResources

The createMBeansForResources option specifies that MBeans are created for all resources, such as servlets, JavaServer Pages (JSP) files, and enterprise beans, that are defined in an application when the application starts on a deployment target. This option does not require a value. The default setting is the nocreateMBeansForResources option.

CtxRootForWebMod

The CtxRootForWebMod option edits the context root of the web module. You can edit a context root that is defined in the application.xml file using this option. The current contents of this option after running default bindings are the following:
  • Web module: xxx
  • URI: xxx
  • ContextRoot: <context root>
If the web module is a Servlet 2.5, the contents of this option are populated only from the XML deployment descriptor. You cannot get deployment information from annotations with this option.

Batch mode example usage

Using Jacl:

$AdminApp install app_server_root/installableApps/ivtApp.ear
 {-appname ivtApp -CtxRootForWebMod
 {{"IVT Application" ivt_app.war,WEB-INF/web.xml /mycontextroot}}}
Using Jacl with pattern matching:
$AdminApp install myapp.ear {-appname MyApp -CtxRootForWebMod {{.* .* /mycontextroot}}}

Using Jython:

AdminApp.install('app_server_root/installableApps/ivtApp.ear',
 ['-appname', 'ivtApp ', '-CtxRootForWebMod',
 [["IVT Application", 'ivt_app.war,WEB-INF/web.xml', '/mycontextroot']]])
Using Jython with pattern matching:
AdminApp.install('myapp.ear', ['-appname', 'MyApp', '-CtxRootForWebMod',
 [['.*', '.*', '/mycontextroot']]])

custom

The custom option specifies a name-value pair using the format name=value. Use the custom option to pass options to application deployment extensions. See the application deployment extension documentation for available custom options.

CustomActivationPlan

The CustomActivationPlan option specifies runtime components to add or remove from the default runtime components that are used to run the application. Only use this option when the application server can not obtain all necessary runtime components by inspecting the application.

Batch mode example usage

Using Jython:
AdminApp.install('Increment.jar','[-CustomActivationPlan [["Increment Enterprise Java Bean"
 Increment.jar,META-INF/ejb-jar.xml WebSphere:specname=WS_ComponentToAdd ""]]')
Using Jython with pattern matching:
AdminApp.install('Increment.jar','[-CustomActivationPlan [[.*
 Increment.jar,META-INF/ejb-jar.xml WebSphere:specname=WS_ComponentToAdd ""]]')
Table 1. CustomActivationPlan components to add. Specify a WS_ComponentToAdd value in the command.
Component WS_ComponentToAdd value
EJB container WS_EJBContainer
Portlet container WS_PortletContainer
JavaServer Faces (JSF) WS_JSF
SIP container WS_SipContainer
Compensation scope service WS_Compensation
Application profile WS_AppProfile
Activity session WS_ActivitySession
Internationalization WS_I18N
Startup beans WS_StartupService

DataSourceFor10CMPBeans

The DataSourceFor10CMPBeans option specifies optional data sources for individual 1.x container-managed persistence (CMP) beans. Use this option to provide missing data or to update a task.

Mapping a specific data source to a CMP bean overrides the default data source for the module that contains the enterprise bean. Each element of the DataSourceFor10CMPBeans option consists of the following fields: EJBModule, EJB, uri, JNDI, userName, password, login.config.name, and auth.props. Of these fields, the following can be assigned values: JNDI, userName, password, login.config.name, and auth.props.

The current contents of the option after running default bindings include:
  • Module: Increment CMP 1.1 EJB
  • Bean: IncCMP11
  • URI: IncCMP11.jar,META-INF/ejb-jar.xml
  • Target Resource JNDI name: [DefaultDatasource]:
  • User name: [null]:
  • Password: [null]:
  • Login configuration name: [null]: Use this option to create a custom login configuration. The client can use JAAS to create a login design.
  • Properties: [null]: Use this option to create a custom login configuration. The client can use JAAS to create a login design.

If the login.config.name is set to DefaultPrincipalMapping, a property is created with the name com.ibm.mapping.authDataAlias. The value of the property is set by the auth.props. If the login.config name is not set to DefaultPrincipalMapping, the auth.props can specify multiple properties. The string format is websphere:name= <name1>,value=<value1>,description=<desc1>. Specify multiple properties using the plus sign (+) .

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are missing information, or requiring an update.

Batch mode example usage

Using Jacl:

[Windows]
$AdminApp install C:/app1.ear {-DataSourceFor10CMPBeans {{"Increment CMP 1.1 EJB"
 IncCMP11 IncCMP11.jar,META-INF/ejb-jar.xml myJNDI user1 password1 loginName1 authProps1}}} 
[Linux][AIX][HP-UX][IBM i][Solaris]
$AdminApp install myapp.ear {-DataSourceFor10CMPBeans {{"Increment CMP 1.1 EJB" IncCMP11
 IncCMP11.jar,META-INF/ejb-jar.xml myJNDI user1 password1 loginName1 authProps1}}} 

Using Jacl with pattern matching:

[Windows]
$AdminApp install C:/myapp.ear {-DataSourceFor10CMPBeans {{.*  .*  
 IncCMP11.jar,.* myJNDI user1 password1 loginName1 authProps1}}}
[Linux][AIX][HP-UX][IBM i][Solaris]
$AdminApp install myapp.ear {-DataSourceFor10CMPBeans {{.*  .*  IncCMP11.jar,.*
 myJNDI user1 password1 loginName1 authProps1}}}

Using Jython:

[Windows]
AdminApp.install('C:/app1.ear', ['-DataSourceFor10CMPBeans', [["Increment CMP 1.1 EJB",
 'IncCMP11', 'IncCMP11.jar,META-INF/ejb-jar.xml', 'myJNDI', 'user1', 'password1',
 'loginName1', 'authProps1']]]) 
[Linux][AIX][HP-UX][IBM i][Solaris]
AdminApp.install('myapp.ear', ['-DataSourceFor10CMPBeans', [["Increment CMP 1.1 EJB",
 'IncCMP11', 'IncCMP11.jar,META-INF/ejb-jar.xml', 'myJNDI', 'user1',
 'password1', 'loginName1', 'authProps1']]]) 

Using Jython with pattern matching:

[Windows]
AdminApp.install('C:/myapp.ear', ['-DataSourceFor10CMPBeans', [['.*', '.*', 
 'IncCMP11.jar,.*', 'myJNDI', 'user1', 'password1', 'loginName1', 'authProps1']]])
[Linux][AIX][HP-UX][IBM i][Solaris]
AdminApp.install('myapp.ear', ['-DataSourceFor10CMPBeans', [['.*', '.*',
 'IncCMP11.jar,.*', 'myJNDI', 'user1', 'password1', 'loginName1', 'authProps1']]])

DataSourceFor20CMPBeans

The DataSourceFor20CMPBeans option specifies optional data sources for individual 2.x container-managed persistence (CMP) beans. Use this option to provide missing data or to update a task.

Mapping a specific data source to a CMP bean overrides the default data source for the module that contains the enterprise bean. Each element of the DataSourceFor20CMPBeans option consists of the following fields: EJBModule, EJB, uri, JNDI, resAuth, login.config.name, and auth.props. Of these fields, the following can be assigned values: JNDI, resAuth, login.config.name, and auth.props.

The current contents of the option after running default bindings includes the following:
  • Module: Increment enterprise bean
  • Bean: Increment
  • URI: Increment.jar,META-INF/ejb-jar.xml
  • Target Resource JNDI name: [null]:
  • Resource authorization: [Per application]:
  • Login configuration name: [null]: Use this option to create a custom login configuration. The client can use JAAS to create a login design.
  • Properties: []: Use this option to create a custom login configuration. The client can use JAAS to create a login design.

If the login.config.name is set to DefaultPrincipalMapping, a property is created with the name com.ibm.mapping.authDataAlias. The value of the property is set by the auth.props. If the login.config name is not set to DefaultPrincipalMapping, the auth.props can specify multiple properties. The string format is websphere:name= <name1>,value=<value1>,description=<desc1>. Specify multiple properties using the plus sign (+).

Use the taskInfo command of the AdminApp object to obtain information about the data needed for your application. You only need to provide data for rows or entries that are missing information, or requiring an update.

Batch mode example usage

Using Jacl:
$AdminApp install Increment.jar {-DataSourceFor20CMPBeans
 {{"Increment Enterprise Java Bean" Increment
 Increment.jar,META-INF/ejb-jar.xml jndi1 container "" ""}}} 
Using Jacl with pattern matching:
$AdminApp install Increment.jar {-DataSourceFor20CMPBeans {{.*  .*
 Increment.jar,.*  jndi1 container "" ""}}}
Using Jython:
AdminApp.install('Increment.jar', ['-DataSourceFor20CMPBeans',
 [["Increment Enterprise Java Bean", 'Increment',
 'Increment.jar,META-INF/ejb-jar.xml', 'jndi1', 'container', '', '']]])
Using Jython with pattern matching:
AdminApp.install('Increment.jar', ['-DataSourceFor20CMPBeans', [['.*', '.*',
 'Increment', 'Increment.jar,.*', 'jndi1', 'container', '', '']]])

DataSourceFor10EJBModules

The DataSourceFor10EJBModules option specifies the default data source for the enterprise bean module that contains 1.x container-managed persistence (CMP) beans. Use this option to provide missing data or update a task.

Each element of the DataSourceFor10EJBModules option consists of the following fields: EJBModule, uri, JNDI, userName, password, login.config.name, and auth.props. Of these fields, the following can be assigned values: JNDI, userName, password, login.config.name, and auth.props.

The current contents of the option after running default bindings include:
  • Module: Increment CMP 1.1 enterprise bean
  • uri: IncCMP11.jar,META-INF/ejb-jar.xml
  • Target Resource JNDI name: [DefaultDatasource]:
  • User name: [null]:
  • Password: [null]:
  • Login configuration name: [null]: Use this option to create a custom login configuration. The client can use JAAS to create a login design.
  • Properties: [null]: Use this option to create a custom login configuration. The client can use JAAS to create a login design.

If the login.config.name is set to DefaultPrincipalMapping, a property is created with the name com.ibm.mapping.authDataAlias. The value of the property is set by the auth.props. If the login.config name is not set to DefaultPrincipalMapping, the auth.props can specify multiple properties. The string format is websphere:name= <name1>,value=<value1>,description=<desc1>. Specify multiple properties using the plus sign (+).

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are either missing information, or requiring an update.

Batch mode example usage

Using Jacl:
$AdminApp install myapp.ear {-DataSourceFor10EJBModules {{"Increment CMP 1.1 EJB"
 IncCMP11.jar,META-INF/ejb-jar.xml yourJNDI user2 password2 loginName authProps}}} 
Using Jacl with pattern matching:
$AdminApp install myapp.ear {-DataSourceFor10EJBModules
 {{.* IncCMP11.jar,.* yourJNDI user2 password2 loginName authProps}}}
Using Jython:
AdminApp.install('myapp.ear', ['-DataSourceFor10EJBModules', [["Increment CMP 1.1 EJB",
 'IncCMP11.jar,META-INF/ejb-jar.xml', 'yourJNDI', 'user2', 'password2', 
 'loginName', 'authProps']]]) 
Using Jython with pattern matching:
AdminApp.install('myapp.ear', ['-DataSourceFor10EJBModules',
 [['.*', 'IncCMP11.jar,.*', 'yourJNDI', 'user2', 'password2', 'loginName', 'authProps']]])

DataSourceFor20EJBModules

The DataSourceFor20EJBModules option specifies the default data source for the enterprise bean 2.x module that contains 2.x container managed persistence (CMP) beans. Use this option to provide missing data or update a task.

Each element of the DataSourceFor20EJBModules option consists of the following fields: EJBModule, uri, JNDI, resAuth, login.config.name, and auth.props. Of these fields, the following can be assigned values: JNDI, resAuth, login.config.name, auth.props, and extended datasource properties.

The current contents of the option after running default bindings include:
  • Module: Increment enterprise bean
  • URI: Increment.jar,META-INF/ejb-jar.xml
  • Target Resource JNDI name: [DefaultDatasource]:
  • Resource authorization: [Per application]:
  • Login configuration name: [null]: Use this option to create a custom login configuration. The client can use JAAS to create a login design.
  • Properties: []: Use this option to create a custom login configuration. The client can use JAAS to create a login design.
  • Extended Data source properties: []: Use this option so that a data source that uses heterogeneous pooling can connect to a DB2® database. The pattern for the property is property1=value1+property2=value2.

The last field in each entry of this task specifies the value for resource authorization. Valid values for resource authorization are per connection factory or container.

If the login.config.name is set to DefaultPrincipalMapping, a property is created with the name com.ibm.mapping.authDataAlias. The value of the property is set by the auth.props. If the login.config name is not set to DefaultPrincipalMapping, the auth.props can specify multiple properties. The string format is websphere:name= <name1>,value=<value1>,description=<desc1>. Specify multiple properties using the plus sign (+).

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are either missing information, or require update.

Batch mode example usage

Using Jacl:
$AdminApp install Increment.jar {-DataSourceFor20EJBModules
 {{"Increment Enterprise Java Bean" Increment.jar,META-INF/ejb-jar.xml
 jndi2 container "" "" ""}}} 
Using Jacl with pattern matching:
$AdminApp install Increment.jar {-DataSourceFor20EJBModules {{.*
 Increment.jar,.* jndi2 container "" "" ""}}}
Note: If you use multiple values for extended data source properties, you must assign the values to a variable and use that variable for the property value. For example:
set s \"value1,value2\"
In the command substitution, reference the variable as shown in the following example:
"clientApplicationInformation=value1,value2" with "clientapplication=$s"
Using Jython:
AdminApp.install('Increment.jar', ['-DataSourceFor20EJBModules',
 [["Increment Enterprise Java Bean", 'Increment.jar,META-INF/ejb-jar.xml',
 'jndi2', 'container', '', '', '']]])
Using Jython with pattern matching:
AdminApp.install('Increment.jar', ['-DataSourceFor20EJBModules',
 [['.*', 'Increment.jar,.*', 'jndi2', 'container', '', '', '']]])
Note: If you use multiple values for extended data source properties, surround the two values with double quote characters. For example:
'property1="value1,value2"+property2="value3,value4"'

defaultbinding.cf.jndi

The defaultbinding.cf.jndi option specifies the Java Naming and Directory Interface (JNDI) name for the default connection factory.

defaultbinding.cf.resauth

The defaultbinding.cf.resauth option specifies the RESAUTH for the connection factory.

defaultbinding.datasource.jndi

The defaultbinding.datasource.jndi option specifies the Java Naming and Directory Interface (JNDI) name for the default data source.

defaultbinding.datasource.password

The defaultbinding.datasource.password option specifies the password for the default data source.

defaultbinding.datasource.username

The defaultbinding.datasource.username option specifies the user name for the default data source.

defaultbinding.ee.defaults

The defaultbinding.ee.defaults option specifies the preconfigured default resources option for Java EE.

defaultbinding.ejbjndi.prefix

The defaultbinding.ejbjndi.prefix option specifies the prefix for the enterprise bean Java Naming and Directory Interface (JNDI) name.

defaultbinding.force

The defaultbinding.force option specifies that the default bindings override the current bindings.

defaultbinding.strategy.file

The defaultbinding.strategy.file option specifies a custom default bindings strategy file.

defaultbinding.virtual.host

The defaultbinding.virtual.host option specifies the default name for a virtual host.

depl.extension.reg (deprecated)

Deprecated feature: The depl.extension.reg option is deprecated. No replication option is available.

deployejb

The deployejb option specifies to run the EJBDeploy tool during installation. This option does not require a value. The EJBDeploy tool only runs during installation of EJB 1.x or 2.x modules. The EJB deployment tool does not run during installation of EJB 3.x modules.

This option is ignored when the EAR or module to be installed or updated contains Java Platform, Enterprise Edition (Java EE) 7 application deployment descriptor, EJB 3.2 module deployment descriptor, or Web 3.1 module deployment descriptor.

If you pre-deploy the application enterprise archive (EAR) file using the EJBDeploy tool then the default value is nodeployejb. If not, the default value is deployejb.

If an EJB module contains entity beans, you must use this deployejb option 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 Version 5.0.

If an EJB module is packaged in a web archive (WAR), you do not need to use this deployejb option.

For this option, install only onto a Version 9.0 deployment target, which has the same or higher Java SDK level than the deployment manager.

deployejb.classpath

The deployejb.classpath option specifies an extra class path for the EJBDeploy tool.

deployejb.complianceLevel

The deployejb.complianceLevel option specifies the JDK compliance level for the EJBDeploy tool.

Possible values include:
1.4 (default) 5.0 6.0

For a list of currently supported JDK compliance levels, run the ejbdeploy -? command.

deployejb.dbschema

The deployejb.dbschema option specifies the database schema for the EJBDeploy tool.

deployejb.dbtype

The deployejb.dbtype option specifies the database type for the EJBDeploy tool.

Possible values include:
DB2UDB_V81 DB2UDB_V82 DB2UDB_V91 DB2UDB_V95 DB2UDBOS390_V8 DB2UDBOS390_NEWFN_V8 DB2UDBOS390_V9 
 DB2UDBISERIES_V53 DB2UDBISERIES_V54 DB2UDBISERIES_V61  DERBY_V10 DERBY_V101 INFORMIX_V100 INFORMIX_V111 INFORMIX_V115 
 MSSQLSERVER_2005 ORACLE_V10G ORACLE_V11G SYBASE_V15 SYBASE_V125
The following databases support Structured Query Language in Java (SQLJ): DB2UDB_V82, DB2UDB_V81, DB2UDBOS390_V7, and DB2UDBOS390_V8.

For a list of supported database vendor types, run the ejbdeploy -? command.

deployejb.dbaccesstype

The deployejb.dbaccesstype option specifies the type of database access for the EJBDeploy tool. Valid values are SQLj and JDBC. The default is JDBC.

deployejb.rmic

The deployejb.rmic option specifies extra RMIC options to use for the EJBDeploy tool.

deployejb.sqljclasspath

The deployejb.sqljclasspath option specifies the location of the SQLJ translator classes.

deployws

The deployws option specifies to deploy web services during installation. This option does not require a value.

The default value is: nodeployws.

For this option, install only onto a Version 9.0 deployment target, which has the same or higher Java SDK level than the deployment manager.

deployws.classpath

The deployws.classpath option specifies the extra class path to use when you deploy web services.

To specify the class paths of multiple entries, separate the entries with the same separator that is used with the CLASSPATH environment variable.

[Windows]Use a semicolon (;) to separate the entries.

[Linux][AIX][HP-UX][Solaris]Use a colon (:) to separate the entries.

deployws.jardirs

The deployws.jardirs option specifies the extra extension directories to use when you deploy web services.

distributeApp

The distributeApp option specifies that the application management component distribute application binaries. This option does not require a value. This setting is the default.

EmbeddedRar

The EmbeddedRar option binds Java 2 Connector objects to JNDI names. You must bind each Java 2 Connector object in your application or module, such as, J2C connection factories, J2C activation specifications and J2C administrative objects, to a JNDI name. Each element of the EmbeddedRar option contains the following fields: RARModule, uri, j2cid, j2c.name, j2c.jndiName. You can assign the following values to the fields: j2c.name, j2c.jndiName.

The current contents of the option after running default bindings include:
Connector module: <rar module name> 
URI: <rar name>,META-INF/ra.xml 
Object identifier: <identifier of the J2C object> 
name: j2cid 
JNDI name: eis/j2cid
Where j2cid is:
J2C connection factory: connectionFactoryInterface
J2C admin object: adminObjectInterface
J2C activation specification: message listener type

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are either missing information, or requiring an update.

If the ID is not unique in the ra.xml file, -<number> will be added. For example, javax.sql.DataSource-2.

Batch mode example usage

Using Jacl:
$AdminApp install $embeddedEar {-EmbeddedRar {{"FVT Resource Adapter" jca15cmd.rar,META-INF/ra.xml 
 javax.sql.DataSource javax.sql.DataSource1 eis/javax.sql.javax.sql.DataSSource1} {"FVT Resource Adapter" 
 jca15cmd.rar,META-INF/ra.xml javax.sql.DataSource2 javax.sql.DataSource2 eis/javax.sql.DataSource2} {"FVT Resource Adapter" 
 jca15cmd.rar,META-INF/ra.xml javax.jms.MessageListener javax.jms.MessageListener1 eis/javax.jms.MessageListener1} {"FVT Resource 
 Adapter" jca15cmd.rar,META-INF/ra.xml javax.jms.MessageLListener2 javax.jms.MessageListener2 eis/javax.jms.MessageListener2} 
 {"FVT Resource Adapter" jca15cmd.rar,META-INF/ra.xml fvt.adapter.message.FVTMessageProvider 
 fvt.adapter.message.FVTMessageProvider1 eis/fvt.adapter.message.FVTMessageProvider1} {"FVT Resource Adapter" 
 jca15cmd.rar,META-INF/ra.xml fvt.adapter.message.FVTMessageProvider2 fvt.adapter.message.FVTMessageProvider2 
 eis/fvt.adapter.message.FVTMessageProvider2}}} 
Using Jacl with pattern matching:
$AdminApp install $embeddedEar {-EmbeddedRar {{.*  .*  .*  javax.sql.DataSource1  
 eis/javax.sql.javax.sql.DataSSource1} {.*  .*  .*  javax.sql.DataSource2  eis/javax.sql.DataSource2} {.*  .*  .*  
 javax.jms.MessageListener1  eis/javax.jms.MessageListener1} {.*  .*  .*  javax.jms.MessageListener2  
 eis/javax.jms.MessageListener2} {.*  .*  .*  fvt.adapter.message.FVTMessageProvider1  
 eis/fvt.adapter.message.FVTMessageProvider1} {.*  .*  .*  fvt.adapter.message.FVTMessageProvider2  
 eis/fvt.adapter.message.FVTMessageProvider2}}}
Using Jython:
AdminApp.install(embeddedEar, ['-EmbeddedRar', [["FVT Resource Adapter", 
 'jca15cmd.rar,META-INF/ra.xml', 'javax.sql.DataSource', 'javax.sql.DataSource1', 'eis/javax.sql.javax.sql.DataSSource1'], ["FVT 
 Resource Adapter", 'jca15cmd.rar,META-INF/ra.xml javax.sql.DataSource2', 'javax.sql.DataSource2', 'eis/javax.sql.DataSource2'], 
 ["FVT Resource Adapter", 'jca15cmd.rar,META-INF/ra.xml', 'javax.jms.MessageListener', 'javax.jms.MessageListener1', 
 'eis/javax.jms.MessageListener1'], ["FVT Resource Adapter", 'jca15cmd.rar,META-INF/ra.xml', 'javax.jms.MessageLListener2', 
 'javax.jms.MessageListener2', 'eis/javax.jms.MessageListener2'], ["FVT Resource Adapter", 'jca15cmd.rar,META-INF/ra.xml 
 fvt.adapter.message.FVTMessageProvider', 'fvt.adapter.message.FVTMessageProvider1', 
 'eis/fvt.adapter.message.FVTMessageProvider1'], ["FVT Resource Adapter", 'jca15cmd.rar,META-INF/ra.xml', 
 'fvt.adapter.message.FVTMessageProvider2', 'fvt.adapter.message.FVTMessageProvider2', 
 'eis/fvt.adapter.message.FVTMessageProvider2']]]) 
Using Jython with pattern matching:
AdminApp.install(embeddedEar, ['-EmbeddedRar', [['.*', '.*', '.*', 'javax.sql.DataSource1', 
 'eis/javax.sql.javax.sql.DataSSource1'], ['.*', '.*', '.*', 'javax.sql.DataSource2', 'eis/javax.sql.DataSource2'], ['.*', '.*', 
 '.*', 'javax.jms.MessageListener1', 'eis/javax.jms.MessageListener1'], ['.*', '.*', '.*', 'javax.jms.MessageListener2', 
 'eis/javax.jms.MessageListener2'], ['.*', '.*', '.*', 'fvt.adapter.message.FVTMessageProvider1', 
 'eis/fvt.adapter.message.FVTMessageProvider1'], ['.*', '.*', '.*', 'fvt.adapter.message.FVTMessageProvider2', 
 'eis/fvt.adapter.message.FVTMessageProvider2']]])

enableClientModule

The enableClientModule option specifies to deploy client modules. Select this option if the file to deploy has one or more client modules that you want to deploy. If you select this option, install the client modules only onto a Version 8.0 or later deployment target.

This option does not require a value. The default value is noenableClientModule. By default, the enableClientModule option is ignored during deployment and client modules are not deployed.

EnsureMethodProtectionFor10EJB

The EnsureMethodProtectionFor10EJB option selects method protections for unprotected methods of 1.x enterprise beans. Specify to leave the method as unprotected, or assign protection which denies all access. Use this option to provide missing data or to update a task.

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are either missing information, or requiring an update.

Batch mode example usage

Using Jacl:
$AdminApp install Increment.jar {-EnsureMethodProtectionFor10EJB
 {{"Increment EJB Module" IncrementEJBBean.jar,META-INF/ejb-jar.xml ""}
 {"Timeout EJB Module" TimeoutEJBBean.jar,META-INF/ejb-jar.xml
 methodProtection.denyAllPermission}}}
Using Jacl with pattern matching:
$AdminApp install myapp.ear {-EnsureMethodProtectionFor10EJB
 {{.* IncrementEJBBean.jar,.* ""} {.* TimeoutEJBBean.jar,.*
 methodProtection.denyAllPermission}}}
Using Jython:
AdminApp.install('Increment.jar', '[-EnsureMethodProtectionFor10EJB
 [["Increment EJB Module" IncrementEJBBean.jar,META-INF/ejb-jar.xml ""]
 ["Timeout EJB Module" TimeoutEJBBean.jar,META-INF/ejb-jar.xml
 methodProtection.denyAllPermission]]]')
Using Jython with pattern matching:
AdminApp.install('myapp.ear', ['-EnsureMethodProtectionFor10EJB',
 [['.*', 'IncrementEJBBean.jar,.*', ""], ['.*', 'TimeoutEJBBean.jar,.*', 
 'methodProtection.denyAllPermission']]])

The last field in each entry of this task specifies the value of the protection. Valid protection values include: methodProtection.denyAllPermission. You can also leave the value blank if you want the method to remain unprotected.

EnsureMethodProtectionFor20EJB

The EnsureMethodProtectionFor20EJB option selects method protections for unprotected methods of 2.x enterprise beans. Specify to assign a security role to the unprotected method, add the method to the exclude list, or mark the method as cleared. You can assign multiple roles for a method by separating roles names with commas. Use this option to provide missing data or to update a task.

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are either missing information, or require an update the existing data.

Batch mode example usage

Using Jacl:

$AdminApp install myapp.ear {-EnsureMethodProtectionFor20EJB
 {{CustmerEjbJar customerEjb.jar,META-INF/ejb-jar.xml methodProtection.uncheck}
 {SupplierEjbJar supplierEjb.jar,META-INF/ejb-jar.xml methodProtection.exclude}}}

Using Jacl with pattern matching:

$AdminApp install myapp.ear {-EnsureMethodProtectionFor20EJB
 {{.* customerEjb.jar,.* methodProtection.uncheck}
 {.* supplierEjb.jar,.* methodProtection.exclude}}}
Using Jython:
AdminApp.install('myapp.ear', '[-EnsureMethodProtectionFor20EJB 
 [[CustmerEjbJar customerEjb.jar,META-INF/ejb-jar.xml methodProtection.uncheck]
 [SupplierEjbJar supplierEjb.jar,META-INF/ejb-jar.xml methodProtection.exclude]]]')
Using Jython with pattern matching:
AdminApp.install('myapp.ear', ['-EnsureMethodProtectionFor20EJB',
 [['.*', 'customerEjb.jar,.*', 'methodProtection.uncheck'],
 ['.*', 'supplierEjb.jar,.*', 'methodProtection.exclude']]])

The last field in each entry of this task specifies the value of the protection. Valid protection values include: methodProtection.uncheck, methodProtection.exclude, or a list of security roles that are separated by commas.

filepermission

The filepermission option enables you to set the appropriate file permissions on application files that are located in the installation directory. File permissions that you specify at the application level must be a subset of the node level file permission that defines the most lenient file permission that can be specified. Otherwise, node level permission values are used to set file permissions in the installation destination. The file name pattern is a regular expression. The default value is the following:
.*\.dll=755#.*\.so=755#.*\.a=755#.*\.sl=755

Batch mode example usage

Using Jacl:
$AdminApp install app_server_root/installableApps/DynaCacheEsi.ear
 {-appname MyApp -cell myCell -node myNode -server server1
 -filepermission .*\\.jsp=777#.*\\.xml=755}
Using Jython:
AdminApp.install("app_server_root/installableApps/DynaCacheEsi.ear",
 ["-appname", "MyApp", "-cell", "myCell", "-node", "myNode", "-server", "server1",
 "-filepermission", ".*\\.jsp=777#.*\\.xml=755"])

installdir (deprecated)

Deprecated feature: The installdir option is deprecated. This option is replaced by the installed.ear.destination option.

installed.ear.destination

The installed.ear.destination option specifies the directory to place application binaries.

JSPCompileOptions

The JSPCompileOptions option specifies Java ServerPages (JSP) compilation options for web modules. This option is only valid if you use the preCompileJSPs option also. The current contents of this option after running default bindings are the following:
  • Web module: xxx
  • URI: xxx
  • JSP Class Path: <jsp class path>
  • Use Full Package Names: Yes | No
  • JDK Source Level: xx
  • Disable JSP Runtime Compilation: Yes | No

For Use Full Package Names and Disable JSP Runtime Compilation, specify a Yes or No value in the language specific for the locale. The product supports the values AppDeploymentOption.Yes and AppDeploymentOption.No instead of Yes and No. However, it is recommended that you specify Yes or No in the language for your locale.

Batch mode example usage

Using Jacl:
$AdminApp install app_server_root/installableApps/ivtApp.ear
 {-appname MyApp -preCompileJSPs -JSPCompileOptions {{"IVT Application"
 ivt_app.war,WEB-INF/web.xml jspcp Yes 15 No}}}
Using Jacl with pattern matching:
$AdminApp install ivtApp.ear {-appname MyApp -preCompileJSPs -JSPCompileOptions
 {{.* .* jspcp Yes 15 No}}}
Using Jython:
AdminApp.install('app_server_root/installableApps/ivtApp.ear',
 ['-appname', 'MyApp', '-preCompileJSPs', '-JSPCompileOptions',
 [["IVT Application", 'ivt_app.war,WEB-INF/web.xml', 'jspcp',
 'Yes', 15, 'No']]])
Using Jython with pattern matching:
AdminApp.install('ivtApp.ear', ['-appname', 'MyApp', '-preCompileJSPs',
 '-JSPCompileOptions', [['.*', '.*', 'jspcp', 'Yes', 15, 'No']]])

JSPReloadForWebMod

The JSPReloadForWebMod option edits the JSP reload attributes for the web module. You can specify the reload attributes of the servlet and JSP for each module. The current contents of the option after running default bindings are the following:
  • Web module: xxx
  • URI: xxx
  • JSP enable class reloading: <Yes | No>
  • JSP reload interval in seconds: <jsp reload internal number>

Use the taskInfo command of the AdminApp object to obtain information about the data needed for your application.

For JSP enable class reloading, specify a Yes or No value in the language specific for the locale. The product supports the values AppDeploymentOption.Yes and AppDeploymentOption.No instead of Yes and No. However, it is recommended that you specify Yes or No in the language for your locale.

Batch mode example usage

Using Jacl:
$AdminApp install app_server_root/installableApps/ivtApp.ear
 {-appname MyApp -JSPReloadForWebMod {{"IVT Application"
 ivt_app.war,WEB-INF/web.xml Yes 5}}}
Using Jacl with pattern matching:
$AdminApp install app_server_root/installableApps/ivtApp.ear
 {-appname MyApp -JSPReloadForWebMod {{.* .* Yes 5}}}
Using Jython:
AdminApp.install('app_server_root/installableApps/ivtApp.ear',
 ['-appname', 'MyApp', '-JSPReloadForWebMod [["IVT Application"
 ivt_app.war,WEB-INF/web.xml Yes 5 ]]'])
Using Jython with pattern matching:
AdminApp.install('app_server_root/installableApps/ivtApp.ear',
 ['-appname', 'MyApp', '-JSPReloadForWebMod', [['.*', '.*', 'Yes', '5']]])
Supported configurations: For IBM® extension and binding files, the .xmi or .xml file name extension is different depending on whether you are using a pre-Java EE 5 application or module or a Java EE 5 or later application or module. An IBM extension or binding file is named ibm-*-ext.xmi or ibm-*-bnd.xmi where * is the type of extension or binding file such as app, application, ejb-jar, or web. The following conditions apply:
  • For an application or module that uses a Java EE version prior to version 5, the file extension must be .xmi.
  • For an application or module that uses Java EE 5 or later, the file extension must be .xml. If .xmi files are included with the application or module, the product ignores the .xmi files.

However, a Java EE 5 or later module can exist within an application that includes pre-Java EE 5 files and uses the .xmi file name extension.

The ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi, and ibm-portlet-ext.xmi files continue to use the .xmi file extensions.

MapEJBRefToEJB

The MapEJBRefToEJB option maps enterprise Java references to enterprise beans. You must map each enterprise bean reference defined in your application to an enterprise bean. Use this option to provide missing data or update to a task.

If the EJB reference is from an EJB 3.x, Web 2.4, or Web 2.5 module, the JNDI name is optional. If you specify the useAutoLink option, the JNDI name is optional. The run time provides a container default. An EJB 3.0 or later module cannot contain container-managed or bean-managed persistence entity beans. Installation fails when a container-managed or bean-managed persistence entity bean is packaged in an EJB 3.x module of a Java EE application. You can only package container-managed or bean-managed persistence beans in an EJB 2.1 or earlier module.

Use the taskInfo command of the AdminApp object to obtain information about the data needed for your application. You only need to provide data for rows or entries that are missing information, or those where you want to update the existing data.

Batch mode example usage

Using Jacl:

$AdminApp install techapp.ear {-MapEJBRefToEJB {{"JAASLogin" "" JAASLoginWeb.war,
WEB-INF/web.xml WSsamples/JAASLogin jaasloginejb.SampleBean TechApp/JAASLogin}}
-MapWebModToVH {{"Web Application" Tech.war,WEB-INF/web.xml default_host}}}

Using Jacl with pattern matching:

[Windows]
$AdminApp install C:/myapp.ear {-MapEJBRefToEJB {{.* .* .* .* .* MyBean}}}
[Linux][AIX][HP-UX][IBM i][Solaris]
$AdminApp install myapp.ear {-MapEJBRefToEJB {{.* .* .* .* .* MyBean}}}
Using Jython:
AdminApp.install('techapp.ear','[
-MapEJBRefToEJB [["JAASLogin" "" JAASLoginWeb.war,WEB-INF/web.xml WSsamples/JAASLogin]]
-MapWebModToVH [["Web Application" tech.war,WEB-INF/web.xml default_host]]]')

Using Jython with pattern matching:

[Windows]
AdminApp.install('C:/myapp.ear', ['-MapEJBRefToEJB',
 [['.*', '.*', '.*', '.*', '.*', 'MyBean']]])
[Linux][AIX][HP-UX][IBM i][Solaris]
AdminApp.install('myapp.ear', ['-MapEJBRefToEJB', 
 [['.*', '.*', '.*', '.*', '.*', 'MyBean']]])

MapEnvEntryForApp

The MapEnvEntryForApp option edits the env-entry value of the application. You can use this option to edit the value of env-entry in the application.xml file.

The current contents of this option after running default bindings are the following:
  • Name: xxx
  • Type: xxx
  • Description: xxx
    Avoid trouble: If after running the default bindings, the value is a null value, you must change the value to .* before you run this task. The .* value is the wildcard value that lets any description be a match. If you leave the value as null, exceptions will occur when you run the MapEnvEntryForApp task.
  • Value: <env-entry value>

Use the taskInfo command of the AdminApp object to obtain information about the data needed for your application.

Batch mode example usage

Using Jacl:
$AdminApp install app_server_root/installableApps/ivtApp.ear
 {-appname MyApp -MapEnvEntryForApp {{MyApp/appEnvEntry String null newEnvEntry}}}
Using Jacl with pattern matching:
$AdminApp install app_server_root/installableApps/ivtApp.ear
 {-appname MyApp2 -MapEnvEntryForApp {{.* .* .* newEnvEntry}}}
Using Jython:
AdminApp.install('app_server_root/installableApps/ivtApp.ear',
 ['-appname', 'MyApp3', '-MapEnvEntryForApp', [['MyApp/appEnvEntry', 'String', 'null', 'newEnvEntry']]])
Using Jython with pattern matching:
AdminApp.install('app_server_root/installableApps/ivtApp.ear',
 ['-appname', 'MyApp4', '-MapEnvEntryForApp', [['.*', '.*', '.*', 'newEnvEntry']]])

If there is a new line character in the description, use the following syntax:

Using Jacl with pattern matching:
$AdminApp install app_server_root/installableApps/ivtApp.ear
 {-appname MyApp5 -MapEnvEntryForApp {{.* .* (?s).* newEnvEntry}}}
Using Jython with pattern matching:
AdminApp.install('app_server_root/installableApps/ivtApp.ear',
 ['-appname', 'MyApp6', '-MapEnvEntryForApp',
 [['.*', '.*', '(?s).*', 'newEnvEntry']]])

MapEnvEntryForClientMod

The MapEnvEntryForClientMod option edits the env-entry value of the client module. You can use this option to edit the value of environment entries in the client module, application-client.xml file.

The current contents of this option after running default bindings are the following:
  • client module: : xxx
  • URI: xxx
  • Name: xxx
  • Type: xxx
  • Description: xxx
  • Value: <env-entry value>

Use the taskInfo command of the AdminApp object to obtain information about the data needed for your client module.

Batch mode example usage

Using Jacl:
$AdminApp install app_server_root/installableApps/myapp.ear
 {-appname MyApp -MapEnvEntryForClientMod {{"Client Module" client.jar,META-INF/application-client.xml
  clientObject String null newValue}}}
Using Jacl with pattern matching:
$AdminApp install myapp.ear {-appname MyApp -MapEnvEntryForClientMod {{.*  .*  .*
  .* .* newValue}}} 
Using Jython:
AdminApp.install('app_server_root/installableApps/myapp.ear',
 ['-appname', 'MyApp', '-MapEnvEntryForClientMod', [["Client Module",
 'client.jar,META-INF/application-client.xml', 'clientObject',
 'String', 'null', 'newValue']]])
Using Jython with pattern matching:
AdminApp.install('myapp.ear', ['-appname', 'MyApp', '-MapEnvEntryForClientMod',
 [['.*', '.*', '.*', '.*', '.*', 'newValue']]]) 

If there is a new line character in the description, use the following syntax:

Using Jacl with pattern matching:
$AdminApp install myapp.ear {-appname MyApp -MapEnvEntryForClientMod {{.* .* .*
 (?s).* newValue}}}
Using Jython with pattern matching:
AdminApp.install('myapp.ear', ['-appname', 'MyApp', '-MapEnvEntryForClientMod',
 [['.*', '.*', '.*', '(?s).*', '*', '*' 'newValue']]])

MapEnvEntryForEJBMod

The MapEnvEntryForEJBMod option edits the env-entry value of the EJB module. You can use this option to edit the value of environment entries in the EJB module, ejb-jar.xml.

The current contents of this option after running default bindings are the following:
  • Module: xxx
  • URI: xxx
  • Bean: xxx
  • Name: xxx
  • Type: xxx
  • Description: xxx
    Avoid trouble: If after running the default bindings, the value is a null value, you must change the value to .* before you run this task. The .* value is the wildcard value that lets any description be a match. If you leave the value as null, WASX7017E and WASX7111E exceptions will occur when you run the MapEnvEntryForEJBMod task.
  • Value: <env-entry value>

If the EJB module uses EJB 3.0 or later, the contents of this option are populated only from the XML deployment descriptor. You cannot get deployment information from annotations with this option.

Use the taskInfo command of the AdminApp object to obtain information about the data needed for your application.

Batch mode example usage

Using Jacl:
$AdminApp install app_server_root/installableApps/ivtApp.ear
 {-appname MyApp -MapEnvEntryForEJBMod {{"IVT EJB Module" ivtEJB.jar,META-INF/ejb-jar.xml
  ivtEJBObject ejb/ivtEJBObject String null newValue}}}
Using Jacl with pattern matching:
$AdminApp install myapp.jar {-appname MyApp -MapEnvEntryForEJBMod {{.*  .*  .*
  .* .* .* newValue}}} 
Using Jython:
AdminApp.install('app_server_root/installableApps/ivtApp.ear',
 ['-appname', 'MyApp', '-MapEnvEntryForEJBMod', [["IVT EJB Module",
 'ivtEJB.jar,META-INF/ejb-jar.xml', 'ivtEJBObject', 'ejb/ivtEJBObject',
 'String', 'null', 'newValue']]])
Using Jython with pattern matching:
AdminApp.install('myapp.ear', ['-appname', 'MyApp', '-MapEnvEntryForEJBMod',
 [['.*', '.*', '.*', '.*', '.*', '.*', 'newValue']]]) 

If there is a new line character in the description, use the following syntax:

Using Jacl with pattern matching:
$AdminApp install myapp.ear {-appname MyApp -MapEnvEntryForEJBMod {{.* .* .*
 (?s).* newValue}}}
Using Jython with pattern matching:
AdminApp.install('myapp.ear', ['-appname', 'MyApp', '-MapEnvEntryForEJBMod',
 [['.*', '.*', '.*', '(?s).*', '*', '*' 'newValue']]])

MapEnvEntryForWebMod

The MapEnvEntryForWebMod option edits the env-entry value of the web module. You can use this option to edit the value of env-entry in the web.xml file.

The current contents of this option after running default bindings are the following:
  • Web module: xxx
  • URI: xxx
  • Name: xxx
  • Type: xxx
  • Description: xxx
    Avoid trouble: If, after running the default bindings, the value is a null value, you must change the value to .* before you run this task. The .* value is the wildcard value that lets any description be a match. If you leave the value as null, WASX7017E and WASX7111E exceptions will occur when you run the MapEnvEntryForWebMod task.
  • Value: <env-entry value>

If the web module uses a Servlet 2.5, the contents of this option are populated only from the XML deployment descriptor. You cannot get deployment information from annotations with this option.

Use the taskInfo command of the AdminApp object to obtain information about the data needed for your application.

Batch mode example usage

Using Jacl:
$AdminApp install app_server_root/installableApps/ivtApp.ear
 {-appname MyApp -MapEnvEntryForWebMod {{"IVT Application" ivt_app.war,
 WEB-INF/web.xml ivt/ivtEJBObject String null newEnvEntry}}}
Using Jacl with pattern matching:
$AdminApp install app_server_root/installableApps/ivtApp.ear
 {-appname MyApp2 -MapEnvEntryForWebMod {{.* .* .* .* newEnvEntry}}}
Using Jython:
AdminApp.install('app_server_root/installableApps/ivtApp.ear',
 ['-appname', 'MyApp3', '-MapEnvEntryForWebMod', [["IVT Application",
 'ivt_app.war,WEB-INF/web.xml', 'ivt/ivtEJBObject', 'String', 'null', 'newEnvEntry']]])
Using Jython with pattern matching:
AdminApp.install('app_server_root/installableApps/ivtApp.ear',
 ['-appname', 'MyApp4', '-MapEnvEntryForWebMod', [['.*', '.*', '.*', '.*', 'newEnvEntry']]])

If there is a new line character in the description, use the following syntax:

Using Jacl with pattern matching:
$AdminApp install app_server_root/installableApps/ivtApp.ear
 {-appname MyApp5 -MapEnvEntryForWebMod {{.* .* .* (?s).* newEnvEntry}}}
Using Jython with pattern matching:
AdminApp.install('app_server_root/installableApps/ivtApp.ear',
 ['-appname', 'MyApp6', '-MapEnvEntryForWebMod',
 [['.*', '.*', '.*', '(?s).*', 'newEnvEntry']]])

MapInitParamForServlet

The MapInitParamForServlet option edits the initial parameter of a web module. You can use this option to edit the initial parameter of a servlet in the web.xml file. The current contents of this option after running the default bindings are the following:
  • Web module: xxx
  • URI: xxx
  • Servlet: xxx
  • Name: xxx
  • Description: null
  • Value: <initial parameter value>
If the web module uses a Servlet 2.5 or later, the contents of this option are populated only from the XML deployment descriptor. You cannot get deployment information from annotations with this option.

Use the taskInfo command of the AdminApp object to obtain information about the data needed for your application.

Batch mode example usage

Using Jacl:
$AdminApp install app_server_root/installableApps/ivtApp.ear
 {-appname MyApp -MapInitParamForServlet {{"IVT Application"
 ivt_app.war,WEB-INF/web.xml ivtservlet pName1 null MyInitParamValue}}} 
Using Jacl with pattern matching:
$AdminApp install myapp.ear {-appname MyApp -MapInitParamForServlet
 {{.*  .*  .*  .*  .*  MyInitParamValue}}}
Using Jython:
AdminApp.install('app_server_root/installableApps/ivtApp.ear',
 ['-appname', 'MyApp', '-MapInitParamForServlet', [["IVT Application",
 'ivt_app.war,WEB-INF/web.xml', 'ivtservlet', 'pName1', 'null', 'MyInitParamValue']]])
Using Jython with pattern matching:
AdminApp.install('myapp.ear', ['-appname', 'MyApp', '-MapInitParamForServlet',
 [['.*', '.*', '.*', '.*', '.*', 'MyInitParamValue']]])

MapJaspiProvider

The MapJaspiProvider option specifies the web application or web modules where you want to override the Java Authentication SPI (JASPI) settings from the global or domain security configuration. The contents of this option are the following:
  • Module: xxx
  • URI: xxx
  • Use JASPI: Yes | No | Inherit
  • JASPI provider name: xxx

For Use JASPI, specify a Yes, No, or Inherit value in the language specific for the locale.

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are missing information or that require an update.

Batch mode example usage

Using Jacl:
$AdminApp install myapp.ear {-MapJaspiProvider {{myapp META-INF/application.xml Yes Provider1} }}
Using Jython:
AdminApp.install('myapp.ear', '[-appname myapp
 -MapJaspiProvider [[myapp META-INF/application.xml Yes Provider1] ]]')

MapMessageDestinationRefToEJB

The MapMessageDestinationRefToEJB option maps message destination references to Java Naming and Directory Interface (JNDI) names of administrative objects from the installed resource adapters. You must map each message destination reference that is defined in your application to an administrative object. Use this option to provide missing data or to update a task.

The current contents of the option after running default bindings include:
  • Module: ejb-jar-ic.jar
  • Bean: MessageBean
  • URI: ejb-jar-ic.jar,META-INF/ejb-jar.xml
  • Message destination object: jms/GSShippingQueue
  • Target Resource JNDI Name: [jms/GSShippingQueue]:
If the message destination reference is from an EJB 3.0 or later module, then the JNDI name is optional and the run time provides a container default.

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are either missing information, or requiring an update.

Batch mode example usage

Using Jacl:
$AdminApp install BankFull.ear {-MapMessageDestinationRefToEJB {{BankCMRQLEJB
 Sender BankCMRQLEJB.jar,META-INF/ejb-jar.xml BankJSQueue BankJSQueue} }}  
Using Jacl with pattern matching:
$AdminApp install $earfile {-MapMessageDestinationRefToEJB {{.*  .*  .*  MyConnection
 jndi2} {.* .*  .*  PhysicalTopic jndi3} {.*  .*  .*  jms/ABC jndi4}}} 
Using Jython:
AdminApp.install('BankFull.ear', '[ -MapMessageDestinationRefToEJB [[ BankCMRQLEJB
 Sender BankCMRQLEJB.jar,META-INF/ejb-jar.xml BankJSQueue BankJSQueue ]]]' )
Using Jython with pattern matching:
AdminApp.install(ear1, ['-MapMessageDestinationRefToEJB', [['.*', '.*', '.*', 'MyConnection', 
 'jndi2'], ['.*', '.*', '.*', 'PhysicalTopic', 'jndi3'], ['.*', '.*', '.*', 'jms/ABC', 'jndi4']]])

MapModulesToServers

The MapModulesToServers option specifies the application server where you want to install modules that are contained in your application. You can install modules on the same server, or disperse them among several servers. Use this option to provide missing data or to update to a task.

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are either missing information, or requiring an update.

Batch mode example usage

The following example installs Increment.jar on one server:

Using Jacl:
$AdminApp install Increment.jar {-MapModulesToServers
 {{"Increment Enterprise Java Bean" Increment.jar,META-INF/ejb-jar.xml
 WebSphere:cell=mycell,node=mynode,server=server1}}}
Using Jython:
AdminApp.install('Increment.jar', '[-MapModulesToServers
 [["Increment Enterprise Java Bean" Increment.jar,META-INF/ejb-jar.xml
 WebSphere:cell=mycell,node=mynode,server=server1] ]]')

The following example removes server1 from the application that is installed:

Using Jacl:
$AdminApp edit myapp {-MapModulesToServers
 {{.* .* -WebSphere:cell=mycell,node=mynode,server=server1}}
 -update -update.ignore.old} 
Using Jython:
AdminApp.edit('myapp', ['-MapModulesToServers',
 [['.*', '.*', '-WebSphere:cell=mycell,node=mynode,server=server1']]]) 

MapResEnvRefToRes

The MapResEnvRefToRes option maps resource environment references to resources. You must map each resource environment reference that is defined in your application to a resource. Use this option to provide missing data or to update a task.

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are either missing information, or requiring an update.

Batch mode example usage

Using Jacl:
$AdminApp install app_server_root/installableApps/sibwsjmsepl.ear {
 -BindJndiForEJBMessageBinding {{ SOAPJMSEndpoint SOAPJMSEndpoint
   SOAPJMSEndpoint.jar,META-INF/ejb-jar.xml lp1 "" "" "" }}
 -MapResEnvRefToRes {{SOAPJMSEndpoint SOAPJMSEndpoint
   SOAPJMSEndpoint.jar,META-INF/ejb-jar.xml jms/WebServicesReplyQCF
   javax.jms.QueueConnectionFactory jndi1}}}
Using Jacl with pattern matching:
$AdminApp install app_server_root/installableApps/sibwsjmsepl.ear {
 -MapResEnvRefToRes {{.* .* .* .* .* jndi1}}}
Using Jython:
AdminApp.install('app_server_root/installableApps/sibwsjmsepl.ear', '[
 -BindJndiForEJBMessageBinding [[ SOAPJMSEndpoint SOAPJMSEndpoint
   SOAPJMSEndpoint.jar,META-INF/ejb-jar.xml lp1 "" "" "" ]]
 -MapResEnvRefToRes [[ SOAPJMSEndpoint SOAPJMSEndpoint
   SOAPJMSEndpoint.jar,META-INF/ejb-jar.xml jms/WebServicesReplyQCF
   javax.jms.QueueConnectionFactory jndi1 ]]]' ) 
Using Jython with pattern matching:
AdminApp.install('app_server_root/installableApps/sibwsjmsepl.ear',
 ['-MapResEnvRefToRes', [['.*', '.*', '.*', '.*', '.*', 'jndi1']]])

MapResRefToEJB

The MapResRefToEJB option maps resource references to resources. You must map each resource reference that is defined in your application to a resource. Use this option to provide missing data or to update a task.

The parameters for MapResRefToEJB include:
  • Module: Ejb1
  • Bean: MailEJBObject
  • URI: deplmtest.jar,META-INF/ejb-jar.xml
  • Resource Reference: jms/MyConnectionFactory
  • Resource type: javax.jms.ConnectionFactory
  • Target Resource JNDI Name: [jms/MyConnectionFactory]:
  • Login Configuration Name: [null]: Use this option to create a custom login configuration. The client can use JAAS to create a login design.
  • Properties: []: Use this option to create a custom login configuration. The client can use JAAS to create a login design.
  • Extended Data source properties: []: Use this option so that a data source that uses heterogeneous pooling can connect to a DB2 database. The pattern for the property is property1=value1+property2=value 2.

The DefaultPrincipalMapping login configuration is used by Java 2 Connectors (J2C) to map users to principals that are defined in the J2C authentication data entries. If the login.config.name is set to DefaultPrincipalMapping, a property is created with the name com.ibm.mapping.authDataAlias. The value of the property is set by the auth.props. If the login.config name is not set to DefaultPrincipalMapping, the auth.props can specify multiple properties. The string format is websphere:name= <name1>,value=<value1>,description=<desc1>. Specify multiple properties using the plus sign (+).

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are either missing information, or requiring an update.

Batch mode example usage

Using Jacl:
$AdminApp install myapp.ear {-MapResRefToEJB 
 {{deplmtest.jar MailEJBObject deplmtest.jar,META-INF/ejb-jar.xml mail/MailSession9
 javax.mail.Session jndi1 login1 authProps1 "clientApplicationInformation=new application"}
 {"JavaMail Sample WebApp" "" mtcomps.war,WEB-INF/web.xml mail/MailSession9 
 javax.mail.Session jndi2 login2 authProps2 ""}}} 
Using Jacl with pattern matching:
$AdminApp install myapp.ear {-MapResRefToEJB 
 {{deplmtest.jar .*  .*  .*  .*  jndi1 login1 authProps1
 "clientApplicationInformation=new application"}
 {"JavaMail Sample WebApp" .*  .*  .*  .*  jndi2 login2 authProps2 ""}}}
Note: If you use multiple values for extended data source properties, you must assign the values to a variable and use that variable for the property value. For example:
set s \"value1,value2\"
In the command substitution, reference the variable as shown in the following example:
"clientApplicationInformation=value1,value2" with "clientapplication=$s"
Using Jython:
AdminApp.install('myapp.ear', ['-MapResRefToEJB', 
 [['deplmtest.jar', 'MailEJBObject', 'deplmtest.jar,META-INF/ejb-jar.xml
 mail/MailSession9', 'javax.mail.Session', 'jndi1', 'login1', 'authProps1',
 'clientApplicationInformation=new application+clientWorkstation=9.10.117.65'],
 ["JavaMail Sample WebApp", "", 'mtcomps.war,WEB-INF/web.xml', 'mail/MailSession9',
 'javax.mail.Session', 'jndi2', 'login2', 'authProps2', '']]]) 
Using Jython with pattern matching:
AdminApp.install('myapp.ear', ['-MapResRefToEJB', 
 [['deplmtest.jar', '.*', '.*', '.*', '.*', 'jndi1', 'login1', 'authProps1',
 'clientApplicationInformation=new application+clientWorkstation=9.10.117.65'],
 ["JavaMail Sample WebApp", '', '.*', '.*', '.*', 'jndi2', 'login2',
 'authProps2', '']]])
Note: If you use multiple values for extended data source properties, surround the two values with double quote characters. For example:
'property1="value1,value2"+property2="value3,value4"'

MapRolesToUsers

The MapRolesToUsers option maps users to roles. You must map each role that is defined in the application or module to a user or group from the domain user registry. You can specify multiple users or groups for a single role by separating them with a pipe (|); for example, user1|user2. Use this option to provide missing data or to update a task.

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are either missing information, or requiring an update.

Batch mode example usage

Using Jacl:
$AdminApp install myapp.ear {-MapRolesToUsers {{"All Role" No Yes "" ""}
 {"Every Role" Yes No "" ""} {DenyAllRole No No user1 group1}}}
Using Jython:
AdminApp.install('myapp.ear', '[-MapRolesToUsers [["All Role" No Yes "" ""]
 ["Every Role" Yes No "" ""] [DenyAllRole No No user1 group1]]]')

where {{"All Role" No Yes "" ""} corresponds to the following:

Table 2. MapRolesToUsers option descriptions. Map each role to a user or group.
Option Description
"All Role" Represents the role name
No Indicates to allow access to everyone (yes/no)
Yes Indicates to allow access to all authenticated users (yes/no)
"" Indicates the mapped users
"" Indicates the mapped groups
"AllAuthenticatedInTrustedRealms" Indicates that any valid user in the trusted realms be given the access.
"Mapped users access ids" Indicates the mapped users access ids
"Mapped groups access ids" Indicates the mapped groups access ids

MapRunAsRolesToUsers

The MapRunAsRolesToUsers option maps RunAs Roles to users. The enterprise beans that you install contain predefined RunAs roles. Enterprise beans that need to run as a particular role for recognition while interacting with another enterprise bean use RunAs roles. Use this option to provide missing data or to update a task.

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are either missing information, or requiring an update.

Batch mode example usage

Using Jacl:

[Windows]
$AdminApp install C:/myapp.ear {-MapRunAsRolesToUsers {{UserRole user1 
 password1} {AdminRole administrator administrator}}}
[Linux][AIX][HP-UX][IBM i][Solaris]
$AdminApp install myapp.ear {-MapRunAsRolesToUsers {{UserRole user1
 password1} {AdminRole administrator administrator}}}

Using Jython:

[Windows]
AdminApp.install('C:/myapp.ear', '[-MapRunAsRolesToUsers [[UserRole user1 
 password1] [AdminRole administrator administrator]]]')
[Linux][AIX][HP-UX][IBM i][Solaris]
AdminApp.install('myapp.ear', '[-MapRunAsRolesToUsers [[UserRole user1
 password1][AdminRole administrator administrator]]]')

MapSharedLibForMod

The MapSharedLibForMod option assigns shared libraries to application or every module. You can associate multiple shared libraries to applications and modules. The current contents of this option after running default bindings are the following:
  • Module: xxx
  • URI: META-INF/application.xml
  • Shared libraries: <share libraries>

Use the taskInfo command of the AdminApp object to obtain information about the data needed for your application.

Batch mode example usage

Using Jacl:
$AdminApp install app_server_root/installableApps/DynaCacheEsi.ear
 {-appname DynaCacheEsi -MapSharedLibForMod {{ DynaCacheEsi META-INF/application.xml
 sharedlib1 }{ DynaCacheEsi DynaCacheEsi.war,WEB-INF/web.xml sharedlib2 }}}
Using Jacl with pattern matching:
$AdminApp install app_server_root/installableApps/DynaCacheEsi.ear
 {-appname DynaCacheEsi -MapSharedLibForMod {{ .* .* sharedlib1 }
 { .* .* sharedlib2 }}}
Using Jython:
AdminApp.install('app_server_root/installableApps/DynaCacheEsi.ear',
 '[ -MapSharedLibForMod [[ DynaCacheEsi META-INF/application.xml sharedlib1 ]
 [ DynaCacheEsi DynaCacheEsi.war,WEB-INF/web.xml sharedlib2 ]]]' )
Using Jython with pattern matching:
AdminApp.install('app_server_root/installableApps/DynaCacheEsi.ear',
 '[ -MapSharedLibForMod [[ .* .* sharedlib1 ][ .* .* sharedlib2 ]]]' )

MapWebModToVH

The MapWebModToVH option selects virtual hosts for web modules. Specify the virtual host where you want to install the web modules that are contained in your application. You can install web modules on the same virtual host, or disperse them among several hosts. Use this option to provide missing data or to update a task.

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application. You need to provide data for rows or entries that are either missing information, or requiring an update.

Batch mode example usage

Using Jacl:
$AdminApp install app_server_root/installableApps/DynaCacheEsi.ear
 {-appname DynaCacheEsi
 -MapWebModToVH {{ DynaCacheEsi DynaCacheEsi.war,WEB-INF/web.xml default_host }}}
Using Jacl with pattern matching:
$AdminApp install app_server_root/installableApps/DynaCacheEsi.ear
 {-MapWebModToVH {{ .* .* default_host }}}
Using Jython:
AdminApp.install('app_server_root/installableApps/DynaCacheEsi.ear',
 '[-MapWebModToVH [[ DynaCacheEsi DynaCacheEsi.war,WEB-INF/web.xml default_host ]]]') 
Using Jython with pattern matching:
AdminApp.install('app_server_root/installableApps/DynaCacheEsi.ear',
 ['-MapWebModToVH', [['.*', '.*', 'default_host']]])

MetadataCompleteForModules

The MetadataCompleteForModules option enables each Java EE 5 or later module to write out the complete deployment descriptor, including deployment information from annotations. Then the system marks the deployment descriptor for the module as complete.

Avoid trouble: If your Java EE 5 or later application uses annotations and a shared library, do not use this option. When your application uses annotations and a shared library, setting the metadata-complete attribute to true causes the product to incorrectly represent an @EJB annotation in the deployment descriptor as <ejb-ref> rather than <ejb-local-ref>. For web modules, setting the metadata-complete attribute to true might cause InjectionException errors. If you must set the metadata-complete attribute to true, avoid errors by not using a shared library, by placing the shared library in either the classes or lib directory of the application server, or by fully specifying the metadata in the deployment descriptors.
The current contents of this option after running default bindings are the following:
  • Module: EJBDD_1.jar
  • URI: EJBDD_1.jar,META-INF/ejb-jar.xml
  • Lock deployment descriptor: [false]:
  • Module: EJBNoDD_2.jar
  • URI: EJBNoDD_2.jar,META-INF/ejb-jar.xml
  • Lock deployment descriptor: [false]:

Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application.

Batch mode example usage

Using Jacl:

[Windows]
$AdminApp install c:/myapp.ear {-MetadataCompleteForModules
 {{EJBDD_1.jar EJBDD_1.jar,META-INF/ejb-jar.xml false}}}
[Linux][AIX][HP-UX][IBM i][Solaris]
$AdminApp install myapp.ear {-MetadataCompleteForModules
 {{EJBDD_1.jar EJBDD_1.jar,META-INF/ejb-jar.xml false}}}

Using Jacl with pattern matching:

[Windows]
$AdminApp install c:/myapp.ear {-MetadataCompleteForModules
 {{.* EJBDD_1.jar,.* false}}}
[Linux][AIX][HP-UX][IBM i][Solaris]
$AdminApp install myapp.ear 
 {-MetadataCompleteForModules {{.* EJBDD_1.jar,.* false}}}

Using Jython:

[Windows]
AdminApp.install('c:/myapp.ear', ['-MetadataCompleteForModules', 
 [['EJBDD_1,jar',  'EJBDD_1.jar,META-INF/ejb-jar.xml', 'false']]])
[Linux][AIX][HP-UX][IBM i][Solaris]
AdminApp.install('myapp.ear', ['-MetadataCompleteForModules',
 [['EJBDD_1,jar',  'EJBDD_1.jar,META-INF/ejb-jar.xml', 'false']]])

Using Jython with pattern matching:

[Windows]
AdminApp.install('c:/myapp.ear', ['-MetadataCompleteForModules', [['.*',
 'EJBDD_1.jar,.*', 'false']]]
[Linux][AIX][HP-UX][IBM i][Solaris]
AdminApp.install('myapp.ear', 
 ['-MetadataCompleteForModules', [['.*', 'EJBDD_1.jar,.*', 'false']]]

ModuleBuildID

The ModuleBuildID option displays the build identifier of a module in an application EAR file. You cannot modify this option because it is read-only. This option returns the build information for a module if you have specified the build identifier in the MANIFEST.MF of a module or application EAR file. The build information consists of the module name, module URI, and build identifier.

The current contents of the option after running default bindings resemble the following:
  • Module: CacheClient
  • URI: CacheClient.jar,META-INF/application-client.xml
  • Build ID: alpha
  • Module: MailConnector
  • URI: Mail.rar,META-INF/ra.xml
  • Build ID: abc
  • Module: CacheWeb1
  • URI: CacheWeb1.war,WEB-INF/web.xml
  • Build ID: alpha
  • Module: JspWeb1
  • URI: JspWeb1.war,WEB-INF/web.xml
  • Build ID: v1.0
  • Module: Servlet
  • URI: Servlet.war,WEB-INF/web.xml
  • Build ID: 0.5

Batch mode example usage

Using Jython:

[Windows]
print AdminApp.taskInfo('c:/temp/Cache2.ear', 'ModuleBuildID')
[Linux][AIX][HP-UX][IBM i][Solaris]
print AdminApp.taskInfo('/temp/Cache2.ear', 'ModuleBuildID')

noallowDispatchRemoteInclude

The noallowDispatchRemoteInclude option disables the enterprise application that dispatches includes to resources across web modules in different Java virtual machines in a managed node environment through the standard request dispatcher mechanism.

noallowPermInFilterPolicy

The noallowPermInFilterPolicy option specifies not to continue with the application deployment process when the application contains policy permissions that are in the filter policy. This option is the default setting and does not require a value.

noallowServiceRemoteInclude

The noallowServiceRemoteInclude option disables the enterprise application that services an include request from an enterprise application that has the allowDispatchRemoteInclude option set to true.

node

The node option specifies the node name to install or update an entire application or to update an application in order to add a new module. If you want to update an entire application, this option only applies if the application contains a new module that does not exist in the installed application.

Batch mode example usage

Using Jacl:

[Windows]
$AdminApp install "C:/myapp.ear" {-node nodeName}
[Linux][AIX][HP-UX][IBM i][Solaris]
$AdminApp install "/myapp.ear" {-node nodeName}

Using Jython:

[Windows]
AdminApp.install('C:/myapp/myapp.ear', '[-node nodeName]')
[Linux][AIX][HP-UX][IBM i][Solaris]
AdminApp.install('/myapp/myapp.ear', '[-node nodeName]')

nocreateMBeansForResources

The nocreateMBeansForResources option specifies that MBeans are not created for all resources, such as servlets, JavaServer Pages files, and enterprise beans, that are defined in an application when the application starts on a deployment target. This option is the default setting and it does not require a value.

nodeployejb

The nodeployejb option specifies not to run the EJBDeploy tool during installation. This option is the default setting and does not require a value.

nodeployws

The nodeployws option specifies not to deploy web services during installation. This option is the default setting and does not require a value.

nodistributeApp

The nodistributeApp option specifies that the application management component does not distribute application binaries. This option does not require a value. The default setting is the distributeApp option.

noenableClientModule

The noenableClientModule option specifies not to deploy client modules. This option does not require a value. This is the default. The default is not to deploy client modules. Use the enableClientModule option to deploy client modules.

noreloadEnabled

The noreloadEnabled option disables class reloading. This option is the default setting and does not require a value. To specify that the file system of the application be scanned for updated files so that changes reload dynamically, use the reloadEnabled option.

nopreCompileJSPs

The nopreCompileJSPs option specifies not to precompile JavaServer Pages files. This option is the default setting and does not require a value.

noprocessEmbeddedConfig

The noprocessEmbeddedConfig option specifies that the system should ignore the embedded configuration data that is included in the application. This option does not require a value. If the application enterprise archive (EAR) file does not contain embedded configuration data, the noprocessEmbeddedConfig option is the default setting. Otherwise, the default setting is the processEmbeddedConfig option.

nouseAutoLink

The nouseAutoLink option specifies not to use the useAutoLink option, and not to automatically resolve Enterprise JavaBeans (EJB) references from EJB module versions prior to EJB 3.0 and from web module versions that are prior to Version 2.4.

nouseMetaDataFromBinary

The nouseMetaDataFromBinary option specifies that the metadata that is used at run time, for example, deployment descriptors, bindings, extensions, and so on, come from the configuration repository. This option is the default setting and does not require a value. Use this option to indicate that the metadata that is used at run time comes from the enterprise archive (EAR) file.

nousedefaultbindings

The nousedefaultbindings option specifies not to use default bindings for installation. This option is the default setting and does not require a value.

novalidateSchema

The novalidateSchema option specifies not to validate the deployment descriptors against published Java EE deployment descriptor schemas. This option does not require a value. This is the default. The default is not to validate deployment descriptors.

operation

The operation option specifies the operation that you want to perform. This option only applies to the update or updateInteractive commands. The valid values include:
  • add - Adds new content.
  • addupdate - Adds or updates content based on the existence of content in the application.
  • delete - Deletes content.
  • update - Updates existing content.

The operation option is required if the content type is file or modulefile. If the value of the content type is app, the value of the operation option must be update. The contenturi option is ignored when the content type is app.

Batch mode example usage

The following examples show how to use the options for the update command to update an entire deployed enterprise application:

Using Jacl:
$AdminApp update "IVT Application" app {-operation update
 -contents app_server_root/installableApps/ivtApp.ear}
Using Jython string:
AdminApp.update('IVT Application', 'app', '[ -operation update
 -contents app_server_root/installableApps/ivtApp.ear ]' )

The following examples show how to use the options for the update command to update a single file in a deployed application:

Using Jacl:

[Windows]
$AdminApp update app1 file {-operation update -contents 
 C:/apps/app1/my.xml -contenturi app1.jar/my.xml}
[Linux][AIX][HP-UX][IBM i][Solaris]
$AdminApp update app1 file {-operation update 
 -contents /apps/app1/my.xml -contenturi app1.jar/my.xml}

Using Jython string:

[Windows]
AdminApp.update('app1', 'file', '[-operation update -contents 
 C:/apps/app1/my.xml -contenturi app1.jar/my.xml]')
[Linux][AIX][HP-UX][IBM i][Solaris]
AdminApp.update('app1', 'file', '[-operation update 
 -contents /apps/app1/my.xml -contenturi app1.jar/my.xml]')

Using Jython list:

[Windows]
AdminApp.update('app1', 'file', ['-operation', 'update', '-contents', 
 'C:/apps/app1/my.xml', '-contenturi', app1.jar/my.xml'])
[Linux][AIX][HP-UX][IBM i][Solaris]
AdminApp.update('app1', 'file', ['-operation',  'update', '-contents',
 '/apps/app1/my.xml', '-contenturi', app1.jar/my.xml'])

where AdminApp is the scripting object, update is the command, app1 is the name of the application you want to update, file is the content type, operation is an option of the update command, update is the value of the operation option, contents is an option of the update command, /apps/app1/my.xml is the value of the contents option, contenturi is an option of the update command, app1.jar/my.xml is the value of the contenturi option.

processEmbeddedConfig

The processEmbeddedConfig option processes the embedded configuration data that is included in the application. This option does not require a value. If the application enterprise archive (EAR) file contains embedded configuration data, this option is the default setting. If not, the default setting is the nonprocessEmbeddedConfig option.

This setting affects installation of enhanced EAR files. An enhanced EAR file results when you export an installed application. Enhanced EAR files have an embedded configuration that consists of files such as resource.xml and variables.xml. This option loads an embedded configuration to the application scope from the EAR file.

If you exported the application from a cell other than the current cell and did not specify the $(CELL) variable for the installed.ear.destination option when first installing the application, use the nonprocessEmbeddedConfig option to expand the enhanced EAR file in the profile_root/installedApps/current_cell_name directory. Otherwise, use this processEmbeddedConfig option to expand the enhanced EAR file in the profile_root/installedApps/original_cell_name directory, where original_cell_name is the cell on which the application was first installed. If you specified the $(CELL) variable for the installed.ear.destination option when you first installed the application, installation expands the enhanced EAR file in the profile_root/installedApps/current_cell_name directory.

preCompileJSPs

The preCompileJSPs option specifies to precompile the JavaServer Pages files. This option does not require a value. The default value is nopreCompileJSPs. If you want to precompile JavaServer Pages files, specify it as a part of installation. The default is not to precompile JavaServer Pages files. The preCompileJSPs option is ignored during deployment and JavaServer Pages files are not precompiled. The flag is set automatically using assembly tools.

For this option, install only onto a Version 9.0 deployment target, which has the same or higher Java SDK level than the deployment manager.

reloadEnabled

The reloadEnabled option specifies that the file system of the application will be scanned for updated files so that changes reload dynamically. If this option is enabled and if application classes are changed, then the application is stopped and restarted to reload updated classes. This option is not the default setting and does not require a value. The default setting is the noreloadEnabled option.

reloadInterval

The reloadInterval option specifies the time period in seconds that the file system of the application will be scanned for updated files. Valid range is greater than zero. The default is three seconds.

SharedLibRelationship

The SharedLibRelationship option assigns assets or composition unit IDs as shared libraries for each Java EE module.

The current contents of the option after running default bindings include:
  • Module: EJB3BNDBean.jar
  • URI: EJB3BNDBean.jar,META-INF/ejb-jar.xml
  • Relationship IDs: specify asset or composition unit IDs, such as [WebSphere:cuname=sharedLibCU1,cuedition=1.0] or WebSphere:assetname=sharedLibAsset1.jar
  • Composition Unit names: optionally specify composition unit names for asset relationship IDs. The system uses the same name as the asset if you do not specify a composition unit name. []
  • Match target: [Yes]:
You can specify assets and composition unit IDs in the relationship, as the following guidelines explain:
  • If you specify an asset, the system creates a composition unit with that asset in the same business level application where the Java EE application belongs.
  • If you specify a value for the composition unit names, then the system position matches each name with the corresponding relationship IDs values.
  • If the relationship ID is a composition unit ID, then the system ignores the corresponding composition unit name.
  • If the relationship ID is an asset ID, then the system creates the composition unit using the corresponding composition unit name.

To specify more than one asset or composition unit ID, separate each value with the plus sign character (+).

When using the edit command for the Java EE application, you can override the relationship with a new set of composition unit relationship IDs, or you can add or remove existing composition unit relationships. You cannot specify an asset relationship when using the edit command. Specify the first character of the composition unit ID as the plus sign character (+) to add to the relationship, or specify the number sign character (#) to remove the composition unit ID from existing relationships. For example, the +cuname=cu2.zip composition unit syntax adds the cu2 composition unit to the relationship. The #cuname=cu1.zip+cuname=cu2.zip composition unit syntax removes the cu1 and cu2 composition units from the relationship.

Batch mode example usage

Using Jacl:

$AdminApp install myapp.ear {-SharedLibRelationship {{EJB3BNDBean.jar 
 EJB3BNDBean.jar,META-INF/ejb-jar.xml WebSphere:cuname=sharedLibCU1 "" Yes}}}

Using Jacl with pattern matching:

$AdminApp install myapp.ear {-SharedLibRelationship {{.*
 EJB3BNDBean.jar,.* WebSphere:cuname=sharedLibCU1 "" Yes}}}

Using Jython:

AdminApp.install('myapp.ear', ['-SharedLibRelationship',
 [['EJB3BNDBean,jar', 'EJB3BNDBean.jar,META-INF/ejb-jar.xml',
 'WebSphere:cuname=sharedLibCU1,' '', 'Yes']]])

Using Jython with pattern matching:

AdminApp.install('myapp.ear', ['-SharedLibRelationship', [['.*',
 'EJB3BNDBean.jar,.*', 'WebSphere:cuname=sharedLibCU1', '', 'Yes']]]

server

The server option specifies the name of the server on which you want to perform one of the following actions:
  • Install a new application.
  • Replace an existing application with an updated version of that application. In this situation, the server option is meaningful only if the updated version of the application contains a new module that does not exist in the already installed version of the application.
  • Add a new module to an existing application.

Batch mode example usage

Using Jacl:

$AdminApp install app_server_root/installableApps/DynaCacheEsi.ear
 {-server server1}

Using Jython:

AdminApp.install('app_server_root/installableApps/DynaCacheEsi.ear',
 '[-server server1]')

target

The target option specifies the target for the installation functions of the AdminApp object. The following is an example of a target option: WebSphere:cell=mycell,node=mynode,server=myserver

You can specify multiple targets by delimiting them with a plus (+) sign. By default, the targets that you specify when you install or edit an application replace the existing target definitions in the application. You can use a leading plus (+) sign to add targets or a negative (-) sign to remove targets without having to specify the targets that are not changed.
Note: The full target mapping syntax has to be used with the MapModulesToServers option when multiple domains are used. You cannot use leading + sign to add a new target with the MapModulesToServers option when multiple domains are used; the runtime is not able to correctly resolve the domains mapped to the deployment targets.

Batch mode example usage

The following example specifies server1 as the target server for the application installation:

Using Jacl:

$AdminApp install app_server_root/installableApps/DynaCacheEsi.ear
 {-appname MyApp -target WebSphere:cell=myCell,node=myNode,server=server1}

Using Jython:

AdminApp.install("app_server_root/installableApps/DynaCacheEsi.ear",
 ["-appname", "MyApp", "-target", "WebSphere:cell=myCell,node=myNode,server=server1"])

update

The update option updates the installed application with a new version of the enterprise archive (EAR) file. This option does not require a value.

The application to update, which is specified by the appname option, must already be installed in the WebSphere® Application Server configuration. The update action merges bindings from the new version with the bindings from the old version, uninstalls the old version, and installs the new version. The binding information from new version of the EAR file or module is preferred over the corresponding one from the old version. If any element of binding is missing in the new version, the corresponding element from the old version is used.

update.ignore.new

The update.ignore.new option specifies that during the update action, binding information from the old version of the application or module is preferred over the corresponding binding information from the new version. If any element of the binding does not exist in the old version, the element from the new version is used. That is, bindings from the new version of the application or module are ignored if a binding exists in the old version. Otherwise, the new bindings are honored and not ignored. This option does not require a value.

This option applies only if you specify one of the following items:
  • The update option for the install command.
  • The modulefile or app as the content type for the update command.

update.ignore.old

The update.ignore.old option specifies that during the update action, the binding information from the new version of the application or module is preferred over the corresponding binding information from the old version. The bindings from the old version of the application or module are ignored. This option does not require a value. This option applies only if you specify one of the following items:
  • The update option for the install command.
  • The modulefile or app as the content type for the update command.

useAutoLink

Use the useAutoLink option to automatically resolve Enterprise JavaBeans (EJB) references from EJB module versions prior to EJB 3.0, and from web module versions that are prior to Version 2.4. If you enable the useAutoLink option, you can optionally specify the JNDI name for MapEJBRefToEJB option. Each module in the application must share one common target to enable autolink support.

Batch mode example usage

Using Jacl:

[Windows]
$AdminApp install C:/myapp.ear {-useAutoLink} 
[Linux][AIX][HP-UX][IBM i][Solaris]
$AdminApp install /myapp.ear {-useAutoLink} 

Using Jython:

[Windows]
AdminApp.install('C:/myapp.ear','[-useAutoLink]') 
[Linux][AIX][HP-UX][IBM i][Solaris]
AdminApp.install('myapp.ear','[-useAutoLink]') 

usedefaultbindings

The usedefaultbindings option specifies to use default bindings for installation. This option does not require a value. The default setting is nousedefaultbindings.

To use the existing listener port instead of using or creating a new activation specification, determine whether the EJB JAR version is earlier than 2.1. The system automatically creates and uses an activation specification when you specify the -usedefaultbindings option to deploy an application. If an activation specification exists, the system ignores the listener port, and instead uses the activation specification. To deploy an application with an EJB JAR version greater than or equal to 2.1 using the defined listener ports instead of a new activation specification, set the com.ibm.websphere.management.application.dfltbndng.mdb.preferexisting system property to true in the wsadmin.properties file in the properties directory of the profile of interest.

useMetaDataFromBinary

The useMetaDataFromBinary option specifies that the metadata that is used at run time, for example, deployment descriptors, bindings, extensions, and so on, come from the EAR file. This option does not require a value. The default value is nouseMetaDataFromBinary, which means that the metadata that is used at run time comes from the configuration repository.

validateinstall

The validateinstall option specifies the level of application installation validation. Valid option values include:
  • off - Specifies no application deployment validation. This value is the default.
  • warn - Performs application deployment validation and continues with the application deployment process even when reported warnings or error messages exist.
  • fail - Performs application deployment validation and does not to continue with the application deployment process when reported warnings or error messages exist.

validateSchema

The validateSchema option specifies to validate the deployment descriptors against published Java EE deployment descriptor schemas. When this application deployment option is selected, the product analyzes each deployment descriptor to determine the Java EE specification version for the deployment descriptor, selects the appropriate schema, and then checks the deployment descriptor against the Java EE deployment descriptor schema. Validation errors result in error messages.

This option does not require a value. The default value is novalidateSchema. By default, the validateSchema option is ignored during deployment and the product does not validate deployment descriptors.

verbose

The verbose option causes additional messages to display during installation. This option does not require a value.

WebServicesClientBindDeployedWSDL

The WebServicesClientBindDeployedWSDL option identifies the client web service that you are modifying. The scoping fields include: Module, EJB, and web service. The single mutable value for this task is the deployed WSDL file name. It indicates the Web Services Description Language (WSDL) the client uses.

The Module field identifies the enterprise or web application within the application. If the module is an enterprise bean , the EJB field identifies a particular enterprise bean within the module. The web service field identifies the web service within the enterprise bean or the web application module. This identifier corresponds to the wsdl:service attribute in the WSDL file, which has a prefix of service/; for example, service/WSLoggerService2.

The deployed WSDL attribute names a WSDL file relative to the client module. An example of a deployed WSDL for a web application is the following: WEB-INF/wsdl/WSLoggerService.

Batch mode example usage

Using Jacl:
$AdminApp install WebServicesSamples.ear {-WebServicesClientBindDeployedWSDL {{AddressBookW2JE.jar 
 AddressBookW2JE service/WSLoggerService2 META-INF/wsdl/DeployedWsdl1.wsdl}}} 
Using Jacl with pattern matching:
$AdminApp install WebServicesSamples.ear {-WebServicesClientBindDeployedWSDL {{.*  .*  .*  
 META-INF/wsdl/DeployedWsdl1.wsdl}}}
The following example illustrates the BindJndiForEJBNonMessageBinding, Hermaphrodite, and the WebServicesClientBindDeployedWSDL options:
$AdminApp install WebServicesSamples.ear {
-WebServicesClientBindDeployedWSDL {{AddressBookW2JE.jar AddressBookW2JE service/WSLoggerService2
 META-INF/wsdl/DeployedWsdl1.wsdl}} 
-BindJndiForEJBNonMessageBinding {{ "Stock Quote Sample EJB"
 com_ibm_websphere_samples_webservices_stock_StockQuote StockQuote.jar,META-INF/ejb-jar.xml 
jndi1 "" "" } { "Address Book Sample EJB" com_ibm_websphere_samples_webservices_addr_AddressBookW2JE
 AddressBookW2JE.jar,META-INF/ejb-jar.xml jndi2 "" "" }{ "Address Book Sample EJB"
 com_ibm_websphere_samples_webservices_addr_AddressBookJ2WE AddressBookJ2WE.jar,META-INF/ejb-jar.xml
 jndi3 "" "" }} 
-MapWebModToVH {{ "module_name" web_services.war,WEB-INF/web.xml default_host }
 { "AddressBook Bottom Up Java Bean" AddressBookJ2WB.war,WEB-INF/web.xml default_host }
 { "AddressBook Top Down Java Bean" AddressBookW2JB.war,WEB-INF/web.xml default_host }} } 
Using Jython:
AdminApp.install('WebServicesSamples.ear', '[-WebServicesClientBindDeployedWSDL 
 [[AddressBookW2JE.jar AddressBookW2JE service/WSLoggerService2 META-INF/wsdl/DeployedWsdl1.wsdl]]]') 
To install the WebServicesSamples.ear sample, you must specify the BindJndiForEJBNonMessageBinding and MapWebModToVH options as well as the WebServicesClientBindDeployedWSDL option:
$AdminApp install WebServicesSamples.ear', '[ 
-WebServicesClientBindDeployedWSDL [[ AddressBookW2JE.jar AddressBookW2JE service/WSLoggerService2
 META-INF/wsdl/DeployedWsdl1.wsdl ]] 
-BindJndiForEJBNonMessageBinding [[ "Stock Quote Sample EJB"
 com_ibm_websphere_samples_webservices_stock_StockQuote StockQuote.jar,META-INF/ejb-jar.xml 
jndi1 "" "" ] [ "Address Book Sample EJB" com_ibm_websphere_samples_webservices_addr_AddressBookW2JE
 AddressBookW2JE.jar,META-INF/ejb-jar.xml jndi2 "" "" ][ "Address Book Sample EJB"
 com_ibm_websphere_samples_webservices_addr_AddressBookJ2WE AddressBookJ2WE.jar,META-INF/ejb-jar.xml
 jndi3 "" "" ]] 
-MapWebModToVH [[ "module_name" web_services.war,WEB-INF/web.xml default_host ]
 [ "AddressBook Bottom Up Java Bean" AddressBookJ2WB.war,WEB-INF/web.xml default_host ]
 [ "AddressBook Top Down Java Bean" AddressBookW2JB.war,WEB-INF/web.xml default_host ]]]' ) 
Using Jython with pattern matching:
AdminApp.install('WebServicesSamples.ear', ['-WebServicesClientBindDeployedWSDL',
['.*', '.*', '.*',  'META-INF/wsdl/DeployedWsdl1.wsdl']]])

WebServicesClientBindPortInfo

The WebServicesClientBindPortInfo option identifies the port of a client web service that you are modifying. The scoping fields include: Module, EJB, web service and Port. The mutable values for this task include: Sync Timeout, BasicAuth ID, BasicAuth Password, SSL Config, and Overridden Endpoint URI. The basic authentication and Secure Sockets Layer (SSL) fields affect transport level security, not Web Services Security.

Batch mode example usage

Using Jacl:
$AdminApp install WebServicesSamples.ear {-WebServicesClientBindPortInfo {{AddressBookW2JE.jar 
 AddressBookW2JE service/WSLoggerService2 WSLoggerJMS 3000 newHTTP_ID newHTTP_pwd sslAliasConfig 
 http://yunus:9090/WSLoggerEJB/services/WSLoggerJMS}}} 
To install the WebServicesSamples.ear sample, you must specify the BindJndiForEJBNonMessageBinding and MapWebModToVH options as well as the WebServicesClientBindPortInfo option:
$AdminApp install WebServicesSamples.ear {
-WebServicesClientBindPortInfo {{AddressBookW2JE.jar AddressBookW2JE service/WSLoggerService2
 WSLoggerJMS 3000 newHTTP_ID newHTTP_pwd sslAliasConfig
 http://yunus:9090/WSLoggerEJB/services/WSLoggerJMS}} 
-BindJndiForEJBNonMessageBinding {{ "Stock Quote Sample EJB"
 com_ibm_websphere_samples_webservices_stock_StockQuote StockQuote.jar,META-INF/ejb-jar.xml
 jndi1 "" "" }
 { "Address Book Sample EJB" com_ibm_websphere_samples_webservices_addr_AddressBookW2JE
 AddressBookW2JE.jar,META-INF/ejb-jar.xml jndi2 "" "" }{ "Address Book Sample
 EJB" com_ibm_websphere_samples_webservices_addr_AddressBookJ2WE AddressBookJ2WE.jar,META-INF/ejb-jar.xml
 jndi3 "" "" }} 
-MapWebModToVH {{ "module_name" web_services.war,WEB-INF/web.xml default_host }
 { "AddressBook Bottom Up Java Bean" AddressBookJ2WB.war,WEB-INF/web.xml default_host }
 { "AddressBook Top Down Java Bean" AddressBookW2JB.war,WEB-INF/web.xml default_host }} } 
Using Jacl with pattern matching:
$AdminApp install WebServicesSamples.ear {-WebServicesClientBindPortInfo {{.*  .*  .*  .*  3000 
 newHTTP_ID newHTTP_pwd sslAliasConfig http://yunus:9090/WSLoggerEJB/services/WSLoggerJMS}}}
Using Jython:
AdminApp.install('WebServicesSamples.ear', '[-WebServicesClientBindPortInfo
 [[AddressBookW2JE.jar AddressBookW2JE service/WSLoggerService2 WSLoggerJMS 3000 newHTTP_ID
 newHTTP_pwd sslAliasConfig http://yunus:9090/WSLoggerEJB/services/WSLoggerJMS]]]') 
To install the WebServicesSamples.ear sample, you must specify the BindJndiForEJBNonMessageBinding and MapWebModToVH options as well as the WebServicesClientBindPortInfo option:
AdminApp.install('WebServicesSamples.ear', '[ 
-WebServicesClientBindPortInfo [[AddressBookW2JE.jar AddressBookW2JE service/WSLoggerService2 WSLoggerJMS
 3000 newHTTP_ID newHTTP_pwd sslAliasConfig http://yunus:9090/WSLoggerEJB/services/WSLoggerJMS ]] 
-BindJndiForEJBNonMessageBinding [[ "Stock Quote Sample EJB"
 com_ibm_websphere_samples_webservices_stock_StockQuote StockQuote.jar,META-INF/ejb-jar.xml jndi1 "" "" ]
 [ "Address Book Sample EJB" com_ibm_websphere_samples_webservices_addr_AddressBookW2JE
 AddressBookW2JE.jar,META-INF/ejb-jar.xml jndi2 "" "" ][ "Address Book Sample EJB"
 com_ibm_websphere_samples_webservices_addr_AddressBookJ2WE AddressBookJ2WE.jar,META-INF/ejb-jar.xml
 jndi3 "" "" ]] 
-MapWebModToVH [[ "module_name" web_services.war,WEB-INF/web.xml default_host ]
 [ "AddressBook Bottom Up Java Bean" AddressBookJ2WB.war,WEB-INF/web.xml default_host ]
 [ "AddressBook Top Down Java Bean" AddressBookW2JB.war,WEB-INF/web.xml default_host ]]]' )
Using Jython with pattern matching:
AdminApp.install('WebServicesSamples.ear', ['-WebServicesClientBindPortInfo',
 [['.*', '.*', '.*', '.*', '3000', 'newHTTP_ID', 'newHTTP_pwd', 'sslAliasConfig',
 'http://yunus:9090/WSLoggerEJB/services/WSLoggerJMS']]])

WebServicesClientBindPreferredPort

The WebServicesClientBindPreferredPort option associates a preferred port (implementation) with a port type (interface) for a client web service. The immutable values identify a port type of the client web service that you are modifying. The scoping fields include: Module, EJB, Web service and Port Type. The mutable value for this task is Port.
  • Port Type - QName ("{namespace} localname") of a port type that is defined by a wsdl:portType attribute in the WSDL file that identifies an interface.
  • Port - QName of a port defined by a wsdl:port attribute within a wsdl:service attribute in a WSDL file that identifies an implementation that has preference.

Batch mode example usage

Using Jacl:
$AdminApp install WebServicesSamples.ear {-WebServicesClientBindPreferredPort
 {{AddressBookW2JE.jar AddressBookW2JE service/WSLoggerService2 WSLoggerJMS WSLoggerJMSPort}}} 
To install the WebServicesSamples.ear sample, you must specify the BindJndiForEJBNonMessageBinding and MapWebModToVH options as well as the WebServicesClientBindPreferredPort option:
$AdminApp install WebServicesSamples.ear
{-WebServicesClientBindPreferredPort {{AddressBookW2JE.jar AddressBookW2JE service/WSLoggerService2
 WSLoggerJMS WSLoggerJMSPort}}
-BindJndiForEJBNonMessageBinding {{ "Stock Quote Sample EJB"
 com_ibm_websphere_samples_webservices_stock_StockQuote StockQuote.jar,META-INF/ejb-jar.xml jndi1 "" "" }
 { "Address Book Sample EJB" com_ibm_websphere_samples_webservices_addr_AddressBookW2JE
 AddressBookW2JE.jar,META-INF/ejb-jar.xml jndi2 "" "" }{ "Address Book Sample EJB"
 com_ibm_websphere_samples_webservices_addr_AddressBookJ2WE AddressBookJ2WE.jar,META-INF/ejb-jar.xml
 jndi3 "" "" }}
-MapWebModToVH {{ "module_name" web_services.war,WEB-INF/web.xml default_host }
 { "AddressBook Bottom Up Java Bean" AddressBookJ2WB.war,WEB-INF/web.xml default_host }
 { "AddressBook Top Down Java Bean" AddressBookW2JB.war,WEB-INF/web.xml default_host }} } 
Using Jacl with pattern matching:
$AdminApp install WebServicesSamples.ear {-WebServicesClientBindPreferredPort {{.* .* .* .* 
 WSLoggerJMSPort}}}
Using Jython:
AdminApp.install('WebServicesSamples.ear', '[-WebServicesClientBindPreferredPort 
 [[AddressBookW2JE.jar AddressBookW2JE service/WSLoggerService2 WSLoggerJMS WSLoggerJMSPort]]]') 
To install the WebServicesSamples.ear sample, you must specify the BindJndiForEJBNonMessageBinding and MapWebModToVH options as well as the WebServicesClientBindPreferredPort option:
AdminApp.install('WebServicesSamples.ear',
'[ -WebServicesClientBindPreferredPort
 [[AddressBookW2JE.jar AddressBookW2JE service/WSLoggerService2 WSLoggerJMS WSLoggerJMSPort ]]
-BindJndiForEJBNonMessageBinding [[ "Stock Quote Sample EJB"
 com_ibm_websphere_samples_webservices_stock_StockQuote StockQuote.jar,META-INF/ejb-jar.xml jndi1 "" "" ]
 [ "Address Book Sample EJB" com_ibm_websphere_samples_webservices_addr_AddressBookW2JE
 AddressBookW2JE.jar,META-INF/ejb-jar.xml jndi2 "" "" ][ "Address Book Sample EJB"
 com_ibm_websphere_samples_webservices_addr_AddressBookJ2WE AddressBookJ2WE.jar,META-INF/ejb-jar.xml
 jndi3 "" "" ]]
-MapWebModToVH [[ "module_name" web_services.war,WEB-INF/web.xml default_host ]
 [ "AddressBook Bottom Up Java Bean" AddressBookJ2WB.war,WEB-INF/web.xml default_host ]
 [ "AddressBook Top Down Java Bean" AddressBookW2JB.war,WEB-INF/web.xml default_host ]]]' )
Using Jython with pattern matching:
AdminApp.install('WebServicesSamples.ear', ['-WebServicesClientBindPreferredPort',
 [['.*', '.*', '.*', '.*', 'WSLoggerJMSPort']]])

WebServicesServerBindPort

The WebServicesServerBindPort option sets two attributes of a web service port. The immutable values identify the port of a web service that you are modifying. The scope fields include: Module, Web service and Port. The mutable values include: WSDL Service Name, and Scope.

The scope determines the life cycle of implementing the Java bean. The valid values include: Request (new instance for each request), Application (one instance for each web-app), and Session (new instance for each HTTP session).

The scope attribute does not apply to web services that a Java Message Service (JMS) transport. The scope attribute does not apply to enterprise beans.

The WSDL service name identifies a service when more than one service has the same port name. The WSDL service name is represented as a QName string, for example, {namespace}localname .

Batch mode example usage

Using Jacl:
$AdminApp install WebServicesSamples.ear {-WebServicesServerBindPort
 {{AddressBookW2JE.jar service/WSLoggerService2 WSLoggerJMS {} Session}}}
Using Jacl with pattern matching:
$AdminApp install WebServicesSamples.ear {-WebServicesServerBindPort
 {{.*  WSClientTestService WSClientTest Request} {.*  StockQuoteService StockQuote Application}
 {.*  StockQuoteService StockQuote2 Session}}}
Using Jython:
AdminApp.install('WebServicesSamples.ear', '[-WebServicesServerBindPort
 [[AddressBookW2JE.jar service/WSLoggerService2 WSLoggerJMS "" Session]]]')
Using Jython with pattern matching:
AdminApp.install('WebServicesSamples.ear', ['-WebServicesServerBindPort',
 [['.*', 'WSClientTestService', 'WSClientTest', 'Request'],
 ['.*', 'StockQuoteService', 'StockQuote', 'Application'],
 ['.*', 'StockQuoteService', 'StockQuote2', 'Session']]])

WebServicesClientCustomProperty

The WebServicesClientCustomProperty option supports the configuration of the name value parameter for the description of the client bind file of a web service. The immutable values identify the port of the web service that you are modifying. The scope fields include: Module, Web service, and Port. The mutable values include: name and value.

The format of the name and value values include a string that represents multiple name and value pairs by using the + character as a separator. For example, name string = "n1+n2+n3" value string = "v1+v2+v3" yields name/value pairs: {{"n1" "v1"}, {"n2" "v2"}, {"n3" " v3"}},

Batch mode example usage

Using Jacl:
$AdminApp edit WebServicesSamples {-WebServicesClientCustomProperty
 {{join.jar com_ibm_ws_wsfvt_test_multiejbjar_client_WSClientTest service/StockQuoteService
 STockQuote propname1 propValue1}
{ejbclientonly.jar Exchange service/STockQuoteService STockQuote propname2 propValue2}}}
Using Jacl with pattern matching:
$AdminApp edit WebServicesSamples {-WebServicesClientCustomProperty
 {{join.jar com_ibm_ws_wsfvt_test_multiejbjar_client_WSClientTest .* .* propname1 propValue1}
 {ejbclientonly.jar Exchange .* .* propname2 propValue2}}}
Using Jython:
AdminApp.edit('WebServicesSamples', ['-WebServicesClientCustomProperty',
 [['join.jar', 'com_ibm_ws_wsfvt_test_multiejbjar_client_WSClientTest',
 'service/StockQuoteService', 'STockQuote', 'propname1', 'propValue1'],
 ['ejbclientonly.jar', 'Exchange', 'service/STockQuoteService', 'STockQuote',
 'propname2', 'propValue2']]])
Using Jython with pattern matching:
AdminApp.edit('WebServicesSamples', ['-WebServicesClientCustomProperty',
 [['join.jar', 'com_ibm_ws_wsfvt_test_multiejbjar_client_WSClientTest',
 '.*', '.*', 'propname1', 'propValue1'],
 ['ejbclientonly.jar', 'Exchange', '.*', '.*', 'propname2', 'propValue2']]])

WebServicesServerCustomProperty

The WebServicesServerCustomProperty option supports the configuration of the name value parameter for the description of the server bind file of a web service. The scoping fields include the following: Module, EJB, and web service. The mutable values for this task include: name and value.

The format of the these values include a string that represents multiple name and value pairs by using the plus (+) character as a separator. For example, name string = "n1+n2+n3" value string = "v1+v2+v3" yields name and value pairs: {{"n1" "v1"}, {"n2" "v2"}, {"n3" " v3"}}.

Batch mode example usage

Using Jacl:
$AdminApp edit WebServicesSamples {-WebServicesServerCustomProperty
 {{AddressBookW2JE.jar AddressBookService AddressBook
 com.ibm.websphere.webservices.http.responseContentEncoding deflate}}}
Using Jacl with pattern matching:
$AdminApp edit WebServicesSamples {-WebServicesServerCustomProperty
 {{.* .* .* com.ibm.websphere.webservices.http.responseContentEncoding deflate}}}
Using Jython:
AdminApp.edit ( 'WebServicesSamples', '[ -WebServicesServerCustomProperty
 [[AddressBookW2JE.jar AddressBookService AddressBook
 com.ibm.websphere.webservices.http.responseContentEncoding deflate]]]')
Using Jython with pattern matching:
AdminApp.edit ( 'WebServicesSamples', ['-WebServicesServerCustomProperty', [['.*', '.*',
 '.*', 'com.ibm.websphere.webservices.http.responseContentEncoding', 'deflate']]])