Sun logo      Previous      Contents      Next     

Sun Java System Application Server Enterprise Edition 8.1 Administration Guide 2005Q1

Chapter 5
Deploying Applications

This chapter explains how to deploy (install) J2EE applications on the Application Server. This chapter contains following sections:


About Deployment

The Deployment Life Cycle

After installing the Application Server and starting a domain, you can deploy (install) J2EE applications and modules. During deployment and as the application is changed, an application or module can go through the following stages:

  1. Initial Deployment
  2. Before deploying an application or module, start the domain.

    Deploy (install) an application or module to a specific stand-alone server instance or cluster. Because applications and modules are packaged in archive files, specify the archive file name during deployment. The default is to deploy to the default server instance server.

    If you deploy to server instances or clusters, the application or module exists in the domain’s central repository and is referenced by any clusters or server instances you deployed to as targets.

    You can also deploy to the domain using the asadmin deploy command, not the Admin Console. If you deploy the application or module only to the domain, it exists in the domain’s central repository, but no server instances or clusters reference it until you add references, as explained in Step 3.

    Deployment is dynamic: you don’t need to restart the server instance after deploying application or module for applications to be available. If you do restart, all deployed applications and modules are still deployed and available.

  3. Enabling or Disabling
  4. By default, a deployed application or module is enabled, which means that it is runnable and can be accessed by clients if it has been deployed to an accessible server instance or cluster. To prevent access, disable the application or module. A disabled application or module is not uninstalled from the domain and can be easily enabled after deployment.

  5. Adding or Deleting Targets for a Deployed Application or Module
  6. Once deployed, the application or module exists in the central repository and can be referenced by a number of server instances and/or clusters. Initially, the server instances or clusters you deployed to as targets reference the application or module.

    To change which server instances and clusters reference an application or module after it is deployed, change an application or module’s targets using the Admin Console, or change the application references using the asadmin tool. Because the application itself is stored in the central repository, adding or deleting targets adds or deletes the same version of an application on different targets. However, an application deployed to more than one target can be enabled on one and disabled on another, so even if an application is referenced by a target, it is not available to users unless it is enabled on that target.

  7. Redeployment
  8. To replace a deployed application or module, redeploy it. Redeploying automatically undeploys the previously deployed application or module and replaces it with the new one.

    When redeploying through the Admin Console, the redeployed application or module is deployed to the domain, and all stand-alone or clustered server instances that reference it automatically receive the new version if dynamic reconfiguration is enabled. If using the asadmin deploy command to redeploy, specify domain as the target.

    For production environments, use rolling upgrade, which upgrades application without interruption in service. For more information, see "About Rolling Upgrades".

  9. Undeployment
  10. To uninstall an application or module, undeploy it.

Types of J2EE Archive Files

A software provider packages an application or module into a archive file. To deploy the application or module, specify the archive file name. The content and structure of the archive file is defined by the specifications of the J2EE platform. Types of J2EE archive files are as follows:

The software provider might assemble an application into a single EAR file or into separate WAR, EJB JAR, and application client JAR files. In the administration tools, the deployment pages and commands are similar for all types of files.

Naming Conventions

In a given domain, the names of deployed applications and modules must be unique.

Modules of different types can have the same name within an application. When the application is deployed, the directories holding the individual modules are named with _jar, _war and _rar suffixes. Modules of the same type within an application must have unique names. In addition, database schema file names must be unique within an application.

Using a Java package-like naming scheme is recommended for module filenames, EAR filenames, module names as found in the <module-name> portion of the ejb-jar.xml files, and EJB names as found in the <ejb-name> portion of the ejb-jar.xml files. The use of this package-like naming scheme ensures that name collisions do not occur. The benefits of this naming practice apply not only to the Sun Java System Application Server, but to other J2EE application servers as well.

JNDI lookup names for EJBs must also be unique. Establishing a consistent naming convention might help. For example, appending the application name and the module name to the EJB name is one way to guarantee unique names. In this case, mycompany.pkging.pkgingEJB.MyEJB would be the JNDI name for an EJB in the module pkgingEJB.jar, which is packaged in the application pkging.ear.

Make sure package and file names do not contain spaces or characters that are illegal for the operating system.


Admin Console Tasks for Deploying Applications

Deploying an Enterprise Application

An enterprise application is packaged in an EAR file, a type of archive file that contains any type of J2EE stand-alone modules, such as WAR and EJB JAR files.

To deploy (install) an enterprise application:

  1. In the tree component, expand the Applications node.
  2. Select the Enterprise Applications node.
  3. On the Enterprise Applications page, click Deploy.
  4. On the Deployment page, specify the location of the EAR file to deploy.
  5. The server machine is the host that is running the application server domain administration server. The client machine is the host on which you are viewing the Admin Console through a browser.

    1. If the file resides on or is accessible from the client machine, click the radio button to specify a package file to upload to the Application Server.
    2. Click Browse to browse to the file, or type the full path to the file.

    3. If the file resides on the server machine, or to deploy an unpackaged application from an exploded directory, click the radio button to specify a package file or a directory path that must be accessible from the server.
    4. Type the full path name to the file or directory. Deploying from an exploded directory is for advanced developers and is not recommended for production environments.

  6. Click Next to display the Deploy Enterprise Application page.
  7. On the Deploy Enterprise Application page, specify the settings for the application.
    1. In the Application Name field, either retain the default name, which is the prefix of the file name, or type another name. (The default name appears if you chose to upload a file.) The application name must be unique.
    2. By default, an application is available as soon as it is deployed. To disable the application so that is unavailable after deployment, select the Disabled radio button.
    3. If the application has already been deployed, select the Redeploy checkbox to redeploy it; otherwise you see an error. You can also choose a different application name and deploy it under a new name.
    4. To verify the structure and contents of the file before deployment, select the Verifier checkbox. Verification of large applications can be time-consuming. Verify the file if you suspect it is corrupt or non-portable.
    5. To precompile JSP pages, select the JSPs checkbox. 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.
    6. Choose a high availability setting.
    7. To enable high availability for the application, select the Availability checkbox. If availability is enabled for an application, it must also be enabled at all higher levels (named configuration and web container or EJB container) as well.

    8. Choose the targets to which to deploy the application.
    9. From the list of available targets, choose the target or targets and click Add. Targets can be clusters or stand-alone server instances. If you do not select a target, the application is deployed to the default server instance server.

      If you are redeploying, don’t select targets. Anything you select here is ignored. Any target clustered or stand-alone server instance that references the deployed application automatically references the new, redeployed application if dynamic reconfiguration is enabled for the cluster or stand-alone instance. For more information about how to redeploy applications without interruption of service, see "Upgrading an Application".

    10. Choose whether to generate RMI stubs.
    11. If you choose to generate RMI stubs, static RMI-IIOP stubs are generated and put into the client.jar.

  8. Click OK to deploy the application.

Equivalent asadmin command: deploy

Deploying a Web Application

A Web application is packaged in a WAR file, a type of archive file that contains components such as servlets and JSP pages.

To deploy (install) a Web application:

  1. In the tree component, expand the Applications node.
  2. Select the Web Applications node.
  3. On the Web Applications page, click Deploy.
  4. On the Deployment page, specify the location of the WAR file to deploy.
  5. The server machine is the host that is running the application server domain administration server. The client machine is the host on which you are viewing the Admin Console through a browser.

    1. If the file resides on or is accessible from the client machine, click the radio button to specify a package file to upload to the Application Server.
    2. Click Browse to browse to the file, or type the full path to the file.

    3. If the file resides on the server machine, or to deploy an unpackaged application from an exploded directory, click the radio button to specify a package file or a directory path that must be accessible from the server.
    4. Type the full path name to the file or directory. Deploying from an exploded directory is for advanced developers and is not recommended for production environments.

  6. Click Next to display the Deploy Web Application page.
  7. On the Deploy Web Application page, specify the settings for the application.
    1. In the Application Name field, either retain the default name, which is the prefix of the file name, or type another name. (The default name appears if you chose to upload a file.) The application name must be unique.
    2. In the Context Root field, enter a string that identifies the Web application. In the URL of the Web application, the context root immediately follows the port number (http://host:port/context-root/...). Make sure that the context root starts with a forward slash, for example: /hello
    3. By default, an application is available as soon as it is deployed. To disable the application so that is unavailable after deployment, select the Disabled radio button.
    4. If the application has already been deployed, select the Redeploy checkbox to redeploy it; otherwise you see an error. You can also choose a different application name and deploy it under a new name.
    5. To verify the structure and contents of the file before deployment, select the Verifier checkbox. Verification of large applications is often time-consuming. Verify the file if you suspect it is corrupt or non-portable.
    6. To precompile JSP pages, select the JSPs checkbox. 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.
    7. Choose a high availability setting.
    8. To enable high availability for the application, select the Availability checkbox. If availability is enabled for an application, it must also be enabled at all higher levels (named configuration and web container or EJB container) as well.

    9. Choose the targets to which to deploy the application.
    10. From the list of available targets, choose the target or targets and click Add. Targets can be clusters or stand-alone server instances. If you do not select a target, the application is deployed to the default server instance server.

      If you are redeploying, don’t select targets. Anything you select here is ignored. Any target clustered or stand-alone server instance that references the deployed application automatically references the new, redeployed application if dynamic reconfiguration is enabled for the cluster or stand-alone instance. For more information about how to redeploy applications without interruption of service, see "About Rolling Upgrades".

    11. Choose whether to generate RMI stubs.
    12. If you choose to generate RMI stubs, static RMI-IIOP stubs are generated and put into the client.jar.

  8. Click OK to deploy the application.

Equivalent asadmin command: deploy

Launching a Deployed Web Application

After deploying an application, you can launch it from the Admin Console.

  1. In the tree component, expand the Applications node.
  2. Click Web Applications.
  3. Click the Launch link for the web application.
  4. Click a link on the Web Application Links page to launch the application.
  5. The server and HTTP listener must be running for the application to launch.

Deploying an EJB Module

An EJB Module, also called an EJB JAR file, contains enterprise beans.

To deploy (install) an EJB module:

  1. In the tree component, expand the Applications node.
  2. Select the EJB Modules node.
  3. On the EJB Module page, click Deploy.
  4. On the Deployment page, specify the location of the JAR file to deploy.
  5. The server machine is the host that is running the application server domain administration server. The client machine is the host on which you are viewing the Admin Console through a browser.

    1. If the file resides on or is accessible from the client machine, click the radio button to specify a package file to upload to the Application Server.
    2. Click Browse to browse to the file, or type the full path to the file.

    3. If the file resides on the server machine, or to deploy an unpackaged application from an exploded directory, click the radio button to specify a package file or a directory path that must be accessible from the server.
    4. Type the full path name to the file or directory. Deploying from an exploded directory is for advanced developers and is not recommended for production environments.

  6. Click Next to display the Deploy EJB Module page.
  7. On the Deploy EJB Module page, specify the settings for the module.
    1. In the Application Name field, either retain the default name, which is the prefix of the file name, or type another name. (The default name appears if you chose to upload a file.) The application name must be unique.
    2. By default, an module is available as soon as it is deployed. To disable the module so that is unavailable after deployment, select the Disabled radio button.
    3. If the module has already been deployed, select the Redeploy checkbox to redeploy it; otherwise you see an error. You can also choose a different application name and deploy it under a new name.
    4. To verify the structure and contents of the file before deployment, select the Verifier checkbox. Verification of large applications can be time-consuming. Verify the file if you suspect it is corrupt or non-portable.
    5. Choose a high availability setting.
    6. To enable high availability for the module, select the Availability checkbox. If availability is enabled for an module, it must also be enabled at all higher levels (named configuration and web container or EJB container) as well.

    7. Choose the targets to which to deploy the module.
    8. From the list of available targets, choose the target or targets and click Add. Targets can be clusters or stand-alone server instances. If you do not select a target, the module is deployed to the default server instance server.

      If you are redeploying, don’t select targets. Anything you select here is ignored. Any target clustered or stand-alone server instance that references the deployed module automatically references the new, redeployed module if dynamic reconfiguration is enabled for the cluster or stand-alone instance. For more information about how to redeploy modules without interruption of service, see "About Rolling Upgrades".

    9. Choose whether to generate RMI stubs.
    10. If you choose to generate RMI stubs, static RMI-IIOP stubs are generated and put into the client.jar.

  8. Click OK to deploy the module.

Equivalent asadmin command: deploy

Deploying a Connector Module

A connector, also known as a resource adapter, is packaged in a type of archive file called a RAR file.

To deploy (install) a connector module:

  1. In the tree component, expand the Applications node.
  2. Select the Connector Modules node.
  3. On the Connector Modules page, click Deploy.
  4. On the Deployment page, specify the location of the RAR file to deploy.
  5. The server machine is the host that is running the application server domain administration server. The client machine is the host on which you are viewing the Admin Console through a browser.

    1. If the file resides on or is accessible from the client machine, click the radio button to specify a package file to upload to the Application Server.
    2. Click Browse to browse to the file, or type the full path to the file.

    3. If the file resides on the server machine, or to deploy an unpackaged module from an exploded directory, click the radio button to specify a package file or a directory path that must be accessible from the server.
    4. Type the full path name to the file or directory. Deploying from an exploded directory is for advanced developers and is not recommended for production environments.

  6. Click Next to display the Deploy Connector Module page.
  7. On the Deploy Connector Module page, specify the settings for the module.
    1. In the Application Name field, either retain the default name, which is the prefix of the file name, or type another name. (The default name appears if you chose to upload a file.) The application name must be unique.
    2. In the Thread Pool Id field, specify the thread pool for the resource adapter you are deploying.
    3. By default, the Sun Java System Application Server services work requests from all resource adapters from its default thread pool. Use this field to associate a specific user-created thread pool to service work requests from a resource adapter.

    4. By default, a module is available as soon as it is deployed. To disable the module so that is unavailable after deployment, select the Disabled radio button.
    5. When you enable or disable a connector module, you also enable or disable the connector resources and connection pools that point to the module.

    6. If the module has already been deployed, select the Redeploy checkbox to redeploy it; otherwise you see an error. You can also choose a different application name and deploy it under a new name.
    7. To verify the structure and contents of the file before deployment, select the Verifier checkbox. Verification of large applications is often time-consuming. Verify the file if you suspect it is corrupt or non-portable.
    8. If the resource adapter has additional properties specified, they are displayed.
    9. Use the table to modify the default values of these properties.

    10. Choose the targets to which to deploy the module.
    11. From the list of available targets, choose the target or targets and click Add. Targets can be clusters or stand-alone server instances. If you do not select a target, the module is deployed to the default server instance server.

      If you are redeploying, don’t select targets. Anything you select here is ignored. Any target clustered or stand-alone server instance that references the deployed module automatically references the new, redeployed module if dynamic reconfiguration is enabled for the cluster or stand-alone instance. For more information about how to redeploy modules without interruption of service, see "About Rolling Upgrades".

  8. Click OK to deploy the module.

Equivalent asadmin command: deploy

Creating a Lifecycle Module

A lifecycle module performs tasks when it is triggered by one or more events in the server lifecycle. These server events are:

Lifecycle modules are not part of the J2EE specification, but are an enhancement to the Sun Java System Application Server.

To create a lifecycle module:

  1. In the tree component, expand the Applications node.
  2. Select the Lifecycle Modules node.
  3. On the Lifecycle Modules page, click New.
  4. On the Create Lifecycle Module page, specify the settings:
    1. In the Name field, type a name that denotes the function of the module.
    2. In the Class Name field, type the fully qualified name of the lifecycle module’s class file.
    3. If the JAR file containing the lifecycle is in the server’s classpath, then leave the Classpath field blank. Otherwise, type the fully qualified path.
    4. If you don’t specify the classpath, you must unpack the classes in application_server_home/domains/domain/applications/lifecycle-module/module_name. If you specify a classpath, nothing else is required.

    5. In the Load Order field, type an integer greater than 100 and less than the operating system’s MAXINT value.
    6. The integer determines the order in which lifecycle modules are loaded when the server starts up. Modules with smaller integers are loaded sooner.

    7. When you start the server, it loads lifecycle modules that are already deployed. By default, if a load fails, the server continues the start-up operation. To prevent the server from starting up when a load fails, select the On Load Failure checkbox.
    8. By default, a module is available as soon as it is deployed. To disable the module so that is unavailable after deployment, select the Disabled radio button.
    9. Choose the targets to which to deploy the module.
    10. From the list of available targets, choose the target or targets and click Add. Targets can be clusters or stand-alone server instances. If you do not select a target, the module is deployed to the default server instance server.

      If you are redeploying, don’t select targets. Anything you select here is ignored. Any target clustered or stand-alone server instance that references the deployed module automatically references the new, redeployed module if dynamic reconfiguration is enabled for the cluster or stand-alone instance. For more information about how to redeploy modules without interruption of service, see "About Rolling Upgrades".

  5. Click OK.

Equivalent asadmin command: create-lifecycle-module

Deploying an Application Client Module

An application client module, also called a J2EE application client JAR file, contains the server-side routines for the client.

To deploy (install) an application client module:

  1. In the tree component, expand the Applications node.
  2. Select the App Client Modules node.
  3. On the Application Client Modules page, click Deploy.
  4. On the Deployment page, specify the location of the JAR file to deploy.
  5. The server machine is the host that is running the application server domain administration server. The client machine is the host on which you are viewing the Admin Console through a browser.

    1. If the file resides on or is accessible from the client machine, click the radio button to specify a package file to upload to the Application Server.
    2. Click Browse to browse to the file, or type the full path to the file.

    3. If the file resides on the server machine, or to deploy an unpackaged module from an exploded directory, click the radio button to specify a package file or a directory path that must be accessible from the server.
    4. Type the full path name to the file or directory. Deploying from an exploded directory is for advanced developers and is not recommended for production environments.

  6. Click Next to display the Deploy Application Client Module page.
  7. On the Deploy Application Client Module page, specify the settings for the module.
    1. In the Application Name field, either retain the default name, which is the prefix of the file name, or type another name. (The default name appears if you chose to upload a file.) The application name must be unique.
    2. If the module has already been deployed, select the Redeploy checkbox to redeploy it; otherwise you see an error. You can also choose a different application name and deploy it under a new name.
    3. To verify the structure and contents of the file before deployment, select the Verifier checkbox. Verification of large applications can be time-consuming.Verify the file if you suspect it is corrupt or non-portable.
    4. Choose the targets to which to deploy the module.
    5. From the list of available targets, choose the target or targets and click Add. Targets can be clusters or stand-alone server instances. If you do not select a target, the module is deployed to the default server instance server.

      If you are redeploying, don’t select targets. Anything you select here is ignored. Any target clustered or stand-alone server instance that references the deployed module automatically references the new, redeployed module if dynamic reconfiguration is enabled for the cluster or stand-alone instance. For more information about how to redeploy modules without interruption of service, see "About Rolling Upgrades".

    6. Choose whether to generate RMI stubs.
    7. If you choose to generate RMI stubs, static RMI-IIOP stubs are generated and put into the client.jar.

  8. Click OK to deploy the module.

For the client-side routines:

Equivalent asadmin command: deploy


Admin Console Tasks for Listing, Undeploying, and Enabling Applications

Listing Deployed Applications

To list deployed applications:

  1. In the tree component, expand the Applications node.
  2. Expand the node for the application or module type.

To view the details of a deployed application or module either:

Equivalent asadmin command: list-components

Listing Subcomponents

Enterprise and Web applications, EJB Modules and Connector Modules contain subcomponents. For example, a Web application might contain one or more servlets.

To list the subcomponents of an application or module:

  1. In the tree component, expand the Applications node.
  2. Expand the node for the type of application or module for which to view descriptors.
  3. Select the node for the deployed application or module.
  4. On the Application or Module page, note the contents of the Sub Components table.

Equivalent asadmin command: list-sub-components

Viewing Module Descriptors of Deployed Applications

For Enterprise Applications, Web Applications, EBJ Modules, Connector Modules, and App Client Modules, you can view the module deployment descriptors.

  1. In the tree component, expand the Applications node.
  2. Select the node for the type of application or module for which to view descriptors.
  3. Select the node for the deployed application or module.
  4. Select the Descriptor tab.
  5. To see the text of the descriptor file, click the file name.
  6. The page displays the file contents. This information is read-only.

Undeploying an Application

Undeploying an application or module uninstalls it from the domain and removes references to it from all instances.

To undeploy an application or module:

  1. In the tree component, expand the Applications node.
  2. Select the node for the type of application or module want to undeploy.
  3. In the table listing the deployed applications, select the checkbox for the application or module you want to undeploy.
  4. Click Undeploy.

Equivalent asadmin command: undeploy

Enabling and Disabling an Application

If a deployed application or module is enabled, it is accessible by clients. If it is disabled, it is still deployed but is not accessible by clients. By default, when you deploy an application or module, it is enabled because the Enable on All Targets radio button is selected by default.

To enable a deployed application or module:

  1. In the tree component, expand the Applications node.
  2. Expand the node for the application type.
  3. Select the checkbox next to a deployed application or module.
  4. Click Enable or Disable.
  5. These buttons enable or disable the application on all targets.

To enable an application on a single target

  1. In the tree component, expand the Applications node.
  2. Expand the node for the application type.
  3. Select the node for the application.
  4. Click the Targets tab.
  5. Select the checkbox next to the deployed application or module.
  6. Click Enable or Disable.

Equivalent asadmin commands: enable and disable

Managing Application Targets

After deploying an application or module, manage the server instances and clusters that reference it by managing targets.

  1. In the tree component, expand the Applications node.
  2. Expand the node for the application type.
  3. Select the node for the deployed application.
  4. Select the Targets tab.
  5. To enable or disable an application on a specific target instance or cluster, click the checkbox next to the target and click Enable or Disable.
  6. To add or delete targets for the application, choose Manage Targets.
  7. Add or remove targets and click OK.
  8. The application is now available on the revised list of targets.

Equivalent asadmin commands: create-application-ref, delete-application-ref.

Deploying on Additional Virtual Servers

After deploying an application or module to a target server instances or clusters, you can associate it with additional virtual servers.

  1. From the deployed application or module’s Target page, click the Manage Virtual Servers link next to the target.
  2. Add or remove virtual server targets from the list of available virtual servers.
  3. Click OK.

Redeploying to Multiple Targets

If an application is deployed to multiple targets (stand-alone server instances or clusters), you have two ways of redeploying to multiple targets. Use one of the following methods to make sure all server instances that reference an application receive the most recent version.

Development Environment

In a development environment, simply redeploy the application. The application is redeployed to the domain, and all targets that reference it automatically receive the new version if dynamic reconfiguration is enabled for the target server instances. Dynamic reconfiguration is enabled by default. If dynamic reconfiguration is not enabled for a server instance, it continues to use the old version until the server instance is restarted.

Production Environment

In a production environment, follow the steps detailed in "About Rolling Upgrades".

Enabling and Disabling Dynamic Reloading

If dynamic reloading is enabled, the server periodically checks for changes in a deployed application and automatically reloads the application with the changes. Changes are signaled by a date change to a file called .reload that you create manually. The applications must be installed in server_root/domain/domain1/applications/j2ee-module_or_j2ee-apps/ app_or_module_name

For example: AppServer/domain/domain1/applications/j2ee-module/webapps-simple

Dynamic reloading is useful in a development environment because it allows code changes to be tested quickly. In a production environment, however, dynamic reloading may degrade performance.


Note

Dynamic reloading is only available for the default server instance.


Dynamic reloading is intended for development environments. It is incompatible with session persistence, a production environment feature. Do not enable session persistence if dynamic deployment is enabled.

To configure dynamic reloading:

  1. In the tree component, expand the Stand-Alone Instances node.
  2. Click server (Admin Server).
  3. Click Advanced.
  4. On the Applications Configuration page, configure the following:
    • Reload: Enable or disable dynamic reloading with the Enabled checkbox.
    • Reload Poll Interval: Specify how often the server checks for changes in the deployed applications.
    • Admin Session Timeout: Specify the amount of time before the Admin Session times out and you have to log in again.

After configuring the system to use dynamic reloading, for every application to be reloaded dynamically, create a file called .reload and put it in the application’s directory. The file does not have any content. When you change the application, change the date of the file (for example, using the UNIX touch command), and the changes are reloaded automatically.


Deployment Methods for Developers

Using Auto Deploy

The auto deploy feature enables you to deploy a pre-packaged application or module by copying it to the domain_root_dir/domain_dir/autodeploy directory.

For example, copy a file named hello.war to the domain_root_dir/domain1/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.

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 dynamic deployment is enabled


Note

Auto deploy is only available for the default server instance.


To configure the auto deploy feature:

  1. In the tree component, expand the Stand-Alone Instances node.
  2. Click server (Admin Server).
  3. Click Advanced.
  4. 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.
    4. 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 Setting Domain Attributes.

    5. To run the verifier before deployment, select the Verifier Enabled checkbox. The verifier examines the structure and content of the file. Verification of large applications is often time-consuming.
    6. To precompile JSP pages, select the JSPs checkbox. 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.

Deploying an Unpackaged Application From a Directory

This feature is for advanced developers.

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 "Enabling and Disabling Dynamic Reloading".

To deploy an unpackaged application from a directory:

  1. In the Admin Console, begin the deployment process. See "Deploying 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: deploydir

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



Previous      Contents      Next     


Copyright 2004 - 2005 Sun Microsystems, Inc. All rights reserved.