Deploy custom J2EE assets

+

Search Tips   |   Advanced Search

WAS provides two tools to update your J2EE application with your customized applications:

• WebSphere console update wizard

  The WebSphere console is a Web-based graphical user interface used to manage your WAS configuration. Use this tool initially to learn about the deployment process. This tool cannot be used for automated deployments.

• wsadmin

  The wsadmin tool is a command line scripting tool that can be used to automate WebSphere Application Server configuration tasks. The tool provides several language options. You write scripts in your preferred language (JACL or Jython are supported), using the WAS administrative objects to manage the configuration.

Backup/export J2EE assets before deploying.

WebSphere Application Server maintains several copies of the application: application binaries and a master copy of the application.

Application binaries are contained in a directory, typically... WC_PROFILE/installedApps/cell/instance.ear

...which contains the expanded copy of the application.

Cell denotes the name of the cell at the time the application was installed, not the cell name post installation. At run time, this directory is used to load WebSphere Commerce application classes and JSP files.

The master copy of the application is a collapsed version of the WebSphere Commerce application. It is used by the WAS application management utilities. When you export the application, it is this file that is returned; changes in the application binaries directory are not exported with the application. This collapsed copy is also used when the application server distributes the application to the nodes that are part of a cluster; therefore, changes to the application binaries directory will not be reflected on all of the nodes of your cluster.

In general, when you update the enterprise application, this is the WAS process:

1. Update

   1. The collapsed copy of the application is checked out of the application server's configuration repository.

   2. The changed assets are merged into the collapsed copy of the application.

   3. A descriptor is created that describes the changes to the application.

2. Save

   1. The new collapsed copy of the application and descriptor is checked into the configuration repository.

3. Synchronize

   1. The new application is synchronized with the nodes that are running the application. (This is only when using a deployment manager configuration.)

4. Expand

   1. The changed assets are extracted from the master copy of the application and copied to the application binaries directory.

   2. File permission is set on the changed assets in the binaries directory.

   3. The application is restarted automatically.

The following diagrams help illustrate the WebSphere Application Server environments.

Use this diagram to understand how application updates work in a stand-alone WAS environment where you have a single node within your cell:

This diagram illustrates a simple managed environment where you have a Deployment Manager that manages two application server nodes. Use this diagram to understand how application updates work in a managed WAS environment:

Multiple updates

If you have multiple updates with your deployment, it is more efficient to complete all updates before you save your changes instead of saving after each update.

In general, the correct process is:

1. Update using full module (see package and deploy for a full module)

2. Update using partial application (see package and deploy for a partial application)

3. Save

Not

1. Update using full module

2. Save

3. Update using partial application

4. Save

• Deploy J2EE assets for a single file
  This option provides the ability to deploy a single file asset into the J2EE application

• Deploy J2EE assets for a partial application
  The partial application option provides the ability to deploy several files into the J2EE application at the same time. This option should also be used if you want to delete any number of files that are in the J2EE application.

• Deploy J2EE assets for an entire module
  The single module option provides the ability to deploy an entire module to the J2EE application. Since there are many different types of modules in J2EE applications the steps can differ depending on the module type.

• Deploy a WAR module
  The single module option provides the ability to deploy an entire WAR module to the J2EE application. Since there are many different types of modules in J2EE applications the steps can differ depending on the module type.

• Compiling JavaServer Page files
  Compiling the JavaServer Page (JSP) files in your site or store will significantly reduce the amount of time needed to load your store. As a result, IBM recommends that you batch-compile your store or site JSP files after publishing a store archive and after deploying JSP files to a production environment.

• Validate changes have been deployed for a custom Enterprise Application (EAR) file
  Once you have deployed your custom EAR file, you should validate that your changes have been successfully deployed.

Related concepts

Dynamic caching

Related tasks

Package custom J2EE assets
Deploy J2EE assets for a single file
Deploy J2EE assets for a partial application
Deploy J2EE assets for an entire module
Validate changes have been deployed for a custom Enterprise Application (EAR) file
Start the wsadmin tool
Compiling JavaServer Page files

Related reference

Troubleshoot: Deployment