Deploying WebLogic Server Applications
|
Deployment Tools Reference
This chapter provides a reference to different tools used in deploying modules to WebLogic Server. It includes the following sections:
weblogic.Deployer Utility
The weblogic.Deployer utility is new in WebLogic Server 7.0 and replaces the earlier weblogic.deploy utility, which has been deprecated. The weblogic.Deployer utility is a Java-based deployment tool that provides a command-line interface to the WebLogic Server deployment API. This utility was developed for administrators and developers who need to initiate deployment from the command line, a shell script, or any automated environment other than Java.
This section describes how to use the weblogic.Deployer utility to perform the following tasks:
Deploying Using weblogic.Deployer Utility
To deploy an application or its components using the weblogic.Deployer utility:
- Set up your local environment so that WebLogic Server classes are in your system CLASSPATH and the JDK is available. You can use the setenv script located in your server's /bin directory to set the CLASSPATH.
- Use the following command syntax:
% java weblogic.Deployer [options] [-activate|-deactivate|-remove|-cancel|-list] [files]
You can also list the specific -files in the archive that are to be deployed (or redeployed, or undeployed, or unprepared, or deactivated, or removed). The file list can include file names and directories relative to the root of the application. If you specify a directory, its entire subtree is deployed or redeployed.
weblogic.Deployer Actions and Options
Table 5-1 weblogic.Deployer Actions
Action
|
Description
|
activate
|
Deploys or redeploys the application specified by -name to the servers specified by -targets.
|
cancel
|
Attempts to cancel the task identified by -id if it is not yet completed.
|
deactivate
|
Deactivates the application on the target servers. Deactivation suspends the deployed components, leaving staged data in place in anticipation of subsequent reactivation. This command only works in the two-phase deployment protocol.
|
delete_files
|
Removes files specified in the file list and leaves the application activated. This is valid only for unarchived applications. You must specify target servers.
|
deploy
|
A convenient alias for -activate.
|
examples
|
Displays example usages of the tool.
|
help
|
Prints a help message.
|
list
|
Lists the status of the task identified by -id.
|
remove
|
Physically removes the application and any staged data from the target servers. The components are deactivated and the targets are removed from the applications configuration. If you remove the application entirely, the associated MBeans are also deleted from the system configuration. This command only works with the two-phase deployment model.
|
undeploy
|
A convenient alias for -unprepare.
|
unprepare
|
Deactivates and unloads classes for the application identified by -name on the target servers, leaving the staged application files in a state where they may be edited or quickly reloaded.
|
upload
|
Transfers the specified source file(s) to the administration server. Use this option when you are on a remote system and want to deploy an application that resides on the remote system. The application files are uploaded to the WebLogic Server administration server prior to distribution to named target servers.
|
version
|
Prints version information.
|
weblogic.Deployer options include:
Table 5-2 weblogic.Deployer Options
Option
|
Description
|
adminurl
|
https://<server>:<port> is the URL of the administration server. Default is http://localhost:7001.
|
debug
|
Turns on debug messages in the output log.
|
external_stage
|
Indicates that user wants to copy the application to the servers' staging area externally on their own, or using a third-party tool. When specified, WLS looks for the application under StagingDirectoryName (of target server)/applicationName.
|
id
|
The task identifier -id is a unique identifier for the deployment task. You can specify an -id with the -activate, -deactivate, or -remove commands, and use it later as an argument to -cancel or -list. Make sure the -id is unique from all other existing deployment tasks. The system generates an -id if you do not specify one.
|
name
|
The application -name specifies the name of the application being deployed. This can be the name of an existing, configured application or the name to use when creating a new configuration.
|
nostage
|
Does not stage the application; instead, deploys it from its current location which you specify using the -source option.
Defaults: nostage for admin server and stage for managed server targets.
|
nowait
|
Once the action is initiated, the tool prints the task id and exits. This is used to initiate multiple tasks and then monitor them later using the -list action.
|
password
|
Specifies the password on the command line. If you do not provide a password, you will be prompted for one.
|
remote
|
Signals that weblogic.Deployer is not running on the same machine as the administration server and that the source path should be passed through unchanged because it represents the path on the remote server.
|
source
|
Specifies the location of the archive, file or directory to be deployed. Use this option to set the application Path. The source option should reference the root directory or archive being deployed. If you are using it with the upload command, the source path is relative to the current directory. Otherwise, it is relative to the administration server root directory—the directory where the config.xml file resides.
|
stage
|
Indicates that application needs to be copied into the target servers staging area before deployment. Defaults: nostage for admin server, and stage for managed server targets. Sets the stagingMethod attribute on the application when it is created so that the application will always be staged. This value overrides the stagingMethod attribute on any targeted servers.
|
targets
|
Displays a comma-separated list of the targeted server and/or cluster names (<server 1>,...<component>@<server N>). Each target may be qualified with a J2EE component name. This enables different components of the archive to deployed on different servers. Default: For an application which is currently deployed, the default is all current targets. For a new application, it is deployed to the administration server, by default.
|
timeout
|
Seconds. Specifies the maximum time in seconds to wait for the completion of the deployment task. When the time expires, weblogic.Deployer prints out the current status of the deployment and exits.
|
user
|
User name.
|
verbose
|
Displays additional progress messages.
|
Example Uses of the weblogic.Deployer Utility
Below are example usages of the weblogic.Deployer utility.
Deploying a New Application
java weblogic.Deployer -adminurl http://admin:7001 -name app -source /myapp/app.ear -targets server1,server2 -activate
Redeploying an Entire Application
java weblogic.Deployer -source /myapp/app.ear -adminurl http://admin:7001 -name app -activate
Note: If you don't provide -source, or a list of updated files, this operation will have no effect because the system will assume that nothing has been changed in the application.
Deploying a Module Newly Added to an EAR
If you have added the module newmodule.war to the deployed application myapp.ear and updated the module in the application.xml file, you can deploy newmodule.war in myapp.ear using the following:
java weblogic.Deployer -username myname -password mypassword -name myapp.ear -activate -targets newmodule.war@myserver -source /myapp/myapp.ear
Note that this command will deploy the new module without redeploying the other modules in the application.
Redeploying Part of an Exploded Web Application (Refresh)
java weblogic.Deployer -adminurl http://admin:7001 -name app -activate jsps/login.jsp
where jsps is a directory in the top level of the exploded web application. Note that partial redeployment is only supported on exploded WAR files. The path is relative to the root of the application as originally deployed.
Deactivating an Application on All Active Targets, Making It Unavailable
java weblogic.Deployer -adminurl http://admin:7001 -name app -deactivate
Reactivating a Deactivated Application
java weblogic.Deployer -adminurl http://7001 -name app -activate
Removing an Application from All Targeted Servers
java weblogic.Deployer -adminurl http://admin:7001 -name app -targets server -remove
Cancelling a Deployment Task
java weblogic.Deployer -adminurl http://admin:7001 -cancel -id tag
Listing All Deployment Tasks
java weblogic.Deployer -adminurl http://admin:7001 -list
Deploying or Redeploying an Application to a Single Server
java weblogic.Deployer -activate -name ArchivedEarJar -source C:/MyApps/JarEar.ear -target server1
Deploying an Application to an Additional Server
java weblogic.Deployer -activate -name ArchivedEarJar -target server2
WebLogic Builder
WebLogic Builder is a WebLogic Server tool for generating and editing deployment descriptors for J2EE applications. It can also deploy applications to single servers.
See WebLogic Builder.
Deployment Management API
A deployment task is initiated through a DeployerRuntimeMBean—a singleton (an object for which only one instance exists) that resides on a WebLogic Administration Server. DeployerRuntimeMBean provides methods for activating, deactivating, and removing an application. These methods return a DeploymentTaskRuntimeMBean that encapsulates the request and provides the means for tracking its progress. DeploymentTaskRuntimeMBean provides ongoing status of the request through TargetStatus objects, one per target.
The WebLogic Server deployment management API is defined by the following WebLogic Server MBeans:
- DeployerRuntimeMBean—programmatic interface to deployment requests. Deployment requests provided through the DeployerRuntimeMBean manifest the configuration state into the application and appropriate component configuration MBeans. These MBeans persist the deployment state of applications in the WebLogic Server domain.
- DeploymentTaskRuntimeMBean—interface for encompassing deployment tasks.
The deployment management API is asynchronous. The client must poll the status or utilize ApplicationMBean notifications to determine when the task is complete.
For more information about WebLogic Server deployment management APIs, see the weblogic.management.deploy Javadoc.