Deployment for Development

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

• Dynamic Deployment

• Disabling a Deployed Application or Module

• Dynamic Reloading

• Automatic Deployment

• Directory Deployment

You can overwrite a previously deployed module by using the asadmin redeploy command, the --force option of asadmin deploy, or the Redeploy button in the Administration Console. However, you must remove a preconfigured resource before you can update it.

Dynamic Deployment

You can deploy, redeploy, and undeploy a module without restarting the server. 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 unless you use the keepSessions=true property of the asadmin redeploy command. For example:

asadmin redeploy --properties keepSessions=true --name hello.war

For details, see the Sun GlassFish Enterprise Server v3 Prelude Reference Manual.

Keep Sessions is also a checkbox option when you redeploy using the Administration Console. For details, click the Help button in the Administration Console.

Disabling a Deployed Application or Module

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

To disable a module using the asadmin disable command, see the Sun GlassFish Enterprise Server v3 Prelude Reference Manual.

To Disable a Module in the Administration Console

1. Open the Applications component.

2. Go to the page for the type of module.

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

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

4. Click on the Disable button.

See Also

For details, click the Help button in the Administration Console.

Dynamic Reloading

If dynamic reloading is enabled (it is by default), you do not have to redeploy a module when you change its code or deployment descriptors. Simply copy the changed class files or descriptors into the deployment directory for the module. Then update the timestamp of a file named .reload as described in To Reload Code or Deployment Descriptor Changes. The server checks for changes periodically and redeploys the module, automatically and dynamically, with the changes. Deployment directories are as follows:

domain-dir/applications/module-name

Deployment directories may change between Enterprise Server releases.

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. JSP file changes don't need to be dynamically reloaded. Modified JSP files are automatically recompiled and reloaded when they are accessed.

To Enable Dynamic Reloading in the Administration Console

1. Select the Application Server component.

2. Select the Advanced tab.

3. Select the Applications Configuration tab.

4. Check the Reload Enabled box to enable dynamic reloading.

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

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

See Also

For details, click the Help button in the Administration Console.

To Reload Code or Deployment Descriptor Changes

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

   domain-dir/applications/module-name/.reload

   ---

   Note –

   Deployment directories may change between Enterprise Server releases.

   ---

2. 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 a module file (JAR, WAR) into a special directory, where it is automatically deployed by the Enterprise Server. To undeploy an automatically deployed 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. Autodeployment is enabled by default.

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

Autodeployment is enabled by default.

To Enable and Configure or to Disable Autodeployment

1. Select the Application Server component.

2. Select the Advanced tab.

3. Select the Applications Configuration tab.

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

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

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

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

7. Check the Precompile Enabled box to precompile any JSP files.

See Also

For details, click the Help button in the Administration Console.

Directory Deployment

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

• Use the Administration Console as described in The Administration Console Deployment Pages and enter a path to an exploded directory instead of a path to an archive file.

• Use the asadmin deploy command and specify a path to an exploded directory instead of a path to an archive file. See the Sun GlassFish Enterprise Server v3 Prelude Reference Manual.

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 modules must be named with _jar and _war suffixes. For information about the required directory contents, see the appropriate specifications.

The directory must be accessible to the machine on which the Enterprise Server runs.

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 modules deployed from the directory. For more information, see Dynamic Reloading.

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.