Deploying WebLogic Server Applications
This document is written mainly for Administrators who want to deploy Java 2 Platform, Enterprise Edition (J2EE) applications or application modules to WebLogic Server. This document assumes that you are working in a production environment, which is generally characterized by multiple WebLogic Server instances or clusters running on multiple machines. It also assumes that you have one or more application module archive files that have been tested and are ready to deploy on a production server.
If you are an engineer and need to deploy or package applications in a development environment, see Developing WebLogic Server Applications. Also see Deployment Topics for Developers on page 4-13 for information about deployment features that apply to development environments.
A deployment unit refers to a J2EE application (an Enterprise Application or Web Application) or a standalone J2EE module (an EJB or Resource Adapter) that has been organized according to the J2EE specification and can be deployed to WebLogic Server.
For each type of deployment unit, the J2EE specification defines both the required files and their location in the directory structure of the application or module. Deployment units may include Java classes for EJBs and servlets, resource adapters, Web pages and supporting files, XML-formatted deployment descriptors, and even other modules.
J2EE does not specify how a deployment unit is deployed on the target server—only how standard applications and modules are organized. WebLogic Server supports deployments that are packaged either as archive files using the
jar utility, or as exploded archive directories.
J2EE provides specifications for creating standalone modules, which include Enterprise JavaBeans and resource adapter modules. WebLogic Server also supports deploying Web Services modules, which are not part of the J2EE specification.
Standalone modules generally provide parts of a larger, distributed application, but do not necessarily provide a direct user interface. For more information on a particular module type, refer to the J2EE 1.3 specification at: http://java.sun.com/j2ee/download.html#platformspec.
Enterprise JavaBeans (EJBs) are reusable Java components that implement business logic and enable you to develop component-based distributed business applications. EJB modules are packaged as archive files having a
.jar extension, but are generally deployed as exploded archive directories. The archive file or exploded archive directory for an EJB contains the compiled EJB classes, optional generated classes, and XML deployment descriptors for the EJB. See Programming WebLogic Server Enterprise JavaBeans for more information on the different types of EJBs.
A Resource Adapter (also referred to as a connector) adds Enterprise Information System (EIS) integration to the J2EE platform. Connectors provide a system-level software driver that WebLogic Server can use to connect to an EIS. Connectors contain both the Java classes, and if necessary, the native components required to interact with the EIS. See Programming WebLogic Server J2EE Connectors for more information.
Web Services are a type of service that can be shared by and used as components of distributed Web-based applications. They commonly interface with existing back-end applications, such as customer relationship management systems, order-processing systems, and so on.
A Web Service module is a virtual module that includes both a Web Application and a Web Service deployment descriptor at minimum. A Web Service module may also include EJBs that implement the Web Service. See Programming WebLogic Web Services for more information.
J2EE also defines several different types of deployable applications: Web Applications, Enterprise Applications, and client applications. Applications generally include one or more standalone J2EE modules to provide a logical service, and may also provide a direct user interface to the applications' contents.
web.xmldeployment descriptor, a J2EE standard XML document that configures the contents of a WAR file.
Web Applications may also contain JSP tag libraries, static .html and image files, supporting classes and
.jar files, and a
weblogic.xml deployment descriptor, which configures WebLogic Server-specific elements for Web Applications. See Developing Web Applications for WebLogic Server for more information.
An Enterprise Application is packaged as a JAR file with an
.ear extension, but is generally deployed as an exploded EAR directory. An exploded EAR directory contains all of the JAR, WAR, and RAR modules (also in exploded format) for an application as well as the XML descriptor files for the Enterprise Application and its bundled applications and modules. See Developing WebLogic Server Applications for more information.
The J2EE specification provides the ability to include a client application archive file within an Enterprise Application. A J2EE client application module contains the Java classes that execute in the client JVM (Java Virtual Machine) and deployment descriptors that describe EJBs (Enterprise JavaBeans) and other WebLogic Server resources used by the client. This enables both the server-side and client-side components to be distributed as a single unit. Client modules in an EAR are defined using the J2EE standard
application-client.xml deployment descriptor and an optional WebLogic Server descriptor,
Startup and shutdown classes are Java classes that you can configure to load and execute when you start up or gracefully shut down a server. The deployment process for startup and shutdown classes differs from other deployable units, because you do not specify any actual deployment files. Instead, you identify the servers that will execute the class, and specify the classpath and optional arguments to use for execution. See Startup and Shutdown Classes in the Administration Console Online Help for more information.
A key file that defines each type of deployment unit is its XML deployment descriptor. The deployment descriptor is an XML document that defines certain runtime characteristics for the application or module. By editing the XML deployment descriptor, you modify runtime behavior for the deployment unit without having to recompile code or rebuild the deployment unit itself; the new behavior is read from the descriptor file and implemented when you deploy the application or module.
For example, the WebLogic deployment descriptors for an EJB allow you to specify the number of beans to keep in the cache when you deploy the EJB to a server. If you need to change the number of cached beans for performance reasons, you simply change the deployment descriptor.
J2EE defines the organization and content of required XML deployment descriptors for each deployment unit. In addition, you can specify optional WebLogic Server XML deployment descriptors to configure WebLogic-specific behavior for handling the deployment. WebLogic Server deployment descriptors enable you to maintain the portability of the original J2EE module while utilizing features only available in WebLogic Server.
Table 1-1 lists the types of deployment units and their associated J2EE-standard and WebLogic-specific deployment descriptors.
Web Services have no J2EE descriptor. However, a Web Service module is typically packaged as an Enterprise Application that contains both a Web Application and EJB modules. For this reason, Web Services modules generally require J2EE descriptors required for those modules.
You create deployment descriptors manually, or generate them with WebLogic Server Java-based utilities. When you receive a J2EE-compliant JAR file from a developer, it should already contain the J2EE-defined and WebLogic Server deployment descriptors. The Administration Console also enables you to modify key deployment descriptor elements of a deployed application, which can help you tune the application's run-time behavior and performance.
In most production environments, you receive a deployment unit as an archive file. An archive file is a single file that contains all of an application's or module's classes, static files, directories, and deployment descriptor files. Archive files are typically created by using the
jar utility or Ant's
.earfiles, and can contain any combination of EJBs, Web Applications, and Resource Adapters.
.earfiles or as
Although you can deploy an archive file directly to WebLogic Server, deploying Exploded Archive Directories provides some additional redeployment capabilities.
An exploded archive directory contains the same files and directories as a
jar archive. However, the files and directories reside directly in your file system and are not packaged into a single archive file with the
If you are unpacking an archive file that contains other module archive files (for example, an Enterprise Application or Web Service that includes JAR or WAR files) and you want to perform partial updates of those modules, you must expand the embedded archive files as well. Make sure that you unpack each module into a subdirectory having the same name as the archive file. For example, unpack a module named
myejb.jar into a
/myejb.jar subdirectory of the exploded Enterprise Application directory.
Note: If you want to use different subdirectory names for the archived modules in an exploded EAR file, you must modify any references to those modules in the application itself. For example, you must update the URI values specified in
CLASSPATH entries in the
To deploy a new archive or exploded archive directory, the file(s) must be accessible by the Administration Server for your domain. This means they must reside on the Administration Server machine, or they must be available via a remote, network-mounted directory.
When using the Administration Console to deploy a module for the first time, you have the option to upload files to the Administration Server machine if they are not otherwise available. Files are uploaded to the location specified by the Upload Directory Name attribute.
Deployment targets are the servers to which you deploy an application or standalone module. Valid deployment targets include WebLogic Server instances, clusters, and virtual hosts. During the deployment process, you select the list of targets from the available servers, clusters, and virtual hosts configured in your domain. You can also change the target list at any time after you have deployed a module.
You can deploy applications and standalone modules to one or more Managed Servers in a domain, or to the Administration Server in a single-server domain. Although you can deploy to the Administration Server in a multiple-server domain, this practice is not recommended. The Administration Server in a multiple-server domain should be used only for administration purposes.
If you are deploying to a cluster of WebLogic Server instances, by default the deployment targets all server instances in the cluster. This corresponds to homogenous module deployment, which is recommended in most clusters. If you want to deploy a module only to a single server in the cluster (that is, "pin" a module to a servers), you can also select the individual server name. This type of deployment is less common, and should be used only in special circumstances where pinned services are required. See Understanding Cluster Configuration and Application Deployment for more information.
Virtual hosting allows you to define host names to which servers or clusters respond. When you use virtual hosting, you use DNS naming to specify one or more host names that map to the IP address of a WebLogic Server or cluster, and you specify which applications are served by each virtual host.
You select a configured virtual host name as you would a WebLogic Server instance or cluster name during deployment. See Configuring Virtual Hosting in Configuring and Managing WebLogic Server for more information.
Note: If the context root for a Web Application is blank in
weblogic.xml file and the virtual host is targetted to a server instance, the Web Application should be deployed only to the Virtual Host or to the server instance.
The deployment staging mode determines how deployment files are made available to target servers that must deploy an application or standalone module. WebLogic Server provides three different options for staging files: stage mode, nostage mode, and external_stage mode. The following table describes the behavior and best practices for using the different deployment staging modes.
The Administration Server does not copy deployment unit files. Instead, all servers deploy using the same physical copy of the deployment files, which must be directly accessible by the Administration Server and target servers.
With nostage deployments of exploded archive directories, WebLogic Server automatically detects changes to a deployment's JSPs or Servlets and refreshes the deployment. (This behavior can be disabled if necessary.)
The Administration Server does not copy deployment files. Instead, the Administrator must ensure that deployment files are distributed to the correct staging directory location before deployment (for example, by manually copying files prior to deployment).
With external_stage deployments, the Administration Server requires a copy of the deployment files for validation purposes. Copies of the deployment files that reside in target servers' staging directories are not validated before deployment.
Most deployments use either stage or nostage modes, and the Administration Console automatically suggests the appropriate mode when you deploy an application or module. For more information about staging modes, see Deployment Staging Modes and Staging Directories in Advanced Deployment Topics.
When you first deploy an application or standalone module to one or more WebLogic Server instances, you specify a deployment name to describe collectively the deployment files, target servers, and other configuration options you selected. You can later redeploy or stop the deployment unit on all target servers by simply using the deployment name. The deployment name saves you the trouble of re-identifying the deployment files and target servers when you want to work with the deployment unit across servers in a domain.
If you do not specify a deployment name at deployment time, the deployment tool selects a default name. For exploded archive directories, the default deployment name is the name of the top-level directory you deploy. For archive files, the deployment name is the name of the archive file without the file extension (
myear for the file
weblogic.Deployer—provides a command-line based interface for performing both basic and advanced deployment tasks.
weblogic.Deployer when you do not have access to a browser or graphical user interface environment, and you want to perform deployment tasks. You can also use
weblogic.Deployer when you want to automate deployment tasks through shell scripts or batch processes, rather than through Ant tasks.
wldeployis an Ant task version of the
weblogic.Deployerutility. You can automate deployment tasks by placing
wldeploycommands in an Ant
build.xmlfile and running Ant to execute the commands.
applicationsdirectory of a server allows you to deploy an application quickly for evaluation or testing in a development environment.
.war, and so forth) when distributing files to different users or environments.
wldeployAnt task all provide similar functionality for deploying applications:
weblogic.Deployerto integrate deployment commands with existing administrative shell scripts or automated batch processes.
wldeployin conjunction with the split development directory for developing and deploying new applications.
wldeploycan also be used in place of
weblogic.Deployerin administration environments that use Ant, rather than shell scripts.
wldeploy, rather than the
applicationsdirectory, to deploy your own applications during development. The
applicationsdirectory is best used for quickly running new applications in a test or temporary. For example, if you download a sample application and want to evaluate its functionality, the
applicationsdirectory provides a quick way to deploy the application into a development server.
Note: An application becomes unavailable to clients during redeployment. WebLogic Server doesn't guarantee the operation of the application and deployment task if there is an access from the client at this time. For this reason, redeployment is not recommended for use in a production environment.
Note: An application becomes unavailable to clients during undeployment. WebLogic Server doesn't guarantee the operation of the application and deployment task if there is an access from the client at this time.
The built-in security roles for "Admin" and "Deployer" users allow you to perform deployment tasks using the WebLogic Server Administration Console. See Starting the Administration Console in the Administration Console Online Help for more information about the built-in security roles.