Deploying Applications to WebLogic Server
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
The following sections describe how to perform basic and advanced deployment tasks using the weblogic.Deployer
utility:
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.
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.
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
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.
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:
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.
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.
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
A WebLogic Server instance, such as an Administration Server in a single-server domain, or a Managed Server. |
J2EE Applications |
|
J2EE Applications |
||
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. |
||
*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. |
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
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.
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:
-DClusterConstraintsEnabled=true
enforces strict cluster deployment for servers in a domain.-DClusterConstraintsEnabled=false
ensures that all available cluster members deploy the application or module. Unavailable servers do not prevent successful deployment to the available clustered instances. This corresponds to the default WebLogic Server deployment behavior.
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.
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
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
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.
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
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
.
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
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.
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
The Administration Server first copies the deployment unit source files to the staging directories of target servers. (The staging directory is named The target servers then deploy using their local copy of the deployment files. |
||
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. You can use the |
|
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.
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.
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
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:
physicianEar
in the example above).physicianEar.ear
, the deployment name and staging subdirectory are physicianEar
.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.
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
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.
To deploy an application using external_stage mode:
myEARExternal
for the deployment name, create a myEARExternal
subdirectory in the staging directories for each target server.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.
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
.java weblogic.Deployer -adminurl http://localhost:7001 -name weblogic
-password weblogic -external_stage -name myEARExternal
-deploy c:\myapps\myear
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 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.
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/
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/
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
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.
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.
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:
-library
option. For example:java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -deploy -targets myserver1,myserver2
-library /deployments/myLibraryApplication/
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:
libspecver
—Defines a specification version for the library or package.libimplver
—Specifies an implementation version for the library or package.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.
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.
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.
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.
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.
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:
REDEPLOY
, and place it in the WEB-INF or META-INF
directory, depending on the application type you are deploying: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.
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.
BEA recommends the following best practices when deploying applications:
.ear
, .jar
, .war
, and so forth) when distributing files to different users or environments.weblogic.Deployer
tool, wldeploy
Ant task, and WLST all provide similar functionality for deploying applications:weblogic.Deployer
to integrate deployment commands with existing administrative shell scripts or automated batch processes.wldeploy
in conjunction with the split development directory for developing and deploying new applications. wldeploy
can also be used in place of weblogic.Deployer
in administration environments that use Ant, rather than shell scripts.wldeploy
, rather than the autodeploy
directory, to deploy your own applications during development. The autodeploy
directory is best used for quickly running new applications in a test or temporary environment. For example, if you download a sample application and want to evaluate its functionality, the autodeploy
directory provides a quick way to deploy the application to a development server.
![]() ![]() |
![]() |
![]() |