Install enterprise application files by adding them to a monitored directory
We can install an enterprise application file on an application server or cluster by dragging or copying an EAR, WAR, JAR, or Session Initiation Protocol (SIP) archive (SAR) to a monitored directory. An enterprise application file must conform to the JEE (Java EE) specification.
Develop and assemble the EAR, JAR, WAR, or SAR file. We can use a supported assembly tool such as an IBM Rational Application Developer for WebSphere Software product to specify bindings and assemble the file.
Installing an EAR, JAR, WAR, or SAR file by adding it to a monitored directory does not change existing Java Naming and Directory (JNDI) and other application bindings. If we must set binding values during deployment, install the file using the administrative console application installation wizard, a wsadmin script, or a properties file that sets bindings. See Install enterprise application files by adding properties files to a monitored directory.
By default, monitored directory deployment is not enabled. Before we can use monitored directory deployment, enable it. See Set monitored directory deployment values.
Restriction: Install an EAR, JAR, WAR, or SAR file by adding it to a monitored directory is available only on distributed and z/OS operating systems. It is not supported on IBM i operating systems.
Avoid trouble: Do not use monitored directory deployment in a production environment where the application must remain continuously available. Instead, in production environments, use an automated process that staggers application updates to each application server by first draining requests from each server, updating the application, and then restarting the server. For information about this automated process, see IBM WebSphere Developer Technical Journal: Maintain continuous availability while updating WebSphere Application Server enterprise applications.gotcha
We can deploy an EAR, JAR, WAR, or SAR file to an application server or cluster by dragging or copying the file to a monitored directory.
For base (stand-alone) application servers, the monitored directory is the monitoredDeployableApps/servers/server_name directory of the application server profile.
For deployment managers, the monitored directories are the monitoredDeployableApps/servers/server_name, monitoredDeployableApps/nodes/node/servers/server_name, and monitoredDeployableApps/clusters/cluster_name directories of the dmgr profile.
The product scans a monitored directory for new applications no more frequently than every five seconds, by default. After finding a new EAR, JAR, WAR, or SAR file in a monitored directory, the product installs the file on the application server or cluster and starts the application or module.
After we add an EAR file to a monitored directory, the product creates a temporary copy of the EAR file in another directory and installs the file on the server. After we add a JAR, WAR, or SAR file to a monitored directory, the product creates a temporary copy of the archive in another directory, wraps the archive in an EAR file named archive_extension.ear, and installs the new EAR file. For example, simpleApp.war is installed as simpleApp_war.ear. The original archive that we added to the monitored directory is not changed.
We can update application files the same way. If we later add an updated EAR, JAR, WAR, or SAR file to the same monitored directory, the product stops the previously deployed application, installs the updated file on the application server or cluster, and starts the updated application or module. For example, suppose you previously deployed my_app.ear by dragging it to a monitored directory. If we later drag a file named my_app.ear to the monitored directory, the product replaces the previously deployed EAR file with the updated EAR file that has the same name. The server or cluster must be running for the product to notice changes to files in its monitored directory.
We can use a graphical file browser to drag or copy the EAR, JAR, WAR, or SAR file. Alternatively, we can use operating system commands to copy a file into a monitored monitoredDeployableApps subdirectory.
- Ensure that the application server or cluster member on which to install the enterprise application file is running.
- Ensure that monitored directory deployment is enabled.
See Setting monitored directory deployment values.
- Browse the file structure of the computer and find or create the monitored directory.
For base (stand-alone) application servers, the monitored directory is under the application server profile. The directory path is:
- (dist) app_server_root/profiles/application_server_profile_name/monitoredDeployableApps/servers/server_name
- (zos) app_server_root/AppServer/profiles/default/monitoredDeployableApps/servers/server_name
For stand-alone servers, the product creates a monitored server_name directory automatically.
For application servers on a managed (federated) node of a deployment manager, create a monitored directory under the dmgr profile. The directory path is:
- (dist) app_server_root/profiles/deployment_manager_profile_name/monitoredDeployableApps/servers/server_name
- (zos) app_server_root/AppServer/profiles/default/monitoredDeployableApps/servers/server_name
For application servers on a federated node, create the monitored server_name directory. The directory name must match the name of an existing server.
If multiple servers of the same name are on different federated nodes and we want only one of the servers to be a monitored directory, we can specify the node and server for the monitored directory. Create the /nodes/node/servers/server_name directories under the dmgr profile. The directory path is:
- (dist) app_server_root/profiles/deployment_manager_profile_name/monitoredDeployableApps/nodes/node/servers/server_name
- (zos) app_server_root/DeploymentManager/profiles/default/monitoredDeployableApps/nodes/node/servers/server_name
Create directories for the node and the server. The node directory name must match the name of an existing node. The server_name directory name must match the name of an existing server on the node.
For clusters, create a monitored directory under the dmgr profile. The directory path is:
- (dist) app_server_root/profiles/deployment_manager_profile_name/monitoredDeployableApps/clusters/cluster_name
- (zos) app_server_root/DeploymentManager/profiles/default/monitoredDeployableApps/clusters/cluster_name
Create the monitored cluster_name directory. The directory name must match the name of an existing cluster.
- Copy the EAR, JAR, WAR, or SAR file to deploy to the monitored directory.
Choose a file that is not already deployed to the target monitored directory, unless to update a currently deployed file.
If a file is already deployed to a monitored directory of a deployment manager and to deploy the file to a different monitored directory of the deployment manager, remove the file from the current target monitored directory before we add the file to the new target monitored directory. For this release, an application file must exist in only one monitored directory of a deployment manager.
Results
The product adds a directory having the same name as the file to the installedApps/cell_name directory of the profile.
Also, the product writes messages about the application deployment to the SystemOut.log file in the app_server_root/logs/server_name directory. The messages start with the CWLDD message key.
The messages indicate that the product deployed the application file and that the application is running.
This topic references one or more of the application server log files. As a recommended alternative, we can configure the server to use the High Performance Extensible Logging (HPEL) log and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM i systems. We can also use HPEL in conjunction with the native z/OS logging facilities. If we are using HPEL, we can access all of the log and trace information using the LogViewer command-line tool from the server profile bin directory. See the information about using HPEL to troubleshoot applications for more information on using HPEL.
For installations on a deployment manager monitored directory, the product does not start an application or module automatically if the node agent or server is not running. If a node agent is stopped, the product installs the application or module at the deployment manager level, but does not synchronize the changes with the node and does not start the application or module. The changes will occur at the node the next time the agent is running and a node synchronization occurs. If the server is stopped but the node agent is running, the product installs the application or module and synchronizes the changes with the node, but does not start the server.
Example
Suppose to install the sample DynaCacheEsi.ear file by copying the EAR file to a monitored directory. We can find the sample EAR file in the app_server_root/installableApps directory.
Deploying an EAR file on a stand-alone application server
- Ensure that the application server on which to install the DynaCacheEsi.ear file is running.
To see if the server is running, we can use the serverStatus -all command. To start the server, we can use the startServer server_name command.
(dist) For example, suppose the stand-alone application server has a profile name of AppSrv02. Run the serverStatus command from a command prompt at the app_server_root/profiles/AppSrv02/bin directory:
serverStatus -all
If the server is not running, start the server.
(dist) For example, to start an application server named server1 on AppSrv02, run the startServer command from a command prompt at the app_server_root/profiles/AppSrv02/bin directory:
startServer server1
The Server server1 open for e-business message indicates that the server is running.
- Locate the monitored directory.
(dist) For the stand-alone AppSrv02 profile, the monitored directory is app_server_root/profiles/AppSrv02/monitoredDeployableApps/servers/server1.
- Copy the DynaCacheEsi.ear file in the app_server_root/installableApps directory to the monitored directory.
- Verify that the directory for installed applications exists.
- (dist) app_server_root/profiles/AppSrv02/installedApps/cell_name/DynaCacheEsi.ear
- (zos) app_server_root/profiles/default/installedApps/cell_name/DynaCacheEsi.ear
- Verify that DynaCacheEsi.ear is in the list of installed enterprise applications and is running.
Deploy an EAR file on a federated node of a deployment manager
- Ensure that the application server of the federated node on which to install the DynaCacheEsi.ear file is running.
To see if the server is running, we can use the serverStatus -all command. To start the server, we can use the startServer server_name command.
(dist) For example, suppose the server1 application server is on a node that has a profile name of AppSrv01. Run the serverStatus command from a command prompt at the app_server_root/profiles/AppSrv01/bin directory:
serverStatus -all
If the server is not running, start the server.
(dist) For example, run the startServer command from a command prompt at the app_server_root/profiles/AppSrv01/bin directory:
startServer server1
- Ensure that the DynaCacheEsi.ear file does not exist in a monitored directory of the deployment manager.
Add an application file to only one monitored directory of a deployment manager. If an application file already exists in a deployment manager monitored directory and we add an application file that has the same file name to a different deployment manager monitored directory, the product uninstalls the application file from the previous target and installs it to the new target. However, the new target is not synchronized with the deployment because the file still exists in the previous target monitored directory. To prevent problems with synchronization, remove DynaCacheEsi.ear from all monitored directories before we add DynaCacheEsi.ear to the new target directory.
- Create the monitored directory.
For federated nodes, create a monitored directory under the dmgr profile, unless the directory for the target server already exists.
(dist) For example, suppose the dmgr profile is Dmgr01 and the application server is server1.
- Go to the /monitoredDeployableApps/servers directory:
- (dist) app_server_root/profiles/Dmgr01/monitoredDeployableApps/servers
- (zos) app_server_root/AppServer/profiles/default/monitoredDeployableApps/servers
- If a directory named server1 exists in the servers directory, then go the next step.
If the server1 directory does not exist, create a directory named server1 in the /monitoredDeployableApps/servers directory.
The monitored directory is:
- (dist) app_server_root/profiles/Dmgr01/monitoredDeployableApps/servers/server1
- (zos) app_server_root/AppServer/profiles/default/monitoredDeployableApps/servers/server1
- Copy the DynaCacheEsi.ear file in the app_server_root/installableApps directory to the server1 monitored directory
- Verify that the directory for installed applications exists.
- (dist) app_server_root/profiles/AppSrv01/installedApps/cell_name/DynaCacheEsi.ear
- (zos) app_server_root/AppServer/profiles/default/installedApps/cell_name/DynaCacheEsi.ear
- Verify that DynaCacheEsi.ear is in the list of enterprise applications installed on the server and is running.
If multiple servers of the same name are on different federated nodes and we want only one of the servers to be a monitored directory, we can specify the node and server for the monitored directory. Create the /nodes/node/servers/server_name directories under the dmgr profile. For example, if we want the monitored directory to be the server1 application server on the myNode01 node, the directory path is:
- (dist) app_server_root/profiles/Dmgr01/monitoredDeployableApps/nodes/myNode01/servers/server1
- (zos) app_server_root/DeploymentManager/profiles/default/monitoredDeployableApps/nodes/myNode01/servers/server1
Only specify the node for a monitored directory if more than one server has the same name.
Deploying an EAR file on a cluster of a deployment manager
- Ensure that the cluster members of the cluster on which to install the DynaCacheEsi.ear file are running. For this example, cluster myCluster01 has one member, myClusterMember01.
- To see if the cluster is running, we can use the serverStatus -all command. To start the cluster member, we can use the startServer myClusterMember01 command.
(dist) For example, suppose myClusterMember01 is in the AppSrv01 profile. Run the serverStatus command from a command prompt at the app_server_root/profiles/AppSrv01/bin directory:
serverStatus -all
If the cluster member is not running, run the startServer command from a command prompt at the app_server_root/profiles/AppSrv01/bin directory:
startServer myClusterMember01
- Ensure that the DynaCacheEsi.ear file does not exist in a monitored directory of the deployment manager.
- Create the monitored directory.
For clusters, create a monitored directory under the dmgr profile, unless the directory for the target cluster member already exists.
(dist) For example, suppose the dmgr profile is Dmgr01:
- Go to app_server_root/profiles/Dmgr01/monitoredDeployableApps/clusters.
- If a directory named myCluster01 exists in the /clusters directory, then go to the next step.
If the myCluster01 directory does not exist, create a directory named myCluster01 in the /clusters directory.
The monitored directory is:
- (dist) app_server_root/profiles/Dmgr01/monitoredDeployableApps/clusters/myCluster01
- (zos) app_server_root/DeploymentManager/profiles/default/monitoredDeployableApps/clusters/myCluster01
- Copy the DynaCacheEsi.ear file in the app_server_root/installableApps directory to the myCluster01 monitored directory.
- Verify that the directory for installed applications exists.
- (dist) app_server_root/profiles/AppSrv01/installedApps/cell_name/DynaCacheEsi.ear
- (zos) app_server_root/AppServer/profiles/default/installedApps/cell_name/DynaCacheEsi.ear
- Verify that DynaCacheEsi.ear is in the list of enterprise applications installed on the cluster member and is running.
What to do next
Test the deployed application or module. For example, point a web browser at the URL for a deployed application and examine the performance of the application.
If the deployment is not successful, read messages in the SystemOut.log file, fix the error condition, and add the application or module to the monitored directory again.
Subtopics
- (dist)(zos) Set monitored directory deployment values
Before we can use the monitored directory application deployment service, enable it. We can optionally change the default monitored directory and polling interval values. By default, the monitored directory application deployment service is not enabled, the monitored directory is app_server_root/monitoredDeployableApps, and the polling interval is 5 seconds.
Related tasks
Install enterprise application files by adding properties files to a monitored directory Install enterprise application files Set monitored directory deployment values Uninstall enterprise application files by dragging them from a monitored directory Use High Performance Extensible Logging to troubleshoot applications
Directory conventions
Related information:
documentation
IBM WebSphere Developer Technical Journal: Maintain continuous availability while updating WebSphere Application Server enterprise applications