7 Auto-Deploying Applications in Development Domains

Auto-deployment is a method for quickly deploying an application to a standalone server (Administration Server) for evaluation or testing. It is recommended that this method be used only in a single-server development environment.

Note:

Oracle 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 for Oracle 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.

Note:

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.

The following sections provide information on how to use auto-deployment in a development domain:

Enabling and Disabling Auto-Deployment

You can run a WebLogic Server domain in two different modes: development and production. Only development mode allows you use the auto-deployment feature

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). 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 Appendix A, "weblogic.Deployer Command-Line Reference").

By default, a WebLogic Server domain runs in development mode. To specify the mode for a domain, see Creating 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, Oracle 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.

Note:

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, Oracle 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 auto-deployed. Alternatively, Oracle recommends that you deploy large applications with weblogic.Deployer, described in Appendix A, "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:

    An exploded Enterprise application has a META-INF top-level directory which contains the application.xml file.

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

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

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

    Note:

    The REDEPLOY file works only for an entire deployed application or standalone 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.
  2. To redeploy the exploded application, copy the updated files over the existing files in that directory.

  3. 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, Oracle recommends that you only remove application files from the /autodeploy directory when the server is in an active state.

Limitations of Auto-Deployment

Auto-deployed applications are very convenient in a development environment, but there are some limitations:

  • There is no configuration in config.xml for an auto-deployed application. Therefore, in the Administration Console, there are no notes or target pages associated with an auto-deployed application because there is no backing configuration for that information.

  • You cannot associate an auto-deployed application with a deployment plan since auto-deployed applications do not support any configuration operations which would be reflected in a deployment plan.

  • You cannot set up security policies or roles for auto-deployed applications.

  • You cannot undeploy or redeploy auto-deployed applications using WebLogic Server tools.