Deployment Errors

If an error
occurs during deployment, the application or module is not deployed. If a
module within an application contains an error, the entire application is
not deployed. This prevents a partial deployment that could leave the server
in an inconsistent state.

The Deployment Life Cycle

After an application is initially deployed, it can be modified and reloaded,
redeployed, disabled, re-enabled, and finally undeployed (removed from the
server). This section covers the following topics related to the deployment
life cycle:

You can overwrite a previously deployed application by using the --force option of asadmin deploy or
by checking the appropriate box in the Administration Console during deployment.
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.

See Also

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. All you have to do is 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.

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

To enable dynamic reloading in the Administration
Console

Select the Stand-Alone Instances component.

Select the instance named server in the table.

This is the Admin Server.

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.

See Also

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 Application 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 is enabled by default.

To enable and configure or to disable autodeployment

Select the Stand-Alone Instances component.

Select the instance named server in the table.

This is the Admin Server.

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 if you like.

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.

Apache Ant

The deploytool

You can use the deploytool,
provided with Application Server, to assemble J2EE applications and modules, configure
deployment parameters, perform simple static checks, and deploy the final
result. For more information about using the deploytool, see the J2EE
1.4 Tutorial at http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html.

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

The Administration Console

You can
use the Administration Console to deploy modules and applications to both
local and remote Application Server sites.

To use the Administration Console for deployment

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 Deploy button.

You can also undeploy, enable, or disable an application
or module from this page.

See Also

Deployment by Module or Application

You can deploy applications or individual modules that are independent
of applications. The runtime and file system implications of application-based
or individual module-based deployment are described in Runtime Environments.

Individual module-based deployment
is preferable when components need to be accessed by:

Other modules

J2EE Applications

ACC clients (Module-based deployment allows shared access
to a bean from an ACC client, a servlet, or an EJB component.)

Modules can be combined into an EAR file and then deployed as a single
module. This is similar to deploying the modules of the EAR independently.

Deploying a WAR Module

You can precompile JSP files during deployment by checking the
appropriate box in the Administration Console or by using the --precompilejsp option of the asadmin deploy or asadmin
deploydir command. The sun-appserv-deploy and sun-appserv-jspc Ant tasks also allow you to precompile
JSP files.

You can keep the generated source for JSP files by adding
the -keepgenerated flag to the jsp-config element in sun-web.xml. If you include this
property when you deploy the WAR module, the generated source is kept in domain-dir/generated/jsp/j2ee-apps/app-name/module-name if it is in an application or domain-dir/generated/jsp/j2ee-modules/module-name if it is in an individually
deployed web module.

After a web application
is undeployed, its HttpSession information is not immediately
removed if sessions are persistent. HttpSession information
is removed in the subsequent cycle, when timed out sessions are removed. Therefore,
you should disable a web application before undeploying it if sessions are
persistent.

Deploying an EJB JAR Module

You can keep the generated source for stubs and ties by adding the -keepgenerated flag
to the rmic-options attribute of the java-config element in domain.xml. If you include this flag when you deploy the EJB
JAR module, the generated source is kept in domain-dir/generated/ejb/j2ee-apps/app-name/module-name if it is in an application or domain-dir/generated/ejb/j2ee-modules/module-name if it is in an individually
deployed EJB JAR module. For more information about the -keepgenerated flag,
see the Sun Java System Application Server Enterprise Edition 8.2 Administration Reference.

Generation of stubs and ties is performed asynchronously,
so unless you request their generation during deployment (for example, using
the --retrieve option of the asadmin deploy command),
stubs and ties are not guaranteed to be available immediately after deployment.
You can use the asadmin get-client-stubs command to retrieve
the stubs and ties whether or not you requested their generation during deployment.
For details, see
the Sun Java System Application Server Enterprise Edition 8.2 Reference Manual.

Copy the client JAR file to the client machine, and set the APPCPATH
environment variable on the client to point to this JAR.

Next Steps

To execute the client on the Application Server machine to test it, use the appclient script
in the install-dir/bin directory. If
you are using the default server instance, the only
required option is -client. For example:

appclient -client converterClient.jar

The -xml parameter, which specifies
the location of the sun-acc.xml file,
is also required if you are not using the default instance.

Deploying a J2EE CA Resource Adapter

Access to Shared Frameworks

When J2EE applications and modules use shared framework classes (such
as utility classes
and libraries) the classes
can be put in the path for the System Classloader or the Common Classloader
rather than in an application or module. If you assemble a large, shared library
into every module that uses it, the result is a huge file that takes too long
to register with the server. In addition, several versions of the same class
could exist in different classloaders, which is a waste of resources. For
more information, see Circumventing Classloader Isolation.