Commands for the AdminApp object using wsadmin

Use the AdminApp object to install, modify, and administer applications. The AdminApp object interacts with the WebSphere Application Server management and configuration services to make application inquiries and changes. This interaction includes installing and uninstalling applications, listing modules, exporting, and so on.

In a deployment manager environment, configuration updates are available only if a scripting client is connected to a deployment manager. When connected to a node agent or a managed application server, we are not able to update the configuration because the configuration for these server processes are copies of the master configuration which resides in the deployment manager. The copies are created on a node machine when a configuration synchronization occurs between the deployment manager and the node agent. Make configuration changes to the server processes by connecting a scripting client to a deployment manager. For this reason, to change a configuration, do not run a scripting client in local mode on a node machine. It is not a supported configuration.

The following commands are available for the AdminApp object:

• deleteUserAndGroupEntries
• edit
• editInteractive
• export
• exportDDL
• exportFile
• getDeployStatus
• help
• install
• installInteractive
• isAppReady
• list
• listModules
• options
• publishWSDL
• searchJNDIReferences
• taskInfo
• uninstall
• update
• updateAccessIDs
• updateInteractive
• view

.xmi vs. .xml

For IBM extension and binding files, the .xmi or .xml file name extension is different depending on whether we 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.

deleteUserAndGroupEntries

Delete users or groups for all roles, and to delete user IDs and passwords for all of the RunAs roles defined in the application.

Target object: None.

Required parameters:

application name

Application of interest.

Optional parameters: None.

Examples

• Jacl:
  $AdminApp deleteUserAndGroupEntries myapp

• Use Jython string:
  print AdminApp.deleteUserAndGroupEntries('myapp')

• Use Jython list:
  print AdminApp.deleteUserAndGroupEntries(['myapp'])

edit

Edit an application or module in batch mode. The edit command changes the application specified by the application name argument using the options specified by the options argument. No options are required for the edit command.

Target object: None.

Required parameters:

application name

Application of interest.

options

Options to apply to the application or module configuration.

Optional parameters: None.

Examples

• Jacl:
  $AdminApp edit "JavaMail Sample" {-MapWebModToVH {{"JavaMail Sample WebApp" mtcomps.war,WEB-INF/web.xml newVH}}}

• Use Jython string:
  print AdminApp.edit("JavaMail Sample", '[-MapWebModToVH [["JavaMail 32 Sample WebApp" mtcomps.war,WEB-INF/web.xml newVH]]]')

• Use Jython list:
  option = [["JavaMail 32 Sample WebApp", "mtcomps.war,WEB-INF/web.xml", "newVH"]] mapVHOption = ["-MapWebModToVH", option] print AdminApp.edit("JavaMail Sample", mapVHOption)

editInteractive

Edit an application or module in interactive mode. The editInteractive command changes the application deployment. Specify these changes in the options parameter. No options are required for the editInteractive command.

Target object: None.

Required parameters:

application name

Application of interest.

options

Options to apply to the application or module configuration.

Optional parameters: None.

Examples

• Jacl:
  $AdminApp editInteractive ivtApp

• Use Jython string:
  AdminApp.editInteractive('ivtApp')

export

Export the application name parameter to a file specified by the file name.

Target object: None.

Required parameters:

application name

Application of interest.

file name

File name to export the application name to.

Optional parameters:

exportToLocal

The system should export the application of interest to the file name specified on the local client machine.

Examples

• Jacl:
  $AdminApp export DefaultApplication c:/temp/export.ear {-exportToLocal}

• Jython:
  AdminApp.export('DefaultApplication', 'c:/temp/export.ear', '[-exportToLocal]')

exportDDL

Extract the data definition language (DDL) from the application name parameter to the directory name parameter that a directory specifies. The options parameter is optional.

Target object: None.

Required parameters:

application name

Application of interest.

directory name

Name of the directory to export the application name to.

Optional parameters:

options

Options to pass to the application name specified.

Examples

• Jacl:
  $AdminApp exportDDL "My App" /usr/me/DDL {-ddlprefix myApp}

• Use Jython string:
  print AdminApp.exportDDL("My App", '/usr/me/DDL', '[-ddlprefix myApp]')

exportFile

Export the contents of a single file specified by the uniform resource identifier (URI) from the application of interest.

Target object: None.

Required parameters:

application name

Application of interest.

URI

Single file to export. URI within the context of an application: META-INF/application.xml. To specify files within a module, the URI begins with a module URI, as the following example displays: foo.war/WEB-INF/web.xml.

filename

Fully qualified path and file name of the file to export to.

Optional parameters: None.

Examples

• Jacl:
  $AdminApp exportFile "My App" myapp/components.jar/META-INF/ibm-ejb-jar-bnd.xml META-INF/ibm-ejb-jar-bnd.xml

• Use Jython string:
  AdminApp.exportFile('My App', 'myapp/components.jar/META-INF/ibm-ejb-jar-bnd.xml', 'META-INF/ibm-ejb-jar-bnd.xml')

getDeployStatus

Display the deployment status of the application. After installing or updating a large application, use this command to display detailed status information for application binary file expansion. We cannot start the application until the system extracts the application binaries.

Target object: None.

Required parameters:

application name

Name of the application of interest.

Optional parameters: None.

Examples

• Jacl:
  $AdminApp getDeployStatus myApplication

• Jython:
  print AdminApp.getDeployStatus('myApplication')

Running the getDeployStatus command where myApplication is DefaultApplication results in status information about DefaultApplication resembling the following:

ADMA5071I: Distribution status check started for application DefaultApplication. WebSphere:cell=myCell01,node=myNode01,distribution=unknown,expansion=unknown ADMA5011I: The cleanup of the temp directory for application DefaultApplication is complete. ADMA5072I: Distribution status check completed for application DefaultApplication. WebSphere:cell=myCell01,node=myNode01,distribution=unknown,expansion=unknown

help

Display general help information about the AdminApp object.

Target object: None.

Required parameters: None.

Optional parameters:

operation name

Specify this option to display help for an AdminApp command or installation option.

Sample output

The following output is returned if we do not specify an argument:

WASX7095I: The AdminApp object allows application objects to be manipulated including installing, 
uninstalling, editing, and listing.  Most of the commands supported by AdminApp operate in two modes: 
the default mode is one in which AdminApp communicates with the application server to accomplish its 
tasks.  A local mode is also possible, in which no server communication takes place.  The local mode of 
operation is invoked by including the "-conntype NONE" flag in the option string supplied to the command.

The following commands are supported by AdminApp; more detailed information about each of these commands 
is available using the "help" command of AdminApp and supplying the name of the command as an argument.

edit                        Edit the properties of an application editInteractive             
                            Edit the properties of an application interactively
export                      Export application to a file
exportDDL                   Extract DDL from application to a directory help                            
                            Show help information
install                     Installs an application, given a file name and an option string.
installInteractive          Installs an application in interactive mode, given a file name and an option string.
list                        List all installed applications listModules                 
                            List the modules in a specified 
application options         Shows the options available, either for a given file, or in general.
taskInfo                    Shows detailed information pertaining to a given installation task for a given file
uninstall                   Uninstalls an application, given an application name and an option string

The following output is returned if we specify uninstall as the operation name argument:

WASX7102I: Method: uninstall
Arguments: application name, options
Description: Uninstalls application named by "application name" using the options supplied by String 2.
Method: uninstall
Arguments: application name
Description: Uninstalls the application specified by "application name" using default options.

Examples

Jacl:

• The following example does not specify any arguments:
  $AdminApp help

• The following example specifies the operation name argument:
  $AdminApp help uninstall

Jython:

• The following example does not specify any arguments:
  print AdminApp.help()

• The following example specifies the operation name argument:
  print AdminApp.help('uninstall')

install

Install an application in non-interactive mode, given a fully qualified file name and a string of installation options. The options parameter is optional.

Target object: None.

Required parameters:

ear file

Path of the .ear file to install.

Optional parameters:

options

Specify the installation options for the command.

Examples

• Jacl:
  $AdminApp install c:/apps/myapp.ear

• Jython:
  print AdminApp.install('c:/apps/myapp.ear')

any options are available for this command. We can obtain a list of valid options for an EAR file with the following command:

Jacl:

$AdminApp options myApp.ear

Jython:

print AdminApp.options('myApp.ear')

We can also obtain help for each object with the following command:

Jacl:

$AdminApp help MapModulesToServers

Jython:

print AdminApp.help('MapModulesToServers')

installInteractive

Install an application in interactive mode, given a fully qualified file name and a string of installation options. The options parameter is optional.

Target object: None.

Required parameters:

ear file

Path of the .ear file to install.

Optional parameters:

options

Specify the installation options for the command.

Examples

• Jacl:
  $AdminApp installInteractive c:/websphere/appserver/installableApps/jmsample.ear

• Jython:
  print AdminApp.installInteractive('c:/websphere/appserver/installableApps/jmsample.ear')

isAppReady

Determine if the specified application has been distributed and is ready to be run. Returns a value of true if the application is ready, or a value of false if the application is not ready. A script that invokes isAppReady typically installs or updates an application, and then loops around the call until the call returns a value of true before starting the application. This command is not supported when the wsadmin tool is not connected to a server.

Target object: None.

Required parameters:

application name

Name of the application of interest.

Optional parameters:

ignoreUnknownState

Tests to see if the specified application has been distributed and is ready to be run. Valid values for the ignoreUnknownState parameter include true and false. If we specify a value of true, nodes and servers with an unknown state will not be included in the final ready return. The command returns a value of true if the application is ready or a value of false if the application is not ready. This command is not supported when the wsadmin tool is not connected to a server.

Sample output

The following sample output is returned if we specify the application name parameter:

ADMA5071I: Distribution status check started for application DefaultApplication.WebSphere:cell=Node03Cell,node=myNode,distribution=true ADMA5011I: The cleanup of the temp directory for application DefaultApplication is complete. ADMA5072I: Distribution status check completed for application DefaultApplication.true

The following sample output is returned if we specify the application name and ignoreUnknownState parameters:

ADMA5071I: Distribution status check started for application TEST.WebSphere:cell=myCell,node=myNode, distribution=unknown ADMA5011I: The cleanup of the temp directory for application TEST is complete. ADMA5072I: Distribution status check completed for application TEST.false

Examples

The following examples only specify the application name parameter:

• Jacl:
  set result [$AdminApp isAppReady DefaultApplication] while {$result == "false"} { ### Wait 5 seconds before checking again after 5000 set result [$AdminApp isAppReady DefaultApplication] } puts "Starting application..."

• Jython:
  import time result = AdminApp.isAppReady('DefaultApplication') while (result == "false") : ### Wait 5 seconds before checking again time.sleep(5) result = AdminApp.isAppReady ('DefaultApplication') print("Starting application...")

The following examples specify the application name and ignoreUnknownState parameters:

• Jacl:
  set result [$AdminApp isAppReady DefaultApplication] while {$result == "false"} { ### Wait 5 seconds before checking again after 5000 set result [$AdminApp isAppReady DefaultApplication] } puts "Starting application..."

• Jython:
  import time result = AdminApp.isAppReady ('DefaultApplication') while (result == "false"): ### Wait 5 seconds before checking again time.sleep(5) result = AdminApp.isAppReady ('DefaultApplication') print("Starting application...")

list

List the applications installed in the configuration.

Target object: None.

Required parameters: None.

Optional parameters:

target

List the applications installed on a given target scope in the configuration.

Sample output

adminconsole DefaultApplication ivtApp

Examples

• Jacl:
  $AdminApp list

• Jython:
  print AdminApp.list()

The following examples specify a value for the target parameter:

• Jacl:
  $AdminApp list WebSphere:cell=myCell,node=myNode,server=myServer

• Jython:
  print AdminApp.list("WebSphere:cell=myCell,node=myNode,server=myServer")

listModules

List the modules in an application.

Target object: None.

Required parameters:

application name

Application of interest.

Optional parameters:

options

List of application servers on which the modules are installed. The options parameter is optional. The valid option is -server.

Sample output

The following example is the concatenation of appname, #, module URI, +, and DD URI. We can pass this string to the edit and editInteractive AdminApp commands.

ivtApp#ivtEJB.jar+META-INF/ejb-jar.xml ivtApp#ivt_app.war+WEB-INF/web.xml

Examples

• Jacl:
  $AdminApp listModules ivtApp

• Jython:
  print AdminApp.listModules('ivtApp')

options

Display a list of options for installing an EAR file.

Target object: None.

Required parameters: None.

Optional parameters:

EAR file

The EAR file of interest.

application name

Application for which to display a list of options for editing an existing application.

application module name

Module name for which to display a list of options for editing a module in an existing application. This parameter requires the same module name format as the output that is returned by the listModules command.

file, operations

Display a list of options for installing or updating an application or application module file. Specify one of the following valid values:

• installapp - Install the file specified.
• updateapp - Use this option to update an existing application with the file specified.
• addmodule - Use this option to add the module file specified to an existing application.
• updatemodule - Use this option to update an existing module in an application with the module file specified.

Sample output

WASX7112I: The following options are valid for "ivtApp" apRolesToUsers BindJndiForEJBNonMessageBinding apEJBRefToEJB apWebModToVH apModulesToServers distributeApp nodistributeApp useMetaDataFromBinary nouseMetaDataFromBinary createMBeansForResources nocreateMBeansForResources reloadEnabled noreloadEnabled verbose installed.ear.destination reloadInterval

Examples

The following example options command returns the valid options for an EAR file:

• Jacl:
  $AdminApp options c:/websphere/appserver/installableApps/ivtApp.ear

• Jython:
  print AdminApp.options('c:/websphere/appserver/installableApps/ivtApp.ear')

The following example options command returns the valid options for an application:

• Jacl:
  $AdminApp options ivtApp

• Jython:
  print AdminApp.options('ivtApp')

The following example options command returns the valid options for an application module:

• Jacl:
  $AdminApp options ivtApp#ivtEJB.jar+META-INF/ejb-jar.xml

• Jython:
  print AdminApp.options('ivtApp#ivtEJB.jar+META-INF/ejb-jar.xml')

The following example options command returns the valid options for the operation that is requested with the input file:

• Jacl:
  $AdminApp options c:/websphere/appserver/installableApps/ivtApp.ear updateapp

• Jython:
  print AdminApp.options('c:/websphere/appserver/installableApps/ivtApp.ear', 'updateapp')

publishWSDL

Publish WSDL files for the application specified in the application name parameter to the file specified in the file name parameter.

Target object: None.

Required parameters:

file name

File of interest.

application name

Application of interest

Optional parameters:

SOAP address prefixes

The SOAP address prefixes to use.

Sample output

The publishWSDL command does not return output.

Examples

The following example publishWSDL command specifies the application name and the file name:

• Jacl:
  $AdminApp publishWSDL JAXRPCHandlerServer c:/temp/a.zip

• Jython:
  print AdminApp.publishWSDL('JAXRPCHandlerServer', 'c:/temp/a.zip')

The following example publishWSDL command specifies the application name, file name, and SOAP address prefixes parameter values:

• Jacl:
  $AdminApp publishWSDL JAXRPCHandlersServer c:/temp/a.zip {{JAXRPCHandlersServerApp.war {{http http://localhost:9080}}}}

• Jython:
  print AdminApp.publishWSDL('JAXRPCHandlersServer', 'c:/temp/a.zip', '[[JAXRPCHandlersServerApp.war [[http http://localhost:9080]]]]')

searchJNDIReferences

List applications that refer to the JNDI name on a specific node.

Target object: None.

Required parameters:

node configuration ID

Configuration ID for the node of interest.

Optional parameters:

options

Options to use.

Sample output

WASX7410W: This operation may take a while depending on the number of applications installed in the system. yApp apResRefToEJB :ejb-jar-ic.jar : [eis/J2CCF1]

Examples

The following example assumes an installed application named MyApp has a JNDI name of eis/J2CCF1:

• Jacl:
  $AdminApp searchJNDIReferences $node {-JNDIName eis/J2CCF1 -verbose}

• Jython:
  print AdminApp.searchJNDIReferences(node, '[-JNDIName eis/J2CCF1 -verbose]')

taskInfo

Provide information about a particular task option for an application file. Many task names changed between V5.x and V6.x for a similar or the exact same operation. We might need to update existing scripts if we are migrating from V5.x to V6.x.

Target object: None.

Required parameters:

EAR file

The EAR file of interest.

task name

Task for which to request the information.

Optional parameters None.

Sample output

MapWebModToVH: Selecting virtual hosts for web modules Specify the virtual host where we want to install the web modules contained in the application. Web modules can be installed on the same virtual host or dispersed among several hosts. Each element of the MapWebModToVH task consists of the following three fields: "webModule," "uri," "virtualHost." Of these fields, the following fields might be assigned new values: "virtualHost"and the following are required: "virtualHost" The current contents of the task after running default bindings are: webModule: JavaMail Sample WebApp uri: mtcomps.war,WEB-INF/web.xml virtualHost: default_host

Examples

• Jacl:
  $AdminApp taskInfo c:/websphere/appserver/installableApps/jmsample.ear MapWebModToVH

• Jython:
  print AdminApp.taskInfo('c:/websphere/appserver/installableApps/jmsample.ear', 'MapWebModToVH')

uninstall

Uninstall an existing application.

Target object: None.

Required parameters:

application name

Name of the application to uninstall.

Optional parameters:

options

Options for uninstall.

Sample output

ADMA5017I: Uninstallation of myapp started. ADMA5104I: Server index entry for myCellManager was updated successfully. ADMA5102I: Deletion of config data for myapp from config repository completed successfully. ADMA5011I: Cleanup of temp dir for app myapp done. ADMA5106I: Application myapp uninstalled successfully.

Examples

• Jacl:
  $AdminApp uninstall myApp

• Jython:
  print AdminApp.uninstall('myApp')

update

Update an application in non-interactive mode. This command supports the addition, removal, and update of application subcomponents or the entire application. Provide the application name, content type, and update options.

Target object: None.

Required parameters:

application name

Name of the application to update.

content type

Update part of the application or the entire application. The following list includes the valid content type values for the update command:

app	Update the entire application. This option is the same as indicating the update option with the install command. With the app value as the content type, specify the operation option with update as the value. Provide the new EAR file using the contents option. We can also specify binding information and application options. By default, binding information for installed modules is merged with the binding information for updated modules. To change this default behavior, specify the update.ignore.old or the update.ignore.new options.
file	Update a single file. We can add, remove, or update individual files at any scope within the deployed application. With the file value as the content type, we must perform operations on the file using the operation option. Depending on the type of operation, additional options are required. For file additions and updates, provide file content and the file URI relative to the root of the EAR file using the contents and contenturi options. For file deletion, provide the file URI relative to the root of the EAR file using the contenturi option which is the only required input. Any other options that we provide are ignored.
modulefile	Update a module. We can add, remove, or update an individual application module. If we specify the modulefile value as the content type, we must indicate the operation to perform on the module using the operation option. Depending on the type of operation, further options are required. For installing new modules or updating existing modules in an application, we must indicate the file content and the file URI relative to the root of the EAR file using the contents and contenturi options. We can also specify binding information and application options that pertain to the new or updated modules. For module updates, the binding information for the installed module is merged with the binding information for the input module by default. To change the default behavior, specify the update.ignore.old or the update.ignore.new options. To delete a module, indicate the file URI relative to the root of the EAR file. Restriction: Generally, we cannot add or update a module if it depends on other classes outside the module, such as classes within an optional package or library. Client-side processing involves introspecting input module classes and those classes might not load successfully unless class dependencies also are resolved. We can add or update a module if we make the required classes available on a file system that is accessible through wsadmin scripting. Through wsadmin scripting, we can modify the com.ibm.ws.scripting.classpath property in the profile_root/properties/wsadmin.properties file to include those classes so that the class loader can resolve them.
partialapp	Update a partial application. Using a subset of application components provided in a compressed .zip file format we can update, add, and delete files and modules. The compressed file is not a valid Java 2 platform, Enterprise Edition (J2EE) archive. Instead, it contains application artifacts in the same hierarchical structure as they display in an EAR file. For more information on how to construct the partial application compressed file, see the Java API section. If we indicate the partialapp value as the content type, use the contents option to specify the location of the compressed file. When a partial application is provided as an update input, binding information and application options cannot be specified and are ignored, if provided.

Optional parameters:

options

There are many options available for the update command. For a list of each valid option for the update command, see Options for the AdminApp object install, installInteractive, edit, editInteractive, update, and updateInteractive commands .

Sample output

Update of singleFile has started. ADMA5009I: Application archive extracted at C:\DOCUME~1\lavena\LOCALS~1\Temp\app_fb5a1960f0\ext Added files from partial ear: [] performFileOperation: source=C:\DOCUME~1\lavena\LOCALS~1\Temp\app_fb5a1960f0\ext, dest=C:\DOCUME~1\lavena\LOCALS~1\Temp\app_fb5a1960f0\mrg, uri= META-INF/web.xml, op= add Copying file from C:\DOCUME~1\lavena\LOCALS~1\Temp\app_fb5a1960f0\ext/META-INF/web.xml to C:\DOCUME~1\lavena\LOCALS~1\Temp\app_fb5a1960f0\mrg\META-INF\web.xml Collapse list is: [] FileMergeTask completed successfully ADMA5005I: Application singleFile configured in WebSphere repository delFiles: [] delM: null addM: null Pattern for remove loose and mod: Loose add pattern: META-INF/[^/]*|WEB-INF/[^/]*|.*wsdl root file to be copied: META-INF/web.xml to C:\asv\b0403.04\WebSphere\AppServer\wstemp\Scriptfb5a191b4e\workspace\cells\BAMBIE\applications\ singleFile.ear\deployments\singleFile/META-INF/web.xml ADMA5005I: Application singleFile configured in WebSphere repository xmlDoc: [#document: null] root element: [app-delta: null] ****** delta file name: C:\asv\b0403.04\WebSphere\AppServer\wstemp\Scriptfb5a191b4e\workspace\cells\BAMBIE\applications\ singleFile.ear/deltas/delta-1079548405564 ADMA5005I: Application singleFile configured in WebSphere repository ADMA6011I: Deleting directory tree C:\DOCUME~1\lavena\LOCALS~1\Temp\app_fb5a1960f0 ADMA5011I: Cleanup of temp dir for app singleFile done. Update of singleFile has ended.

Examples

• Jacl:
  $AdminApp update myApp file {-operation add -contents c:/apps/myApp/web.xml -contenturi META-INF/web.xml}

• Jython:
  print AdminApp.update('myApp', 'file', '[-operation add -contents c:/apps/myApp/web.xml -contenturi META-INF/web.xml]')

• Use Jython list:
  print AdminApp.update('myApp', 'file', ['-operation', 'add', '-contents', 'c:/apps/myApp/web.xml', '-contenturi', 'META-INF/web.xml'])

updateAccessIDs

Update the access ID information for users and groups that are assigned to various roles defined in the application. The system reads the access IDs from the user registry and saves the IDs in the application bindings. This operation improves runtime performance of the application. Use this command after installing an application or after editing security role-specific information for an installed application. This method cannot be invoked when the -conntype option for the wsadmin tool is set to NONE. We must be connected to a server to invoke this command.

Target object: None.

Required parameters:

application name

Name of the application of interest.

bALL

The bALL boolean parameter retrieves and saves all access IDs for users and groups in the application bindings. Specify false to retrieve access IDs for users or groups that do not have an access ID in the application bindings.

Examples

• Jacl or true:
  $AdminApp updateAccessIDs myapp true

• Jacl for false:
  $AdminApp updateAccessIDs myapp false

• Use Jython for true:
  print AdminApp.updateAccessIDs('myapp', 1)

• Use Jython for false:
  print AdminApp.updateAccessIDs('myapp', 0)

updateInteractive

Add, remove, and update application subcomponents or an entire application. When we update an application module or an entire application using interactive mode, the steps used to configure binding information are similar to those that apply to the installInteractive command. If we update a file or a partial application, the steps used to configure the binding information are not available. In this case, the steps are the same as the ones we use with the update command.

Target object: None.

Required parameters:

application name

Name of the application to update.

content type

Update part of the application or the entire application. The following list includes the valid content type values for the updateInteractive command:

app	Update the entire application. This option is the same as indicating the update option with the install command. With the app value as the content type, specify the operation option with update as the value. Provide the new EAR file using the contents option. We can also specify binding information and application options. By default, binding information for installed modules is merged with the binding information for updated modules. To change this default behavior, specify the update.ignore.old or the update.ignore.new options.
file	Update a single file. We can add, remove, or update individual files at any scope within the deployed application. With the file value as the content type, we must perform operations on the file using the operation option. Depending on the type of operation, additional options are required. For file additions and updates, provide file content and the file URI relative to the root of the EAR file using the contents and contenturi options. For file deletion, provide the file URI relative to the root of the EAR file using the contenturi option which is the only required input. Any other options that we provide are ignored.
modulefile	Update a module. We can add, remove, or update an individual application module. If we specify the modulefile value as the content type, we must indicate the operation to perform on the module using the operation option. Depending on the type of operation, further options are required. For installing new modules or updating existing modules in an application, we must indicate the file content and the file URI relative to the root of the EAR file using the contents and contenturi options. We can also specify binding information and application options that pertain to the new or updated modules. For module updates, the binding information for the installed module is merged with the binding information for the input module by default. To change the default behavior, specify the update.ignore.old or the update.ignore.new options. To delete a module, indicate the file URI relative to the root of the EAR file. Restriction: Generally, we cannot add or update a module if it depends on other classes outside the module, such as classes within an optional package or library. Client-side processing involves introspecting input module classes and those classes might not load successfully unless class dependencies also are resolved. We can add or update a module if we make the required classes available on a file system that is accessible through wsadmin scripting. Through wsadmin scripting, we can modify the com.ibm.ws.scripting.classpath property in the profile_root/properties/wsadmin.properties file to include those classes so that the class loader can resolve them.
partialapp	Update a partial application. Using a subset of application components provided in a compressed .zip file format we can update, add, and delete files and modules. The compressed file is not a valid Java 2 platform, Enterprise Edition (J2EE) archive. Instead, it contains application artifacts in the same hierarchical structure as they display in an EAR file. For more information on how to construct the partial application compressed file, see the Java API section. If we indicate the partialapp value as the content type, use the contents option to specify the location of the compressed file. When a partial application is provided as an update input, binding information and application options cannot be specified and are ignored, if provided.

Optional parameters:

options

There are many options available for the updateInteractive command. For a list of each valid option for the updateInteractive command, see Options for the AdminApp object install, installInteractive, edit, editInteractive, update, and updateInteractive commands .

Sample output

Getting tasks for: myApp WASX7266I: A was.policy file exists for this application; would you like to display it? [No] Task[4]: Binding enterprise beans to JNDI names Each non message driven enterprise bean in the application or module must be bound to a JNDI name. EJB Module: Increment EJB module EJB: Increment URI: Increment.jar,META-INF/ejb-jar.xml JNDI Name: [Inc]: Task[10]: Specifying the default data source for EJB 2.x modules Specify the default data source for the EJB 2.x Module containing 2.x CMP beans. WASX7349I: Possible value for resource authorization is container or per connection factory EJB Module: Increment EJB module URI: Increment.jar,META-INF/ejb-jar.xml JNDI Name: [DefaultDatasource]: Resource Authorization: [Per connection factory]: Task[12]: Specifying data sources for individual 2.x CMP beans Specify an optional data source for each 2.x CMP bean. Mapping a specific data source to a CMP bean overrides the default data source for the module containing the enterprise bean. WASX7349I: Possible value for resource authorization is container or per connection factory EJB Module: Increment EJB module EJB: Increment URI: Increment.jar,META-INF/ejb-jar.xml JNDI Name: [DefaultDatasource]: Resource Authorization: [Per connection factory]:container Setting "Resource Authorization" to "cmpBinding.container" Task[14]: Selecting Application Servers Specify the application server where we want to install modules contained in the application. Modules can be installed on the same server or dispersed among several servers. Module: Increment EJB module URI: Increment.jar,META-INF/ejb-jar.xml Server: [WebSphere:cell=myCell,node=myNode,server=server1]: Task[16]: Selecting method protections for unprotected methods for 2.x EJB Specify whether we want to assign security role to the unprotected method, add the method to the exclude list, or mark the method as unchecked. EJB Module: Increment EJB module URI: Increment.jar,META-INF/ejb-jar.xml Protection Type: [methodProtection.uncheck]: Task[18]: Selecting backend ID Specify the selection for the BackendID EJB Module: Increment EJB module URI: Increment.jar,META-INF/ejb-jar.xml BackendId list: CLOUDSCAPE_V50_1 CurrentBackendId: [CLOUDSCAPE_V50_1]: Task[21]: Specifying application options Specify the various options available to prepare and install the application. Pre-compile JSP: [No]: Deploy EJBs: [No]: Deploy WebServices: [No]: Task[22]: Specifying EJB deploy options Specify the options to deploy EJB. ....EJB Deploy option is not enabled. Task[24]: Copy WSDL files Copy WSDL files ....This task does not require any user input Task[25]: Specify options to deploy web services Specify options to deploy web services ....Web services deploy option is not enabled. Update of myApp has started. ADMA5009I: Application archive extracted at C:\DOCUME~1\lavena\LOCALS~1\Temp\app_fb5a48e969\ext/Increment.jar FileMergeTask completed successfully ADMA5005I: Application myApp configured in WebSphere repository delFiles: [] delM: null addM: [Increment.jar, ] Pattern for remove loose and mod: Loose add pattern: META-INF/[^/]*|WEB-INF/[^/]*|.*wsdl root file to be copied: ETA-INF/application.xml to C:\asv\b0403.04\WebSphere\AppServer\wstemp\Scriptfb5a487089\workspace\cells\BAMBIE\ applications\testSM.ear\deployments\testSM/META-INF/application.xml del files for full module add/update: [] ADMA6017I: Saved document C:\asv\b0403.04\WebSphere\AppServer\wstemp\Scriptfb5a487089\workspace\cells\BAMBIE\ applications\testSM.ear\deployments\testSM/Increment.jar\META-INF/ejb-jar.xml ADMA6016I: Add to workspace Increment.jar/META-INF/ejb-jar.xml ADMA6017I: Saved document C:\asv\b0403.04\WebSphere\AppServer\wstemp\Scriptfb5a487089\workspace\cells\BAMBIE\ applications\testSM.ear\deployments\testSM/Increment.jar\META-INF/MANIFEST.MF ADMA6016I: Add to workspace Increment.jar/META-INF/MANIFEST.MF ADMA6017I: Saved document C:\asv\b0403.04\WebSphere\AppServer\wstemp\Scriptfb5a487089\workspace\cells\BAMBIE\ applications\testSM.ear\deployments\testSM/Increment.jar\META-INF/ibm-ejb-jar-bnd.xmi ADMA6016I: Add to workspace Increment.jar/META-INF/ibm-ejb-jar-bnd.xmi ADMA6017I: Saved document C:\asv\b0403.04\WebSphere\AppServer\wstemp\Scriptfb5a487089\workspace\cells\BAMBIE\ applications\testSM.ear\deployments\testSM/Increment.jar\META-INF/Table.ddl ADMA6016I: Add to workspace Increment.jar/META-INF/Table.ddl ADMA6017I: Saved document C:\asv\b0403.04\WebSphere\AppServer\wstemp\Scriptfb5a487089\workspace\cells\BAMBIE\ applications\testSM.ear\deployments\testSM/Increment.jar\META-INF/ibm-ejb-jar-ext.xmi ADMA6016I: Add to workspace Increment.jar/META-INF/ibm-ejb-jar-ext.xmi add files for full module add/update: [Increment.jar/META-INF/ejb-jar.xml, Increment.jar/META-INF/MANIFEST.MF, Increment.jar/META-INF/ibm-ejb-jar-bnd.xmi, Increment.jar/META-INF/Table.ddl, Increment.jar/META-INF/ibm-ejb-jar-ext.xmi] ADMA5005I: Application myApp configured in WebSphere repository xmlDoc: [#document: null] root element: [app-delta: null] ****** delta file name: C:\asv\b0403.04\WebSphere\AppServer\wstemp\Scriptfb5a487089\workspace\cells\BAMBIE\ applications\testSM.ear/deltas/delta-1079551520393 ADMA5005I: Application myApp configured in WebSphere repository ADMA6011I: Deleting directory tree C:\DOCUME~1\lavena\LOCALS~1\Temp\app_fb5a48e969 ADMA5011I: Cleanup of temp dir for app myApp done. Update of myApp has ended.

Examples

• Jacl:
  $AdminApp updateInteractive myApp modulefile {-operation add -contents c:/apps/myApp/Increment.jar -contenturi Increment.jar -nodeployejb -BindJndiForEJBNonMessageBinding {{"Increment EJB module" Increment Increment.jar,META-INF/ejb-jar.xml Inc}}}

• Jython:
  print AdminApp.updateInteractive('myApp', 'modulefile', '[-operation add -contents c:/apps/myApp/Increment.jar -contenturi Increment.jar -nodeployejb -BindJndiForEJBNonMessageBinding [["Increment EJB module" Increment Increment.jar,META-INF/ejb-jar.xml Inc]]]')

• Use Jython list:

  bindJndiForEJBValue = [["Increment EJB module", "Increment","Increment.jar,META-INF/ejb-jar.xml", "Inc"]]
  
  
  
  print AdminApp.updateInteractive('myApp', 'modulefile', ['-operation', 'add', '-contents', 'c:/apps/myApp/Increment.jar', '-contenturi', 'Increment.jar', '-nodeployejb', '-BindJndiForEJBNonMessageBinding', bindJndiForEJBValue])
  

view

View the task specified by the task name parameter for the application or module specified by the application name parameter. Use -tasknames as the option to get a list of valid task names for the application. Otherwise, specify one or more task names as the option.

Target object: None.

Required parameters:

name

Name of the application or module to view.

Optional parameters:

bALL

The bALL boolean parameter retrieves and saves all access IDs for users and groups in the application bindings. Specify false to retrieve access IDs for users or groups that do not have an access ID in the application bindings.

-buildVersion

Specifies whether to display the build version of the application of interest.

Sample output

The command returns the following information if we specify the taskoptions value for the task name parameter:

MapModulesToServers
apWebModToVH
apRolesToUsers

The command returns the following information if we specify the mapModulesToServers task for the task name parameter:

MapModulesToServers: Selecting Application Servers

Specify the application server where we want to install the modules contained in your
application. Modules can be installed on the same server or dispersed among several servers:

Module: adminconsole
URI: adminconsole.war,WEB-INF/web.xml
Server: WebSphere:cell=juniartiNetwork, node=juniartiManager,server=dmgr

Examples

The following view command example lists each available task name:

• Jacl:
  $AdminApp view DefaultApplication {-tasknames}

• Jython:
  print AdminApp.view('DefaultApplication', ['-tasknames'])

The following view command example returns information for the mapModulesToServer task:

• Jacl:
  $AdminApp view DefaultApplication {-MapModulesToServers}

• Jython:
  print AdminApp.view('DefaultApplication', ['-MapModulesToServers'])

The following view command example returns information for the AppDeploymentOptions task:

• Jacl:
  $AdminApp view DefaultApplication {-AppDeploymentOptions}

• Jython:
  print AdminApp.view('DefaultApplication', '-AppDeploymentOptions')

The following view command example returns the build version for the DefaultApplication application:

• Jacl:
  $AdminApp view DefaultApplication {-buildVersion}

• Jython:
  print AdminApp.view('DefaultApplication', '-buildVersion')

Local mode

We can start the scripting client when no server is running, if we want to use only local operations. To run in local mode, use the -conntype NONE option to start the scripting client. You receive a message that we are running in the local mode. Running the AdminApp object in local mode when a server is currently running is not recommended. This is because any configuration changes made in local mode will not be reflected in the running server configuration and vice versa. If we save a conflicting configuration, we could corrupt the configuration.

If we are deploying an application in the local mode using wsadmin -conntype NONE, we must modify the wsadmin.bat or wsadmin.sh command file in install_root/bin. Complete the following steps:

1. Make a backup copy of the install_root/bin/wsadmin.bat or install_dir/bin/wsadmin.bat file.

2. Add the following lines of code to the wsadmin file right after the call to the setupCmdLine.bat or setupCmdLine.sh file:

   (AIX)

   LIBPATH="$WAS_LIBPATH":$LIBPATH
   export LIBPATH EXTSHM

   (HPUX)

   SHLIB_PATH="$WAS_LIBPATH":$SHLIB_PATH
   export SHLIB_PATH

   (Linux) (Solaris)

   LD_LIBRARY_PATH="$WAS_LIBPATH":$LD_LIBRARY_PATH
   export LD_LIBRARY_PATH

   (Windows)

   SET PATH=%WAS_PATH%

   Do not specify LD_LIBRARY_PATH_64 instead of LD_LIBRARY_PATH on the preceding export statement. Specifying LD_LIBRARY_PATH_64 on that export statement overrides any LD_LIBRARY_PATH values that exist in other scripts.

3. Save the updated wsadmin.bat or wsadmin.sh file.

4. Deploy the application.

Pattern matching

wsadmin AdminApp