Deployment for Development (Sun GlassFish Enterprise Server 2.1 Application Deployment Guide)

Sun GlassFish Enterprise Server 2.1 Application Deployment Guide

Deployment for Development

This section covers the following topics related to deployment for development:

Note –

You can overwrite a previously deployed application by using the --force option of asadmin deploy or asadmin deploydir or by selecting the Redeploy button in the Admin Console. However, you must remove a preconfigured resource before you can update it.

Dynamic Deployment

You can deploy, redeploy, and undeploy an application or module without restarting the server instances. This is called dynamic deployment. Although primarily for developers, dynamic deployment can be used in operational environments to bring new applications and modules online without requiring a server restart.

Whenever a redeployment is done, the sessions at that transit time become invalid. The client must restart the session.

Disabling a Deployed Application or Module

You can disable a deployed application or module without removing it from the server. Disabling an application makes it inaccessible to clients.

To disable an application or module using the asadmin disable command, see the Sun GlassFish Enterprise Server 2.1 Reference Manual.

To Disable an Application or Module in the Admin Console

Open the Applications component.

Go to the page for the type of application or module.

For example, for a web application, go to the Web Applications page.

Click on the box to the left of the name of each application or module you wish to disable.

Click on the Disable button.

Dynamic Reloading

If dynamic reloading is enabled (it is by default), you do not have to redeploy an application or module when you change its code or deployment descriptors. Simply copy the changed JSP or class files into the deployment directory for the application or module. The server checks for changes periodically and redeploys the application, automatically and dynamically, with the changes. This feature is available only on the default server instance. Deployment directories are as follows:

For an application:

domain-dir/applications/j2ee-apps/app-name

For an individually deployed module:

domain-dir/applications/j2ee-modules/module-name

Dynamic reloading is useful in a development environment, because it allows code changes to be tested quickly. In a production environment, however, dynamic reloading might degrade performance. In addition, whenever a reload is done, the sessions at that transit time become invalid. The client must restart the session.

You can also use the sun-appserv-update task with the asant utility to update an application or module. See Chapter 3, The asant Utility, in Sun GlassFish Enterprise Server 2.1 Developer’s Guide.

To Enable Dynamic Reloading in the Admin Console

To access reloading features:
- In the developer profile:
  1. Select the Application Server component.
  2. Select the Advanced tab.
  3. Select the Applications Configuration tab.
- In the cluster profile:
  1. Select the Stand-Alone Instances component.
  2. Select the instance named server in the table.
    
    This is the Admin Server.
  3. Select the Advanced tab.

Check the Reload Enabled box to enable dynamic reloading.

Enter a number of seconds in the Reload Poll Interval field.

This sets the interval at which applications and modules are checked for code changes and dynamically reloaded. The default is 2.

To Reload Code or Deployment Descriptor Changes

Create an empty file named .reload at the root of the deployed application or module.

For an application:
```
domain-dir/applications/j2ee-apps/app-name/.reload
```
For an individually deployed module:
```
domain-dir/applications/j2ee-modules/module-name/.reload
```

Explicitly update the .reload file’s timestamp (touch .reload in UNIX) each time you make changes.

Automatic Deployment

Automatic deployment, also called autodeployment, involves copying an application or module file (JAR, WAR, RAR, or EAR) into a special directory, where it is automatically deployed by the Enterprise Server. To undeploy an automatically deployed application or module, simply remove its file from the special autodeployment directory. This is useful in a development environment, because it allows new code to be tested quickly. This feature is available only on the default server instance.

Autodeployment of a web services JSR 181 annotated file is supported. For more information, see JSR 181 and Chapter 6, Developing Web Services, in Sun GlassFish Enterprise Server 2.1 Developer’s Guide.

Autodeployment is enabled by default.

To Enable and Configure or to Disable Autodeployment

To access autodeployment features:
- In the developer profile:
  1. Select the Application Server component.
  2. Select the Advanced tab.
  3. Select the Applications Configuration tab.
- In the cluster profile:
  1. Select the Stand-Alone Instances component.
  2. Select the instance named server in the table.
    
    This is the Admin Server.
  3. Select the Advanced tab.

Check the Auto Deploy Enabled box to enable autodeployment, or uncheck this box to disable autodeployment.

Enter a number of seconds in the Auto Deploy Poll Interval field.

This sets the interval at which applications and modules are checked for code changes and dynamically reloaded. The default is 2.

You can change the Auto Deploy Directory.

You can enter an absolute or relative path. A relative path is relative to domain-dir. The default is domain-dir/autodeploy.

You can check the Verifier Enabled box to verify your deployment descriptor files. This is optional.

For details about the verifier, see The verifier Utility.

Check the Precompile Enabled box to precompile any JSP files.

Directory Deployment

A directory containing an unpackaged application or module is sometimes called an exploded directory. To deploy a directory instead of an EAR, WAR, JAR, or RAR file, you can do one of the following:

Use the Admin Console as described in The Admin Console Deployment Pages and enter a path to an exploded directory instead of a path to an archive file.
Use the asadmin deploydir command. See the Sun GlassFish Enterprise Server 2.1 Reference Manual. The asadmin deploydir command is available only on the default server instance.

The contents of the directory must match the contents of a corresponding Java EE 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. In addition, the directories holding the individual modules must be named with _jar, _war and _rar suffixes. 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 Dynamic Reloading.

Note –

On Windows, if you are deploying a directory on a mapped drive, you must be running the Enterprise Server as the same user to which the mapped drive is assigned, or the Enterprise Server won’t see the directory.

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 Enterprise Server. The deployment plan is part of the implementation of JSR 88. Use a deployment plan to deploy an application or module that does not contain the deployment descriptors that are specific to the Enterprise Server. For more information about JSR 88, see the JSR 88 page at http://jcp.org/en/jsr/detail?id=88.

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 myrostapp.ear file according to the plan specified by the mydeployplan.jar file.

$ asadmin deploy --user admin --deploymentplan mydeployplan.jar myrostapp.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 module file, the deployment descriptor that is specific to the Enterprise 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