![]() ![]() ![]() ![]() ![]() ![]() |
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.
Note: | 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. |
Note: | 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:
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 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. |
Note: | 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 auto-deployed. 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 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 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. |
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. |
![]() ![]() ![]() |