Skip navigation.

Deploying Applications to WebLogic Server

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

Deploying Applications and Modules

The following sections describe how to perform basic and advanced deployment tasks using the weblogic.Deployer utility:

 


Overview of Common Deployment Scenarios

The sections that follow organize common deployment tasks into several general categories, starting with the most basic tasks and progressing to more advanced tasks. Before you deploy an application, perform the appropriate tasks described in Configuring Applications for Production Deployment.

 


Uploading Deployment Files from a Remote Client

In order to deploy an application or module to a domain, the deployment file(s) must be accessible to the domain's Administration Server. If the files do not reside on the Administration Server machine or are not available to the Administration Server machine via a network mounted directory, use the -upload option to upload the files before deploying them:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -deploy -upload c:\localfiles\myapp.ear

To upload an exploded archive directory, specify the directory name instead of an archive filename (for example c:\localfiles\myappEar).

When you upload files to the Administration Server machine, the archive file is automatically placed in the server's upload directory. You can configure the path of this directory using the instructions in Changing the Default Staging Behavior for a Server.

 


Deploying to a Single-Server Domain

A single-server WebLogic Server domain, consisting only of an Administration Server, represents the simplest scenario in which to deploy an application or module. If you are deploying files that reside on the same machine as the domain, use the -deploy command and identify the file location, with connection arguments for the Administration Server. For example:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -deploy c:\localfiles\myapp.ear

In the above command, WebLogic Server creates a default deployment name of myapp, as described in Understanding Default Deployment Names, because myapp is the name of the deployment file without the extension. If you want to specify a non-default deployment name, use the -name option, as in:

java weblogic.Deployer -adminurl http://localhost:7001 
   -user weblogic -password weblogic -deploy
   -name myTestApplication c:\localfiles\myapp.ear

 


Deploying an Application with a Deployment Plan

When you use weblogic.Deployer to deploy an application, the deployment plan and WebLogic Server deployment descriptors must define a valid configuration for the target environment, or the deployment fails. This means you cannot use weblogic.Deployer with a deployment plan that defines null variables for an application's required resource bindings.

To deploy an application and deployment plan using weblogic.Deployer, include the -plan option with the -deploy command, as in:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
     -password weblogic -deploy -name myTestDeployment
     -source /myDeployments/myApplication.ear
     -targets myCluster -stage
     -plan /myDeployments/myAppPlan.xml

If you are deploying from an application root directory and the deployment plan is located in the /plan subdirectory, you still need to identify both the actual deployment source files the plan to use for deployment, as in:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
     -password weblogic -deploy -name myTestDeployment
     -source /myDeployments/installedApps/myApplication/app/myApplication.ear
     -targets myCluster -stage
     -plan /myDeployments/installedApps/myApplication/plan/plan.xml

When you deploy or distribute an application with a deployment plan, the deployment plan and any generated deployment descriptors are copied to the staging directories of target servers along with the application source files.

 


Deploying an Application that Looks Up System Resources from JNDI During preStart

Because preStart application lifecycle listeners are invoked during the prepare phase of an application—which occurs when an edit session is activated—JNDI lookup of system resources will fail if you create a new system resource during the same edit session in which you deploy an application that uses the system resource. For example, if you acquire an edit lock from the Administration Console, then create a new JDBC system resource and deploy an application that uses the new JDBC system resource during the same edit session (in other words, before activating changes in the Administration Console), JNDI lookup of the JDBC system resource will fail because the preStart application lifecycle listeners were invoked before the system resource was activated. To look up system resources from JNDI in your preStart lifecycle listeners, BEA recommends that you create the system resource during startup or during a separate edit session, before you deploy any applications that use the system resource. For example, you could:

  1. Acquire an edit lock by clicking Lock & Edit in the Administration Console.
  2. Create the desired system resource. For information, see Create JMS system modules in Administration Console Online Help.
  3. Complete the edit session by clicking Activate Changes in the Administration Console.
  4. Acquire another edit lock by clicking Lock & Edit in the Administration Console.

Deploy the application that uses the system resource you created in step 2. For information on deploying applications from the Administration Console, see Deploy applications and modules in Administration Console Online Help.

See Overview of J2EE Libraries and Optional Packages in Developing Applications with WebLogic Server for more information.

 


Targeting Deployments to Servers, Clusters, and Virtual Hosts

In most production environments, you typically deploy applications to one or more Managed Servers configured in a Weblogic Server domain. In some cases, the servers may be included as part of a WebLogic Server cluster, or a virtual host may be used for directing Web application requests. The term deployment target refers to any server or collection of servers to which you can deploy an application or module.

Understanding Deployment Targets

Deployment targets are the servers or groups of servers on which you deploy an application or stand-alone module. During the deployment process, you select the list of targets from the available targets configured in your domain. You can also change the target list after you have deployed a module.

The following table describes all valid deployment targets for WebLogic Server, and lists the types of modules that you can deploy to each target.

Table 5-1 WebLogic Server 9.0 Deployment Targets

Target Type

Description

Valid Deployments

WebLogic Server Instance

A WebLogic Server instance, such as an Administration Server in a single-server domain, or a Managed Server.

J2EE Applications
J2EE modules
JMS, JDBC, or WLDF modules
J2EE Libraries

Cluster

A configured cluster of multiple WebLogic Server instances

J2EE Applications
J2EE modules
JMS, JDBC, or WLDF modules
J2EE Libraries

Virtual Host

A configured host name that routes requests for a particular DNS name to a WebLogic Server instance or cluster. See Configuring Virtual Hosting in Designing and Configuring WebLogic Server Environments for more information.

Web applications

JMS Server

A JMS Server configured in a Weblogic Server domain

A JMS queue or topic defined within a JMS module*

*When deployed as a stand-alone application module, a JMS, JDBC, or WLDF resource appears as J2EE deployment in the Administration Console.

A stand-alone JMS application module can be targeted to server, cluster, or virtual host targets; queues and topics defined within a JMS module can be further targeted to a configured JMS server. For information on sub-module targeting, see Using Sub-Module Targeting with JMS Application Modules.

Deploying to One or More Targets

To deploy to a single WebLogic Server target, list the configured target name after the -targets option to weblogic.Deployer. For example, to deploy a Web application to a configured virtual host named companyHost, use the command:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -deploy -targets companyHost c:\localfiles\myWebApp.ear

Specify multiple targets using a comma-separated list, as in:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -deploy -targets ManagedServer-1,ManagedServer-2
   c:\localfiles\myapp.ear

Deploying to a Cluster Target

If you specify a cluster target (using -targets mycluster), WebLogic Server targets all server instances in the cluster by default. 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), specify the individual server instance name, rather than the cluster, as the target. 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 in Using WebLogic Server Clusters for more information.

Note: Pinning a deployment to a subset of server instances in a cluster (rather than to a single server on the cluster) is not recommended and will generate a warning message.

When you deploy an application to a cluster target, WebLogic Server ensures that the deployment successfully deploys on all available members of the cluster. If even a single, available WebLogic Server instance in the cluster cannot deploy the application, the entire deployment fails and no servers in the cluster start the application. This helps to maintain homogeneous deployments to the cluster, because deployment operations succeed or fail as a logical unit.

If a clustered server is unreachable at the time of deployment (for example, because of a network failure between the Administration Server and a Managed Server, or because a cluster member is shut down) that server does not receive the deployment request until the network connection is restored. This default behavior ensures that most deployment operations succeed, even when servers are taken offline.

Enforcing Consistent Deployment to all Configured Cluster Members

The default cluster deployment behavior ensures homogeneous deployment for all clustered server instances that can be reached at the time of deployment. However, if the Administration Server cannot reach one or more clustered servers due to a network outage, those servers do not receive the deployment request until the network connection is restored. For redeployment operations, this can lead to a situation where unreachable servers use an older version of the deployed application, while reachable servers use the newer version. When the network connection is restored, previously-disconnected servers may abruptly update the application as they receive the delayed redeployment request.

It is possible to change WebLogic Server's default deployment behavior for clusters by setting the ClusterConstraintsEnabled option when starting the WebLogic Server domain. The ClusterConstraintsEnabled option enforces strict deployment for all servers configured in a cluster. A deployment to a cluster succeeds only if all members of the cluster are reachable and all can deploy the specified files.

Warning: Do not use the ClusterConstraintsEnabled option unless you have an extremely reliable network configuration, and you can guarantee that all cluster members are always available to receive deployment and redeployment requests. With ClusterConstraintsEnabled, WebLogic Server will fail all deployment operations to a cluster if any clustered server is unavailable, even if a single server has been shut down for maintenance.

To set the ClusterConstraintsEnabled for the domain when you start the Administration Server, include the appropriate startup argument:

 


Using Module-Level Targeting for Deploying an Enterprise Application

An Enterprise Application (EAR file) differs from other deployment units because an EAR can contain other module types (WAR and JAR archives). When you deploy an Enterprise Application using the Administration Console, you can target all of the archive's modules together as a single deployment unit, or target individual modules to different servers, clusters, or virtual hosts.

You can also use module-level targeting to deploy only a subset of the modules available in an EAR. This can simplify packaging and distribution of applications by packaging multiple modules in a single, distributable EAR, but targeting only the modules you need to each domain.

Module-Targeting Syntax

To target individual modules in an Enterprise Application, use the module_name@target_name syntax. For example:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name myEnterpriseApp
   -targets module1@myserver1,module2@myserver2,module3@myserver3
   -stage -deploy c:\localfiles\myEnterpriseApp.ear

Targeting Web Application Modules

To target Web application modules that are part of an .ear file, you can use the Web application's context-root name as the module name or specify the web-uri.

For example, if the application.xml file for a file, myEnterpriseApp.ear, defines:

<module>
  <web>
    <web-uri>myweb.war</web-uri>
    <context-root>/welcome</context-root>
  </web>
</module>

You can deploy only the Web application module by using the context-root name:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mywebapplication -targets /welcome@myserver1
   -stage -deploy c:\localfiles\myEnterpriseApp.ear

You can deploy only the Web application module by using the web-uri:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mywebapplication -targets myweb.war@myserver1
   -stage -deploy c:\localfiles\myEnterpriseApp.ear

To deploy a Web application as a default Web application, set the value of the context-root element to "/". For example, if the application.xml file for a file, myEnterpriseApp.ear, defines:

<module>
  <web>
    <web-uri>myweb.war</web-uri>
    <context-root>/</context-root>
  </web>
</module>

You can deploy only the Web application module by using the context-root name:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mywebapplication -targets /@myserver1
   -stage -deploy c:\localfiles\myEnterpriseApp.ear

 


Deploying JDBC, JMS, and WLDF Application Modules

Stand-alone JDBC, JMS, and WLDF application modules can be deployed similar to stand-alone J2EE modules. For a stand-alone JDBC, JMS, or WLDF application module, the target list determines the WebLogic Server domain in which the module is available. JNDI names specified within an application module are bound as global names and available to clients. For example, if you deploy a stand-alone JDBC application module to a single-server target, then applications that require resources defined in the JDBC module can only be deployed to the same server instance. You can target application modules to multiple servers, or to WebLogic Server clusters to make the resources available on additional servers.

If you require JDBC, JMS, or WLDF resources to be available to all servers in a domain, create system modules, rather than deployable application modules. See Configuring JMS System Resources, Configuring WebLogic JDBC Resources, and Configuring Diagnostic System Modules.

Note: Deploying a JMS module does not necessarily mean it is properly targeted and active, and that the JNDI name is available. The JNDI name is not available until the JMS module is properly targeted. For more information, see Understanding JMS Resource Configuration.

Targeting Application-Scoped JMS, JDBC, and WLDF Modules

JMS, JDBC, and WLDF application modules can also be included as part of an Enterprise Application, as an application-scoped resource module. Application-scoped resource modules can be targeted independently of other EAR modules during deployment, if necessary, by using module-level targeting syntax. For example:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name myEnterpriseApp
   -targets myWebApp@myCluster,myJDBCModule@myserver1,myEJBModule@myserver1
   -stage -deploy c:\localfiles\myEnterpriseApp.ear

Using Sub-Module Targeting with JMS Application Modules

Certain JMS resources defined within a JMS application module can be further targeted to a JMS Server available on the module's target during deployment. These resources are known as submodules. Certain types of submodule require deployment to a JMS Server, such as:

Other submodules can be targeted to JMS Servers as well as WebLogic Server instances and clusters:

During deployment, WebLogic Server selects default JMS Server targets for submodules in a JMS application module, as described in Targeting JMS Modules and Subdeployment Resources . To specify submodule targets at deployment or undeployment time, you must use an extended form of the module targeting syntax with the -submoduletargets option to weblogic.Deployer.

Sub-module Targeting for Stand-alone JMS Modules

For a stand-alone JMS module, the submodule targeting syntax is: -submoduletargets submodule_name@target_name. For example, to deploy a stand-alone JMS module on a single server instance, targeting the submodule myQueue to a JMS Server named JMSServer1, enter the command:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name myJMSModule
   -targets ManagedServer1 -submoduletargets myQueue@JMSServer1
   -deploy c:\localfiles\myJMSModule.xml

To undeploy the same JMS module, enter the following command, which, assuming myJMSModule contains more than one submodule, will undeploy only the myQueue submodule; all other submodules are unaffected.

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name myJMSModule
   -undeploy -submoduletargets myQueue@JMSServer1

Sub-module Targeting for Application-scoped JMS Modules

For an application-scoped JMS module in an EAR, use the syntax: submodule_name@module_name@target_name to target a submodule. For example, if the queue in the above example were instead packaged as part of an enterprise application, you would use the command:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name myEnterpriseApp
   -targets ManagedServer1 -submoduletargets myQueue@myJMSModule@JMSServer1
   -deploy c:\localfiles\myEnterpriseApp.ear

To undeploy the same JMS module, enter the following command, which, assuming myEnterpriseApp contains more than one submodule, will undeploy only the myQueue submodule; all other submodules are unaffected.

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name myEnterpriseApp
   -undeploy -submoduletargets myQueue@myJMSModule@JMSServer1

Warning: When you undeploy an application that contains application-scoped resources, the resources are deleted along with the application, which can potentially cause abandoned transactions or lost messages as a result of deleted JMS destinations. For more information, see Unregister Resource Grace Period.

Warning: You should only undeploy applications that you are certain you want to completely remove; to temporarily stop client access to applications, use the -stop command, described in weblogic.Deployer Command-Line Reference.

For more information on JMS subdeployments, see Targeting JMS Modules and Subdeployment Resources.

 


Controlling Deployment File Copying with Staging Modes

The deployment staging mode determines how deployment files are made available to target servers that must deploy an application or stand-alone 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.

Table 5-2 Application Deployment Staging Modes

Deployment Staging Mode

Behavior

When to Use

stage

The Administration Server first copies the deployment unit source files to the staging directories of target servers. (The staging directory is named stage by default, and it resides under the target server's root directory.)

The target servers then deploy using their local copy of the deployment files.

  • Deploying small or moderate-sized applications to multiple WebLogic Server instances.

  • Deploying small or moderate-sized applications to a cluster.

nostage

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.)

  • Deploying to a single-server domain.

  • Deploying to a cluster on a multi-homed machine.

  • Deploying very large applications to multiple targets or to a cluster where deployment files are available on a shared directory.

  • Deploying exploded archive directories that you want to periodically redeploy after changing content.

  • Deployments that require dynamic update of selected Deployment Descriptors via the Administration Console.

external_stage

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.

You can use the -noversion option to turn off the requirement that deployment files be on the Administration Server, but the -noversion option causes versioning information to be ignored; therefore, you cannot use the -noversion option with versioned applications. For information, see Common Arguments.

  • Deployments where you want to manually control the distribution of deployment files to target servers.

  • Deploying to domains where third-party applications or scripts manage the copying of deployment files to the correct staging directories.

  • Deployments that do not require dynamic update of selected Deployment Descriptors via the Administration Console (not supported in external_stage mode).

  • Deployments that do not require partial redeployment of application components.

A server's staging directory is the directory in which the Administration Server copies deployment files for stage mode deployments. It is also the directory in which deployment files must reside before deploying an application using external_stage mode.

Most deployments use either stage or nostage modes, and the WebLogic Server deployment tools use the appropriate default mode when you deploy an application or module. The sections that follow explain how to explicitly set the deployment staging mode when deploying an application or module.

Using Nostage Mode Deployment

In nostage mode, the Administration Server does not copy the archive files from their source location. Instead, each target server must access the archive files from a single source directory for deployment. The staging directory of target servers is ignored for nostage deployments.

For example, if you deploy a J2EE Application to three servers in a cluster, each server must be able to access the same application archive files (from a shared or network-mounted directory) to deploy the application.

Note: The source for the deployment files in nostage mode is the path provided by the user at deployment time (as opposed to stage mode, where the source is the path in each server's staging directory). However, even in nostage mode, WebLogic Server copies out parts of the deployment to temporary directories. This enables users to update entire archived deployments or parts of archived deployments.

In nostage mode, the Web application container automatically detects changes to JSPs and servlets. Nostage also allows you to later update only parts of an application by updating those parts in one file system location and then redeploying.

The Administration Console uses nostage mode as the default when deploying only to the Administration Server (for example, in a single-server domain). weblogic.Deployer uses the target server's staging mode, and Administration Servers use nostage mode by default. You can also select nostage mode if you run a cluster of server instances on the same machine, or if you are deploying very large applications to multiple machines that have access to a shared directory. Deploying very large applications in nostage mode saves time during deployment because no files are copied.

Syntax for Using Nostage Mode

To use nostage mode, specify -nostage as an option to weblogic.Deployer, as in:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mydeploymentname
   -targets myserver1,myserver2,myserver3 -nostage
   -deploy c:\localfiles\myapp.ear

Using Stage Mode Deployment

In stage mode, the Administration Server copies the deployment files from their original location on the Administration Server machine to the staging directories of each target server. For example, if you deploy a J2EE Application to three servers in a cluster using stage mode, the Administration Server copies the deployment files to directories on each of the three server machines. Each server then deploys the J2EE Application using its local copy of the archive files.

When copying files to the staging directory, the Administration Server creates a subdirectory with the same name as the deployment name. So if you deployed using the command:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mytestear -stage -targets mycluster
   -deploy c:\bea\weblogic81\samples\server\medrecd\dist\physicianEar

a new directory, mytestear, would be created in the staging directory of each server in mycluster. If you do not specify a deployment name, a default deployment name (and staging subdirectory) is used:

The Administration Console uses stage mode as the default mode when deploying to more than one WebLogic Server instance. weblogic.Deployer uses the target server's staging mode as the default, and Managed Servers use stage mode by default.

Stage mode ensures that each server has a local copy of the deployment files on hand, even if a network outage makes the Administration Server unreachable. However, if you are deploying very large applications to multiple servers or to a cluster, the time required to copy files to target servers can be considerable. Consider nostage mode to avoid the overhead of copying large files to multiple servers.

Syntax for Using Stage Mode

To use stage mode, specify -stage as an option to weblogic.Deployer, as in:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mydeploymentname
   -targets myserver1,myserver2,myserver3 -stage
   -deploy c:\localfiles\myapp.ear

Using External_stage Mode Deployment

External_stage mode is similar to stage mode, in that target servers deploy using local copies of the deployment files. However, the Administration Server does not automatically copy the deployment files to targeted servers in external_stage mode; instead, you must copy the files to the staging directory of each target server before deployment. You can perform the copy manually or use automated scripts.

Within each target server's staging directory, deployment files must be stored in a subdirectory that reflects the deployment name. This can either be the name you type in for the deployment, or the default deployment name (the name of the exploded archive directory, or the name of the archive file without its file extension).

External_stage mode is the least common deployment staging mode. It is generally used only in environments that are managed by third-party tools that automate the required copying of files. You may also choose to use external_stage mode when you are deploying very large applications to multiple machines and you do not have a shared file system (and cannot use nostage mode). Using external_stage in this scenario decreases the deployment time because files are not copied during deployment.

You can use the -noversion option to turn off the requirement that deployment files be on the Administration Server, but the -noversion option causes versioning information to be ignored so you cannot use the -noversion option with versioned applications. For information, see Common Arguments.

Syntax for Using external_stage Mode

To deploy an application using external_stage mode:

  1. Make sure that the deployment files are accessible to the Administration Server. (See Uploading Deployment Files from a Remote Client.)
  2. On each target server for the deployment, create a subdirectory in the staging directory that has the same name as the deployment name. For example, if you will specify the name myEARExternal for the deployment name, create a myEARExternal subdirectory in the staging directories for each target server.
  3. Note: If you do not specify a deployment name at deployment time, WebLogic Server selects a default name. See Understanding Default Deployment Names for more information.

  4. If you are deploying a versioned application for use with production redeployment, create a subdirectory beneath the application directory for the version of the application you are deploying. For example, if you are deploying myEARExternal at version level 2.0Beta, the deployment files must reside in a subdirectory of each target server's staging directory named myEARExternal\2.0Beta.
  5. Copy the deployment files into the staging subdirectories you created in Step 2 or 3 above.
  6. Deploy the application or module using the weblogic.Deployer utility. For example:
  7. java weblogic.Deployer -adminurl http://localhost:7001 -name weblogic
       -password weblogic -external_stage -name myEARExternal
       -deploy c:\myapps\myear

Changing the Default Staging Behavior for a Server

The server staging mode specifies the default deployment mode for a server if none is specified at deployment time. For example, the server staging mode is used if you deploy an application or stand-alone module using weblogic.Deployer and you do not specify a staging mode.

Notes: You can only change the server staging mode by using the Administration Console or by directly changing the ServerMBean via JMX.

Changing the server staging mode does not affect existing applications. If you want to change the staging mode for an existing application, you must undeploy the application deployment and then redeploy it with the new staging mode.

To set the server staging mode using the Administration Console, follow the steps described in Set a server staging mode in Administration Console Online Help. For detailed information on staging modes, see Table 5-2.

 


Distributing Applications to a Production Environment

Distributing an application prepares it for deployment by copying its deployment files to all target servers and validating it. After you distribute an application, you can start it in Administration mode, which restricts access to the application to a configured Administration channel and allows you to distribute the application to a production environment (or distribute a new version of an application) without opening the application to external client connections.

While in Administration mode, you can connect to an application only via a configured Administration channel. This allows you to perform final ("sanity") checking of the application directly in the production environment without disrupting clients. After performing final testing, you can either undeploy the application to make further changes, or start the application to make it generally available to clients.

You can use the -adminmode option application in administration mode. For information, see Starting a Distributed Application in Administration mode.

Distributing an Application

To distribute an application, use the weblogic.Deployer -distribute command, as in:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
     -password weblogic -distribute -name myTestDeployment
     /myDeployments/myApplication/

Starting a Distributed Application in Administration mode

After WebLogic Server distributes the deployment files, you can start the application in Administration mode so that you can access and test it via a configured Administration channel. See Configuring Network Resources in Designing and Configuring WebLogic Server Environments.

To start a distributed application in Administration mode, use the -start command with the -adminmode option:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
     -password weblogic -start -adminmode -name myTestDeployment
     /myDeployments/myApplication/

Starting a Distributed Application

After performing final testing of a distributed application using a configured Administration channel, you can open the application to new client connections by using the weblogic.Deployer -start command without the -adminmode option:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
     -password weblogic -start -name myTestDeployment

 


Deploying Shared J2EE Libraries and Dependent Applications

J2EE library support in WebLogic Server 9.0 provides an easy way to share one or more J2EE modules or JAR files among multiple Enterprise Applications. A J2EE library is a stand-alone J2EE module, multiple J2EE modules packaged in an Enterprise Application (EAR), or a plain JAR file that is registered with the J2EE application container upon deployment. After a J2EE library has been registered, you can deploy Enterprise Applications that reference the library. Each referencing application receives a copy of the shared J2EE library module(s) on deployment, and can use those modules as if they were packaged as part of the application itself.

Note: BEA documentation and WebLogic Server utilities use the term library to refer to both J2EE libraries and optional packages. Optional packages are called out only when necessary.

Understanding Deployment Behavior for Shared Libraries

WebLogic Server 9.0 supports shared J2EE libraries by merging the shared files with a referencing application when the referencing application is deployed.

You first register a J2EE library or optional package with one or more WebLogic Server instances or clusters by deploying the library and indicating that the deployment is a library (see Registering Libraries with WebLogic Server). Deploying a library or package does not activate the deployment on target servers. Instead, WebLogic Server distributes the deployment files to target servers (if nostage deployment mode is used) and records the location of the deployment files, the deployment name, and any version string information for the library or package.

When an application that references a shared library or package is deployed, WebLogic Server checks the names and version string requirements against the libraries registered with the server. If an exact match for a library or package name is not found, or if the version requirements are not met, the application deployment fails.

If WebLogic Server finds a name and version string match for all of the libraries referenced in the application, the server adds the libraries' classes to the classpath of the referencing application and merges deployment descriptors from both the application and libraries in memory. The resulting deployed application appears as if the referenced libraries were bundled with the application itself.

The contents of a J2EE library are loaded into classloaders in the same manner as any other J2EE modules in an enterprise application. For example, EJB modules are loaded as part of the referencing application's classloader, while Web application modules are loaded in classloaders beneath the application classloader. If a shared J2EE library consists of an EAR, any classes stored in the EAR's APP-INF/lib or APP-INF/classes subdirectory are also available to the referencing application.

You cannot undeploy any J2EE libraries or optional packages that are referenced by a currently deployed application. If you need to undeploy a shared library or package, you must first undeploy all applications that use the shared files. For regular application maintenance, you should deploy a new version of a shared library or package and redeploy referencing applications to use the newer version of the shared files. See Editing Manifest Entries for Shared Libraries in Developing Applications with WebLogic Server for more information.

Registering Libraries with WebLogic Server

A shared J2EE library is a standard J2EE module or Enterprise Application that is registered with a WebLogic Server container as a library. To register a J2EE library with a WebLogic Server container, perform the following steps:

  1. Ensure that the deployment file(s) you are working with represent a valid J2EE library or optional package. See Creating Shared J2EE Libraries in Developing Applications with WebLogic Server.
  2. Select the WebLogic Server targets to which you will register the library or package. Shared libraries must be registered to the same WebLogic Server instances on which you plan to deploy referencing applications. (You may consider deploying libraries to all servers in a domain, so that you can later deploy referencing applications as needed.)
  3. Register the library or package by deploying the files to your selected target servers, and identifying the deployment as a library or package with the -library option. For example:
  4. java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
         -password weblogic -deploy -targets myserver1,myserver2
         -library /deployments/myLibraryApplication/

Specifying Library Versions at Deployment

As a best practice, your development team should always include version string information for a library or optional package in the manifest file for the deployment. See Editing Manifest Attributes for Shared Libraries in Developing Applications with WebLogic Server for more information about version string requirements and best practices.

If you are deploying a library or package that does not include version string information, you can specify it at the command line using one or both of the following options:

For example:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
     -password weblogic -deploy -targets myserver1,myserver2
     -library -libspecver 700 -libimplversion 7.0.0.1Beta
     /deployments/myLibraryApplication/

Notes: If both the manifest file and the weblogic.Deployer command line specify version information, and the values do not match, the deployment will fail.

If you initially registered a library without providing a specification or implementation version, you must undeploy the library before registering a newer version and specifying version string information.

You can register multiple versions of a library or package, but each version must use the same version strings. For example, you cannot register a library having only a specification version, and then register a new version of the library having both a specification and an implementation version.

Deploying Applications That Reference Libraries

After you deploy the required library and package versions, you can deploy Enterprise Applications and modules that reference the libraries. Successfully deploying a referencing application requires that two conditions are met:

There is no special syntax for deploying a referencing application. Deploy the application as you would a standard Enterprise Application or J2EE module.

Note that referencing applications can be configured with varying levels of version requirements for shared libraries. An application might be configured to require:

If you cannot deploy a referencing application because of version requirements, try registering the required version of the conflicting library or package. Or, consult with your development team to determine whether the version requirements of the application can be relaxed. See Referencing Libraries in an Enterprise Application in Developing Applications with WebLogic Server for more information.

Note: If you have an EAR library that contains Web application components, you cannot deploy multiple applications that reference the library because attempting to do so will result in a context path conflict. This is because context-root cannot be set for individual Web applications in EAR libraries; it can only be set for an entire library.

See Overview of J2EE Libraries and Optional Packages in Developing Applications with WebLogic Server for more information.

 


Auto-Deploying Applications in Development Domains

Notes: Auto-deployment is a method for quickly deploying an application to a stand-alone server (Administration Server) for evaluation or testing. It is recommended that this method be used only in a single-server development environment. Use of auto-deployment in a production environment or for deployment to Managed Servers is not recommended.

BEA recommends that you use the WebLogic Server split development directory and wldeploy ant task, rather than auto-deployment, when developing an application. See Creating a Split Development Directory in Developing Applications with WebLogic Server.

If auto-deployment is enabled, when an application is copied into the \autodeploy directory of the Administration Server, the Administration Server detects the presence of the new application and deploys it automatically (if the Administration Server is running). If WebLogic Server is not running when you copy the application to the \autodeploy directory, the application is deployed the next time the WebLogic Server Administration Server is started. Auto-deployment deploys only to the Administration Server.

Notes: Due to the file locking limitations of Windows, if an application is exploded, all the modules within the application must also be exploded. In other words, you cannot use auto-deployment with an exploded application or module that contains a JAR file.

Auto-deployment is intended for use with a single server target in a development environment. If you use other tools, such as the Administration Console, to add targets to an auto-deployed, exploded application, redeploying the application does not propagate changes to the new target servers.

Enabling and Disabling Auto-Deployment

You can run a WebLogic Server domain in two different modes: development and production.

Development mode enables a WebLogic Server instance to automatically deploy and update applications that are in the domain_name/autodeploy directory (where domain_name is the name of a WebLogic Server domain). In other words, development mode lets you use the auto-deployment feature. Production mode disables the auto-deployment feature and prevents any applications you place in the autodeploy directory after you switch to production mode from being deployed. When you switch from development mode to production mode, any applications that were previously deployed via the autodeploy directory remain deployed; if you wish to undeploy or redeploy such applications after you have switched to production mode, you must undeploy or redeploy them manually (for instance, with the weblogic.Deployer command and the -undeploy or -redeploy options, as described in weblogic.Deployer Command-Line Reference).

By default, a WebLogic Server domain runs in development mode. To specify the mode for a domain, see Creating and Configuring Domains Using the Configuration Wizard.

Auto-Deploying, Redeploying, and Undeploying Archived Applications

To auto-deploy an archived application, copy its archive file to the /autodeploy directory. WebLogic Server automatically sets the application's deployment mode to stage mode.

A deployment unit that was auto-deployed can be dynamically redeployed while the server is running. To dynamically redeploy, copy the new version of the archive file over the existing file in the /autodeploy directory.

To undeploy an archived deployment unit that was auto-deployed, delete the application from the /autodeploy directory. WebLogic Server stops the application and removes it from the configuration.

Note: If you delete an application from the /autodeploy directory when the server is not active, WebLogic Server will not detect that the application was deleted even when the server is again in an active state. In order to prevent an out-of-sync domain tree, BEA recommends that you only remove applications from the /autodeploy directory when the server is in an active state.

Auto-Deploying, Redeploying, and Undeploying Exploded Archives

To auto-deploy an application in exploded archive format, copy the entire exploded archive directory to the /autodeploy directory. WebLogic Server automatically deploys exploded archive applications using the nostage deployment mode.

Notes: Due to Windows file locking limitations, if you deploy an exploded EAR directory that contains archived modules (JAR files), the JAR files are locked during the deployment and you will not be able to remove them. Therefore, if an application you plan to auto-deploy is exploded, all of the modules it contains must also be exploded.

Auto-deployment will fail if you attempt to deploy an application in exploded archive format when the contents of the entire exploded archive directory are not in the /autodeploy directory. Because large applications in exploded archive format can take a long time to copy into the /autodeploy directory, BEA recommends that you copy the exploded archive directory into the /autodeploy directory while the server is in an inactive state. After the entire exploded archive directory has been copied in the /autodeploy directory, you can return the server to an active state and the application will be autodeployed. Alternatively, BEA recommends that you deploy large applications with weblogic.Deployer, described in weblogic.Deployer Command-Line Reference.

When an application has been auto-deployed in exploded archive format, the Administration Server periodically looks for a file named REDEPLOY in the exploded application directory. If the timestamp on this file changes, the Administration Server redeploys the exploded directory.

To redeploy files in an exploded application directory:

  1. When you first deploy the exploded application directory, create an empty file named REDEPLOY, and place it in the WEB-INF or META-INF directory, depending on the application type you are deploying:
  2. An exploded enterprise application has a META-INF top-level directory; this contains the application.xml file.

    An exploded Web application has a WEB-INF top-level directory; this contains the web.xml file.

    An exploded EJB application has a META-INF top-level directory; this contains the ejb-jar.xml file.

    An exploded connector has a META-INF top-level directory; this contains the ra.xml file.

    Note: The REDEPLOY file works only for an entire deployed application or stand-alone module. If you have deployed an exploded Enterprise Application, the REDEPLOY file controls redeployment for the entire application—not for individual modules (for example, a Web application) within the Enterprise Application. If you deploy a Web application by itself as an exploded archive directory, the REDEPLOY file controls redeployment for the entire Web application.

  3. To redeploy the exploded application, copy the updated files over the existing files in that directory.
  4. After copying the new files, modify the REDEPLOY file in the exploded directory to alter its timestamp.

When the Administration Server detects the changed timestamp, it redeploys the contents of the exploded directory.

Note: You must touch the REDEPLOY file (alter its timestamp) any time you wish to trigger redeployment of an auto-deployed application. Even if you modify an application while a server is shut down, you must touch REDEPLOY to ensure that changes are applied when the server next starts up.

To undeploy an application that was auto-deployed in exploded format, use the weblogic.Deployer -undeploy command, or use the Administration Console to remove the deployment configuration. Then remove the application files from the /autodeploy directory.

Note: If you delete application files from the /autodeploy directory when the server is not active, WebLogic Server will not detect that the application files were deleted even when the server is again in an active state. In order to prevent an out-of-sync domain tree, BEA recommends that you only remove application files from the /autodeploy directory when the server is in an active state.

 


Best Practices for Deploying Applications

BEA recommends the following best practices when deploying applications:

 

Skip navigation bar  Back to Top Previous Next