Deploying Applications to WebLogic Server
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
The following sections describe the audience for and organization of this document:
This document is 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, you may need to perform activities such as:
See Developing WebLogic Server Applications for information about performing these development-related tasks.
weblogic.Deployer
tool syntax.
For additional information about deploying applications and modules to WebLogic Server, see these documents:
wldeploy
Ant task, and provides information about the WebLogic Server deployment descriptor for Enterprise Applications.
The following sections describe new deployment features introduced in WebLogic Server 9.0.
In J2EE 1.4, the JSR-88 specification defines a standard API for application configuration and deployment to a target application server environment. WebLogic Server 9.0 supports the J2EE 1.4 deployment API as described in Deployment Standards. See the J2EE v1.4 Documentation for more information about the J2EE 1.4 deployment specification.
The basic J2EE 1.4 deployment API configuration process provides a simple way for standardized deployment tools to deploy J2EE applications on multiple application server products. However, it does not help in the process of migrating an application's configuration from one environment to another within an organization. The WebLogic Server 9.0 deployment API extends the J2EE 1.4 deployment API to provide support for exporting an application's configuration for deployment to multiple WebLogic Server environments, such as testing, staging, and production domains. See WebLogic Server Deployment Features.
WebLogic Server introduces a new application directory structure for storing deployment plans and generated WebLogic Server deployment descriptor files along with the J2EE application archive or exploded archive directory. The directory structure separates generated configuration files from the core application files, so that configuration files can be easily changed or replaced without disturbing the application itself. See Creating an Application Installation Directory.
WebLogic Server enables you to redeploy a new version of a production application without affecting existing clients to the application, and without interrupting the availability of the application to new client requests. See Updating Applications in a Production Environment.
To support the production redeployment strategy, WebLogic Server now recognizes a unique version string entry in an Enterprise Application's MANIFEST.MF
file. When a redeployment operation is requested, WebLogic Server checks the version string to determine if a new version of the application should be deployed.
If an application does not specify a version string in the manifest file, you can specify one during deployment or redeployment using the -appversion
option to weblogic.Deployer
.
The Name
attribute, retrieved from AppDeploymentMBean
, now returns a unique application identifier consisting of the deployed application name and the application version.
Versioned applications must use the new ApplicationName
attribute, instead of the Name
attribute. to get the application name. Non-versioned applications can use the Name
attribute because application version is only required for versioned applications.
Distributing an application now copies deployment files to target servers and places the application in a prepared state. You can then use the -adminmode
option, as described in Starting a Distributed Application in Administration mode, to start the application in Administration mode, which restricts access to the application to a configured Administration channel so you can perform final testing without opening the application to external client connections. See Distributing Applications to a Production Environment and Distributing a New Version of a Production Application.
JMS and JDBC configurations in WebLogic Server 9.0 are now stored in XML documents that conform to the appropriate WebLogic Server schema for the resource: weblogic-jmsmd.xsd
or weblogic-jdbc.xsd
. You create and manage JMS and JDBC resources either as system modules, similar to the way they were managed prior to version 9.0, or as application modules, similar to standard J2EE modules.
A JMS or JDBC application module can be deployed as a stand-alone resource, in which case the resource is available to the servers or cluster targeted during the deployment process, or as part of an Enterprise application. An application module deployed as part of an Enterprise Application is available only to the enclosing application (an application-scoped resource). Using application-scoped resources ensures that an application always has access to required resources, and simplifies the process of deploying the application into new environments.
In contrast to system modules, application modules are owned by the developer who created and packaged the module, rather than the Administrator who deploys the module. This means that the Administrator has more limited control over JDBC and JMS application modules. When deploying an application module, an Administrator can change resource properties that were specified in the module, but cannot add or delete resources. System modules are created by the Administrator via the WebLogic Administration Console, and can be changed or deleted as necessary by the Administrator.
WebLogic Server includes a new deployment API to implement and extend the J2EE 1.4 deployment specification. All WebLogic Server deployment tools, such as the Administration Console, weblogic.Deployer
tool, and wldeploy
Ant task, use the deployment API to configure, deploy, and redeploy applications in a domain. You can use the deployment API to build your own WebLogic Server deployment tools, or to integrate WebLogic Server configuration and deployment operations with an existing JSR-88-compliant tool.
The new WebLogic Server deployment API is provided in the following packages:
weblogic.deploy.api.model
provides the WebLogic Server implementation of, and extensions to the javax.enterprise.deploy.model
package. This package contains the interfaces used to represent the J2EE configuration of a deployable object (an Enterprise Application or stand-alone module).weblogic.deploy.api.spi
provides the implementation classes required to configure applications for deployment to WebLogic Server targets. This package enables a deployment tool to represent the WebLogic Server-specific deployment configuration for an Enterprise Application or stand-alone module.weblogic.deploy.api.shared
provides classes that represent the WebLogic Server-specific deployment commands, module types, and target types. These objects are shared between the model and SPI packages.weblogic.deploy.api.tools
provides WebLogic Server helper classes that you can use to easily configure applications and perform deployment operations.See the Programming WebLogic Deployment.
The weblogic.management.runtime.DeployerRuntimeMBean
API is deprecated in this release. Deployment tools should use the new weblogic.deploy.api
packages for all application configuration and deployment tasks. See the WebLogic Server 9.0 API Reference.
The use of alternate deployment descriptors for deploying applications modules is deprecated in this release. Use J2EE 1.4 deployment API-style deployment configuration and deployment plans, instead of alternate deployment descriptors, to maintain custom configurations outside of a packaged application. See Configuring Applications for Production Deployment.
This release deprecates the use of the weblogic.Deployer -redeploy
module-uri
syntax for redeploying a single module in a deployment. Instead, use production redeployment or use the -redeploy -targets
module@target
syntax, as described in Using Partial Redeployment for J2EE Module Updates.
Each WebLogic Server 9.0 deployment descriptor property is now formally classified into one of the following four categories: non-configurable, dependency, declaration, or configurable. These categories are used during the configuration export process to select properties to expose as variables in the deployment plan. SeeExporting an Application for Deployment to New Environments.
WebLogic Server 9.0 introduces a new JMS Server deployment target that you can select when deploying JMS modules to a domain. See Using Sub-Module Targeting with JMS Application Modules.
WebLogic Server includes these new deployment tools:
weblogic.PlanGenerator
—The PlanGenerator
utility generates WebLogic Server deployment plans and exports deployment descriptor properties to deployment plan variables using the Formal Classification for WebLogic Server Deployment Descriptor Properties. See the weblogic.PlanGenerator Command Line Reference for more information.These tools have been changed to support the new configuration and deployment features:
weblogic.Deployer
has been updated to use the new deployment API to perform all deployment-related operations. weblogic.Deployer
provides new command-line options for:
See the weblogic.Deployer Command-Line Reference.
The wldeploy
Ant task has been updated to support the same new features introduced with weblogic.Deployer
. See the wldeploy Ant Task Reference in Developing Applications with WebLogic Server.
The Administration Console contains new deployment assistants for installing applications, new screens for configuring applications, and new controls for performing deployment operations and redeploying production applications.
The WebLogic Server 6.x single-phase deployment protocol, deprecated in versions 7.x and 8.x, is no longer supported in WebLogic Server 9.0. All deployments now use the two-phase deployment protocol.
![]() ![]() |
![]() |
![]() |