Sun Java System Application Server Platform Edition 8.2 Administration Guide

Deployment Methods for Developers

See Also:

ProcedureTo use auto deploy

The auto deploy feature enables you to deploy a prepackaged application or module by copying it to the domain-dir/autodeploy directory.

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.

  1. In the tree component, select Application Server.

  2. Click Advanced.

  3. On the Applications Configuration page, configure the following:

    1. Enable or disable auto deploy by selecting or deselecting the Enabled checkbox.

    2. 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.

    3. 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.

    4. 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.

    5. 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.

ProcedureTo deploy an unpackaged application from a directory

This feature is for advanced developers.

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.

  1. In the Admin Console, begin the deployment process. See To deploy a web application.

  2. On the Deployment page, specify the following:

    1. Click the radio button to specify a package file or a directory path that must be accessible from the server.

    2. In the File Or Directory field, enter the name of the exploded directory.

Equivalent asadmin command


Using the deploytool Utility

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.

Using a Deployment Plan

This feature is for advanced developers.

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 

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