For example, copy a file named hello.war to the domain-dir/autodeploy directory. To undeploy the application, remove the hello.war file from the autodeploy directory.
You can also use the Admin Console or asadmin tool to undeploy the application. In that case, the archive file remains.
Auto deploy is only available for the default server instance.
The auto deploy feature is intended for development environments. It is incompatible with session persistence, a production environment feature. Do not enable session persistence if auto deployment is enabled
In the tree component, expand the Stand-Alone Instances node.
Click server (Admin Server).
On the Applications Configuration page, configure the following:
Enable or disable auto deploy by selecting or deselecting the Enabled checkbox.
In the Auto Deploy Poll Interval field, specify how often the server checks the auto deploy directory for application or module files.
Changing the poll interval does not affect the amount of time it takes to deploy an application or module.
In the Auto Deploy Directory, if you specify the directory where you build your application, then you won’t have to copy the file to the default auto deploy directory.
The default is a directory called autodeploy in the server instance’s root directory.
By default a variable is used to eliminate the need to manually change the directory for multiple server instances. For more information on these variables, see To set the advanced domain attributes.
To run the verifier before deployment, select the Verifier.
The verifier examines the structure and content of the file. Verification of large applications is often time-consuming.
To precompile JSP pages, select Precompile.
If you do not select this checkbox, the JSP pages are compiled at runtime when they are first accessed. Because compilation is often time-consuming, in a production environment select this checkbox.
Use directory deployment only to deploy to the default server instance (server). You cannot use it to deploy to clusters or stand-alone server instances.
A directory containing an unpackaged application or module is sometimes called an exploded directory. The contents of the directory must match the contents of a corresponding J2EE archive file. For example, if you deploy a Web application from a directory, the contents of the directory must be the same as a corresponding WAR file. For information about the required directory contents, see the appropriate specifications.
You can change the deployment descriptor files directly in the exploded directory.
If your environment is configured to use dynamic reloading, you can also dynamically reload applications deployed from the directory. For more information, see To configure dynamic reloading.
In the Admin Console, begin the deployment process. See To deploy a web application.
On the Deployment page, specify the following:
Designed for software developers, the deploytool utility packages and deploys J2EE applications and modules. For instructions on how to use deploytool, see The J2EE 1.4 Tutorial.
A deployment plan is an JAR file that contains only the deployment descriptors that are specific to the Application Server. These deployment descriptors, for example sun-application.xml, are described in the Application Server Developer’s Guide. The deployment plan is part of the implementation of JSR 88: J2EE Application Deployment. Use a deployment plan to deploy an application or module that does not contain the deployment descriptors that are specific to the Application Server.
To deploy using a deployment plan, specify the --deploymentplan option of the asadmin deploy command. The following command, for example, deploys the enterprise application in the myrosterapp.ear file according to the plan specified by the mydeployplan.jar file.
$ asadmin deploy --user admin ---deploymentplan mydeployplan.jar myrosterapp.ear
In the deployment plan file for an enterprise application (EAR), the sun-application.xml file is located at the root. The deployment descriptor for each module is stored according to this syntax: module-name.sun-dd-name, where the sun-dd-name depends on the module type. If a module contains a CMP mappings file, the file is named module-name.sun-cmp-mappings.xml. A .dbschema file is stored at the root level with each forward slash character (/) replaced by a pound sign (#). The following listing shows the structure of the deployment plan file for an enterprise application (EAR).
$ jar -tvf mydeployplan.jar 420 Thu Mar 13 15:37:48 PST 2003 sun-application.xml 370 Thu Mar 13 15:37:48 PST 2003 RosterClient.war.sun-web.xml 418 Thu Mar 13 15:37:48 PST 2003 roster-ac.jar.sun-application-client.xml 1281 Thu Mar 13 15:37:48 PST 2003 roster-ejb.jar.sun-ejb-jar.xml 2317 Thu Mar 13 15:37:48 PST 2003 team-ejb.jar.sun-ejb-jar.xml 3432 Thu Mar 13 15:37:48 PST 2003 team-ejb.jar.sun-cmp-mappings.xml 84805 Thu Mar 13 15:37:48 PST 2003 team-ejb.jar.RosterSchema.dbschema
In the deployment plan for a web application or a module file, the deployment descriptor that is specific to the Application Server is at the root level. If a stand-alone EJB module contains a CMP bean, the deployment plan includes the sun-cmp-mappings.xml and .dbschema files at the root level. In the following listing, the deployment plan describes a CMP bean.
$ jar r -tvf myotherplan.jar 3603 Thu Mar 13 15:24:20 PST 2003 sun-ejb-jar.xml 3432 Thu Mar 13 15:24:20 PST 2003 sun-cmp-mappings.xml 84805 Thu Mar 13 15:24:20 PST 2003 RosterSchema.dbschema