The following sections describe how to perform common maintenance tasks on applications and modules that are currently deployed to a WebLogic Server domain:
WebLogic Server provides two different ways to take an application offline for testing or maintenance purposes:
Stopping an Application to Restrict Client Access—Makes an application unavailable for processing client requests, but does not remove the deployment from the WebLogic Server domain. Stopping an application places the deployment in Administration mode, which allows you to perform internal testing using a configured Administration channel.
Undeploying an Application or Module—Makes an application unavailable for processing client requests and removes WebLogic Server-generated deployment files from the domain.
As described in Distributing Applications to a Production Environment, distributing an application and starting it in Administration mode, restricts access to an application to a configured Administration channel. You can also stop a running application to client requests and place it in Administration mode. In a production environment, you may want to stop an application to confirm a reported problem, or to isolate the application from external client processing in order to perform scheduled maintenance.
-stop command to place a running application into Administration mode, as in:
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic -password weblogic -name mymodule -stop -adminmode
By default, WebLogic Server immediately stops the application, without regard to pending HTTP sessions or in-process work. If you want to wait for pending HTTP sessions to complete their work before stopping the application to client requests and placing it in Administration mode, add the
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic -password weblogic -name mymodule -stop -adminmode -graceful
Note:If you do not explicitly specify an application version with the
-stopcommand will only stop the active version of the application. If there are other versions of the application that you also want to stop (or that you want to stop instead or the active version), you must specify them with the
To restart an application that was previously stopped, making it available to external clients, use the
-start command and specify the deployment name. You do not need to redeploy a stopped application to make it generally available:
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic -password weblogic -name mymodule -start
After you deploy a new application or stand-alone module to servers in a domain, the deployment name remains associated with the deployment files you selected. Even after you stop the deployment on all servers, the files remain available for redeployment using either the Administration Console or
If you want to remove a deployment name and its associated deployment files from the domain, you must explicitly undeploy the application or stand-alone module. To undeploy a deployment unit from the domain using
weblogic.Deployer, specify the
-undeploy command, as in:
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic -password weblogic -name mymodule -undeploy
-undeploycommand without the
-submoduletargetsflags completely removes the application or stand-alone module from all WebLogic Server instances and untargets all JMS sub-module resources.
By default, WebLogic Server immediately stops and undeploys the application, interrupting current clients and in-progress work. For a production application, you may want to undeploy "gracefully," allowing current HTTP clients to complete their work before undeploying:
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic -password weblogic -name mymodule -undeploy -graceful
Undeploying a deployment unit does not remove the original source files used for deployment. It only removes the deployment's configuration from the domain, as well as any deployment files that WebLogic Server created during deployment (for example, files copied with stage deployment mode and files uploaded to the Administration Server).
If you need to redeploy a deployment unit after undeploying it, you must again identify the deployment files, targets, staging mode, and deployment name using the instructions in Deploying Applications and Modules with weblogic.Deployer.
A shared J2EE libraries or optional package cannot be undeployed until all applications that reference the library or package are first undeployed. If no applications reference an application or package, use the instructions in Undeploying an Application or Module to undeploy it.
WebLogic Server's module-level targeting support enables you to add and deploy a new Enterprise Application module without having to redeploy other modules that are already deployed. To deploy a new module in an EAR, you simply use module-level targeting syntax described in Module-Targeting Syntax.
For example, if you were to add a module,
newmodule.war, to a deployed Enterprise Application named
application.xml file as necessary), you could then deploy
newmodule.war using the
java weblogic.Deployer -username myname -password mypassword -name myapp.ear -deploy -targets newmodule.war@myserver -source /myapp/myapp.ear
This command deploys the new module without redeploying the other modules in the application. Note that you must specify the correct file extension (
.war in the above example) for archived modules in an EAR file.
By default, WebLogic Server deploys applications and resources in the following order:
JDBC system modules
JMS system modules
J2EE Libraries and optional packages
Applications and stand-alone modules
Note:WebLogic Server security services are always initialized before server resources, applications, and startup classes are deployed. For this reason, you cannot configure custom security providers using startup classes, nor can custom security provider implementations rely on deployed server resources such as JDBC.
You can change the deployment order for a deployed application or stand-alone module by setting the
AppDeploymentMBean DeploymentOrder attribute in the Administration Console (or programmatically using the
DeploymentOrder attribute controls the load order of deployments relative to one another—modules with lower
DeploymentOrder values deploy before those with higher values. By default, each deployment unit is configured with a Deployment Order value of 100. Deployments with the same Deployment Order value are deployed in alphabetical order using the deployment name. In all cases, applications and stand-alone modules are deployed after the WebLogic Server instance has initialized dependent subsystems.
Note:You cannot change the load order of applications and stand-alone modules using the weblogic.Deployer utility.
To view or change the deployment order of deployments using the Administration Console, follow the steps in Change the server deployment order in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.
The modules contained in an Enterprise Application are deployed in the order in which they are declared in the
application.xml deployment descriptor. See Enterprise Application Deployment Descriptor Elements in Oracle Fusion Middleware Developing Applications for Oracle WebLogic Server.
By default WebLogic Server startup classes are run after the server initializes JMS and JDBC services, and after applications and stand-alone modules have been deployed.
If you want to perform startup tasks after JMS and JDBC services are available, but before applications and modules have been activated, you can select the Run Before Application Deployments option in the Administration Console (or set the
LoadBeforeAppActivation attribute to "true").
If you want to perform startup tasks before JMS and JDBC services are available, you can select the Run Before Application Activations option in the Administration Console (or set the
LoadBeforeAppDeployments attribute to "true").
To select Run Before Applications or Run Before Application Activations in the Administration Console, see Configure startup classes in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.
The following figure summarizes the time at which WebLogic Server executes startup classes.
See the full Javadocs for
StartupClassMBean for more information.
After you deploy an application or stand-alone module in a WebLogic Server domain, you can change the target server list to add new WebLogic Server instances or to remove existing server instances. If you remove a target server, only the target list itself is updated—the deployment unit remains deployed to the removed server until you explicitly undeploy it. Similarly, if you add a new target server, you must explicitly deploy the deployment unit on the new server before it is active on that server.
To add a new server to the target list using
weblogic.Deployer, simply specify the new list of target servers with the
-deploy command. For example:
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic -password weblogic -name mydeploymentname -deploy -targets server1, newserver
If you deploy a Web application using an exploded archive directory, you can update static contents of the Web application either by refreshing the files (see Updating Static Files in a Deployed Application), or by deleting files from the deployment. To delete files, you must use the
weblogic.Deployer utility with the
delete_files option. For example:
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic -password weblogic -name mywebapp -delete_files mywebapp/copyright.html
Always specify the pathname to updated files starting with the top level of the exploded archive directory. In the above example, the Web application resides in an exploded archive directory named
-delete_filesoption deletes all specified files or, if you specify a directory but do not specify files within the directory, all files in the specified directory, Oracle recommends that you use caution when using the delete_files option and that you do not use the
delete_filesoption in production environments.
The WebLogic Server deployment system automatically assigns a unique ID to deployment tasks so that you can track and manage their progress.
weblogic.Deployer enables you to assign your own task identification numbers for use with deployment commands, as well as monitor and cancel long-running deployment tasks.
For example, the following command assigns a task ID of
redeployPatch2 to a new deployment operation:
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic -password weblogic -name mymodule -targets myserver -id redeployPatch2 -nowait -deploy c:\localfiles\myapp.ear
You can later check the status of the task:
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic -password weblogic -id redeployPatch2 -list
You can check the status of all running tasks:
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic -password weblogic -listtask
If a task takes too long to complete you can cancel it:
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic -password weblogic -id redeployPatch2 -cancel
There are many internal applications that are deployed during startup. These internal applications consume memory and require CPU time during deployment. This contributes to the WLS startup time and base memory footprint. Since many of these internal applications are not needed by every user, WLS has been modified to wait and deploy these applications on the first access (on-demand) instead of always deploying them during server startup. This reduces startup time and memory footprint.
There are two different types of internal applications. The first type displays a user interface, and includes the Administration Console, UDDI explorer, and WLS test client. The second type does not display a user interface, and includes UDDI and internal servlets for deployment and management file distribution.
For applications with a user interface, WLS displays a status page indicating that on-demand deployment is in progress. This page refreshes every two seconds. When the internal application completes deployment, you are redirected to the internal application. This status page is displayed on the first access of each application. Subsequent invocations do not deploy the application and go directly to the user interface for the internal application.
For a development domain, the default is for WLS to deploy internal applications on demand. For a production-mode domain, the default is for WLS to deploy internal applications as part of server startup. You can control the default behavior by configuring the
InternalAppsDeployOnDemandEnabled attribute in the Domain MBean. You can change the configuration setting using the Administration Console or by using the WebLogic Scripting Tool (WLST).
To change the
InternalAppsDeployOnDemandEnabled attribute using the Administration Console, perform the following steps:
Start an edit session with the Lock and Edit button.
Select the domain to bring up the Configuration > General page.
Change the setting of the Enable on-demand deployment of internal applications check box.
Click Save and then click Activate Changes to activate the changes that will take effect at the next restart of WLS.