Deployment Tools

2017-11-03 09:05:02

WebLogic provides several tools to configure and deploy J2EE applications and modules. WebLogic Builder is one such graphical tool that allows you to generate and modify the deployment descriptors of J2EE applications. It can even deploy applications to a single WebLogic instance. However, its primary role is in packaging J2EE applications because its deployment options are rudimentary. For this reason, we won't consider WebLogic Builder any further. Instead, we look at how to use the Administration Console to deploy J2EE components to multiple WebLogic instances and/or clusters. In addition, WebLogic provides a command-line deployer tool, which mimics the deployment capabilities of the Administration Console and more.

12.2.1 Administration Console

The Administration Console lets you deploy, redeploy, and undeploy J2EE applications and modules. Expand the Deployments node from the left pane of the Administration Console. Here, you can select from one of the following nodes: Applications, EJB Modules, Web Application Modules, Connector Modules, and Startup & Shutdown. If you click one of these nodes, you'll find the "Deploy a new ..." option on the right pane, which enables you to deploy a new application or module. For instance, if you've chosen the Web Applications node, then from the right pane you can select the "Deploy a new Web Application Module" option to deploy a new web application.

Subsequent deployment screens let you choose an EAR (enterprise application), EJB JAR (EJB module), RAR (resource adapter), or WAR (web application) from the filesystem for deployment. You even can upload the application component through your web browser. You also can select a directory from the filesystem instead of a packaged module, in which case WebLogic expects the directory to hold an exploded form of the same module. After choosing the component, you need to target the module to the WebLogic instances in your domain to which the component ought to be deployed. The component may be targeted to an individual server, cluster, or virtual host configured for the domain. Remember, when you target the enterprise application (EAR) to a server or cluster, it is the individual modules within the EAR that are targeted, and not the EAR itself.

After this, you must indicate how the module will be staged i.e., how the application files will be copied over to the different servers. You will be presented with two choices:

"Copy this application onto every target for me"

This option instructs WebLogic to copy the module onto every targeted server. Each server will then deploy the application using its own copies of the module. This is a deployment in a staged mode.

"I will make the application accessible from the following location"

This option requires you to supply the path of the directory that holds the application. Each targeted server must then access the source from the given directory; therefore, the directory must be shared among all of the targeted servers. This corresponds to a deployment in a nostage mode.

We look at the different application staging modes later in Section 12.3.1. For now, you must note that the Administration Console doesn't allow you to create a deployment in the externally staged mode.

Once the application has been deployed, you can modify the deployment by selecting the relevant node from under the Deployments node in the left pane of the Administration Console, and then navigating to either the Deploy or the Targets tabs. The Targets tab lists the servers or clusters to which the component has been targeted. Changing the targets of a deployed application usually will come into effect only when the server subsequently is restarted, or in some cases if you undeploy and redeploy the application. The Deploy tab lists the deployment status of the component for each target. Choose the Stop option to undeploy the application component from the particular target, and the Redeploy option to initiate a fresh deployment for the component on the particular target.

12.2.2 WebLogic's Deployer Tool

The Deployer tool is a powerful tool to manage the deployment and redeployment of applications on WebLogic. It even allows you to deploy specific modules within an EAR for instance, you can use the Deployer tool to deploy a WAR that has just been added to an EAR. Your understanding of the Deployer tool won't be complete until we've looked at WebLogic's two-phase deployment strategy and its support for different application staging modes. We begin by examining the syntax and a few examples of how to use the Deployer tool.

Here is the general syntax for invoking the Deployer tool:

-user, -password, and -adminurl are command-line options that must be supplied at all times. They allow you to specify the username/password of the WebLogic user that is executing the deployment operation, and the URL of the Administration Server. The following example shows how to use the deployer tool to list the status of current deployment tasks:

java weblogic.Deployer -user system -password pst -adminurl t3://10.0.10.10:8001/ -list

Don't be surprised if we omit these options from further examples of the Deployer tool. We'll assume you understand that these options need to be passed to the Deployer tool on every invocation.

Any task initiated using the Deployer tool is executed synchronously by default. You can execute a task asynchronously by supplying the -nowait command-line option. You can view this list of all deployment tasks by specifying the -list option. By selecting the Tasks node from the left pane of the Administration Console, you can view the same list of tasks. You also can abort a task that hasn't completed yet by using the -cancel option. In WebLogic 8.1, the Deployer tool supports two additional options: the -listtask option for listing all deployment tasks that are currently in progress, and the -listapps option for listing all modules that are currently deployed.

Any deployment task that needs to operate on one or more modules must refer to the module by its name. For example, you can undeploy an application named myapp using the following command:

java weblogic.Deployer -undeploy -name myapp

Here, the -name option lets you specify the name of the application or module that must be undeployed. The -listapps option lets you list the names of all deployed modules. Use the -deploy option to deploy or redeploy an application or its modules. The -deploy option usually is followed by the -targets option, which specifies the servers or clusters to which the application or module ought to be deployed. The following example shows how to deploy a WAR:

java weblogic.Deployer -targets server1, server2 -name myWar -source oo.war -deploy oo.war

In this case, the -source option specifies the location of the web archive or directory that holds the web application. In WebLogic 8.1, you don't need to use the -source option and can write something like this instead:

java weblogic.Deployer -targets server1, server2 -name myWar -deploy oo.war

If you are not on the Administration Server, you can use the -upload option to first upload the application to the Administration Server, and then subsequently deploy it to all targeted servers. The following command shows how to deploy a web application to a cluster from a machine that doesn't host the Administration Server:

java weblogic.Deployer -targets mycluster -name oo -deploy -stage -upload oo.war

The web application will be deployed once the WAR file has been copied to the upload directory on the Administration Server.

You can refine the targets even further by referring to individual modules within the application that ought to be deployed. For example, assume that you have added a new web application to a deployed EAR, and updated the EAR's deployment descriptors to reflect this change. You then can deploy the new web application only, without having to redeploy the entire EAR, as follows:

java weblogic.Deployer -targets myNewWar@server1 -name myEar -deploy myEar.ear

Note that the @target suffix used to specify target servers is not required if the targets of the new module are the same as those of the already deployed EAR. This feature can be used to deploy different parts of an EAR to different servers by qualifying each target server with the name of the module that should be deployed to that server. The following example shows how to deploy a WAR and EJB JAR to different servers, even though they are both modules within the same EAR:

java weblogic.Deployer -name myEar -targets myWar@webserver,myEJB@ejbserver -deploy myEar.ear

Exploded (unarchived) web applications also support partial redeployment; we saw an example of this in Chapter 2:

java weblogic.Deployer -name mywebapp -targets server1,server2 -redeploy help/*.jsp

Here, the file list is specified relative to the root of the deployed application. So, for example, if the JSPs were part of a web application, mywebapp, packaged within an EAR, the file list would have to be specified as mywebapp/help/*.jsp. If you supply a -targets option, the files will be refreshed on all of the targeted servers. If you remove the -targets option, the specified files would be redeployed on all servers to which the web application is deployed. We will look at many more examples of the Deployer tool when we turn our attention to two-phase deployment and application staging.

Категории