Deployment

First of all, be aware that when IBM says EJB deployment, they usually mean the generation of EJB stubs and skeletons, not the deployment of anything. This is accomplished with the ejbdeploy.sh program. This section of this document is about deployment in the normal J2EE sense-- deploying something to an application server, not IBM's idiosyncratic use of the word.

Note that in this section I use $USER_INSTALL_ROOT to indicate the home of your WAS instance, whether it is an alternate instance or not. If you are running the default instance, the variable used is actually $WAS_HOME.

Note that what most of the J2EE world calls redeployment, IBM calls update. I.e.

         update = redeploy
     

What happens during deployment?

1. You supply an ear file and an application name to wsadmin.sh or to the Admin Console. (For an update, the app name must match an existing application name).
2. Your ear file is validated and written under $USER_INSTALL_ROOT/wstemp
3. When you save applications to WAS ("Save to global..." with WAS Admin, or "$AdminConfig save" with wsadmin.sh)
   1. J2EE ears and components get copied from $USER_INSTALL_ROOT/wstemp to $USER_INSTALL_ROOT/installedApps
   2. Deployment descriptors get written to $USER_INSTALL_ROOT/config/cells/<CELL>/application
   3. The server index for the target instances (nodes) get updated at $USER_INSTALL_ROOT/config/cells/<CELL>/nodes/<NODE>_<INST>/serverindex.xml
4. If you indicated to start the application during deployment, it will still not be started until WAS is restarted (you can, however start it at this time with the Admin Console). (If you indicated to start an application during an update, then it will be started when you save).

For "application name", do not include a file extension, like ".ear", because WAS deploys applications in a directory like "appname.ear". (So, if you name your app "x.ear", it would be deployed to "x.ear.ear".) Therefore, do not just accept Admin Console's default application name, which is just the ear file name.

Do not use spaces or special characters in your application name. Since we host on UNIX, these spaces cause difficulties for shell scripts (it isn't difficult to work around these difficulties, but most shell script writers do not know how to do it).

If you add any application that contains a context root change, or which contains a new .war, you will generally have to Update Web Server Plugin. This will add the new context roots to the plugin-cfg.xml file. Unless this context root is covered by an existing mapping in the file, your web server will not forward requests for this context to the app server. If you are running multiple instances, be aware that you are only updating the plugin-cfg.xml in your $USER_INSTALL_ROOT, and that plugin-cfg.xml file is only used if it is referenced by a web server config file.

Front end web servers do not need to be restarted after deploying new applications, nor after regenerating the plugin-cfg.xml file.

There is a deployment script in the wsadmin section of this document.