Ways to update Java EE applications on WebSphere deployment targets

Ways to update enterprise application files

We can update Java EE application files deployed on a server or cluster in several ways.

files. We can update application files using the console,
Option Method Comments Start after update
Administrative console update wizard
See Update enterprise applications with the console.
To remove a single file from a Java EE application or module, see the topic on removing enterprise files.
Briefly, do the following:

Go to the Enterprise applications page. Click Applications > Application Types > WebSphere enterprise applications in the console navigation tree.

Select the application to update and click Update.

On the Preparing for application update page, identify the application, module or files to update and click Next.

Complete steps in the update wizard and click Finish.
On the Preparing for application update page:

Use Full application to update an .ear file.

Use Single module to update a .war, .sar, enterprise bean .jar, or connector .rar file.

Use Single file to update a file other than an .ear, .war, .sar, EJB .jar, or .rar file.

Use Partial application to update or remove multiple files.

On the Enterprise applications page, select the updated application and click Start.
(dist)(zos) Monitored directory If we installed an application or module by adding it to a monitored directory, we can update it by adding an application or module that has the same file name to the monitored directory. Refer to the topic on installing enterprise application files by adding them to a monitored directory. After application or module installation, the product starts it automatically.
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.
(dist)(zos) Application properties files Create a properties file that specifies to update application files. Then, run the wsadmin applyConfigProperties command in any of the following ways:

In a script

At a command prompt

By adding the properties file to a monitoredDeployableApps/deploymentProperties monitored directory

Refer to the topic on installing enterprise application files by adding properties files to a monitored directory. After application or module installation, the product starts it automatically.
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.
wsadmin scripts
See the topic on updating installed applications using wsdmin.sh.
Use the update command or the updateInteractive command in a script or at a command prompt. For more information on the update and updateInteractive commands, see the topic on commands for the AdminApp object. The Getting started with wsadmin scripting topic provides an overview of wsadmin. Start the application using the invoke command and the startApplication attribute. For more information about the invoke command, see the topic on commands for the AdminControl object.
Java APIs
See the topic on using administrative programs (JMX).
Update deployed applications by completing the steps in the topic on managing applications through programming. Update an application in the following ways:

Update the entire application

Add to, replace or delete multiple files in an application

Add a module to an application

Update a module in an application

Delete a module in an application

Add a file to an application

Update a file in an application

Delete a file in an application

Invoke the AdminApp startApplication command.

Invoke the startApplication method on an ApplicationManager MBean using AdminControl.

Rapid deployment tools
See topics under Rapid deployment of J2EE applications.
Briefly, do the following:

Update the J2EE application files.

Set up the rapid deployment environment.

Create a free-form project.

Launch a rapid deployment session.

Drop the updated application files into the free-form project.
Rapid deployment tools offer the following advantages:

You do not need to assemble the J2EE application files prior to deployment.

You do not need to use other installation tools mentioned in this table to deploy the files.

Use any of the previous options to start the application. Clicking Start on the Enterprise applications page is the easiest option.
Hot deployment and dynamic reloading Briefly, do the following:

Update the application (.ear), web module (.war), enterprise bean .jar or HTTP plug-in configuration file.

Follow instructions in Hot deployment and dynamic reloading to update your file.
If we are new to WebSphere Application Server, use the administrative console to update applications. That option is easier.
Hot deployment and dynamic reloading is more difficult to complete. We must directly manipulate the application or module file on the server where the application is deployed.
In particular, any new function which uses annotations can interact substantially with Hot Deployment. See the information below under The metadata-complete attribute for more information on these interactions when deploying applications with hot deployment.
Use any of the previous options to start the application. Clicking Start on the Enterprise applications page is the easiest option.

We can update .ear, enterprise bean .jar, web module .war, Session Initiation Protocol (SIP) archive (.sar), connector .rar, application client .jar, and any other files used by an installed application.
If the application is updated while it is running, WebSphere Application Server automatically stops the application, updates the application logic and restarts the application. If the application does not start automatically, start it manually using one of the Starting options. For more information on the restarting of updated applications, refer to "Fine-grained recycle behavior" in IBM WebSphere Developer Technical Journal: System management for WebSphere Application Server V6 -- Part 5 Flexible options for updating deployed applications.
If we update module metadata while an application is running, restarting the application might not be sufficient for the changes to take effect. For example, if you change descriptors in running Java EE 6 applications that use annotations, you must reinstall the application. If we change classes that introduce, remove, or alter class hierarchies within an application, and those changes impact annotated classes, we also must reinstall the application.

The metadata-complete attribute: When updating the metadata for a web module, you must be concerned with the setting of the metadata-complete attribute.

When metadata-complete is false, two new files are written: web_merged.xml, which contains the results of merged in web.xml with annotations metadata, plus a new file, ibm-metadata.xml, which contains additional annotations-related data, which cannot be stored in web_merged.xml. The web_merged.xml file also contains additional metadata that is read from web-fragment.xml in jar files under WEB-INF/lib of the WAR.

When metadata-complete is true, web_merged.xml is NOT generated and ibm-metadata.xml is NOT created. The ibm-metadata.xml file is only generated if a web_merged.xml file is generated.

The metadata-complete attribute can be omitted from web.xml (or web-fragment.xml), in which case a default value of "false" is assumed for it.
The metadata-complete attribute must be added to the web.xml file or the web_merged file as shown below:.
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"  xmlns:xsi="http://www.w3.org/2011/XMLSchema-instance"  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee  http://java.sun.com/xml/ns/javaee/web-app_3.0.xsd"  version="3.0" metadata-complete="true">
<display-name>TestServlet30</display-name>
</web-app>
The web.xml and web_fragment.xml files should be updated, if these files are driving the hot deployment update. If only web_merged.xml is updated, the hot deployment changes will be lost if any administrative action is taken that causes a regeneration of web_merged.xml.
Important: If metadata-complete is false in web.xml, we need to update web.xml and web_merged.xml on hot deployment of Servlet (web) 2.5 applications. If metadata-complete is true in web.xml, we need to update ONLY web.xml on hot deployment of Servlet (web) 2.5 applications.
Processing of web.xml in a WAR file and ejb-jar.xml in an EJBJAR file are the same, with web_merged.xml created for a WAR file if the web.xml is absent or has metadata-complete set to false, with ejb-jar_merged.xml created for an EJBJAR file if the ejb-jar.xml is absent or has metadata-complete set to false.
In either case, an ibm-metadata.xml is created whenever a merged XML is created. (And only if the merged XML is created.)
In either case, if the deployment changes metadata-complete from false to true, the XML file (web.xml or ejb-jar.xml) is created or replaced, no merged XML file is created, and no ibm-metadata.xml is created.
The additional case is for EJB content in a WAR file (EJB-IN-WAR). For this case, there are additional complex rules: First, the web.xml metadata-complete setting interacts with the EJB-IN-WAR processing. Second, when no EJB content is present in the WAR file, no EJB-IN-WAR processing is performed.. Third, deployment may independently change metadata-complete from false to true for either the web.xml or the ejb-jar.xml. Fourth and finally, ibm-metadata.xml is created when either of the merged XML is created. (And is not created when neither merged XML is created.)
With regards to EJB-IN-WAR, when the web.xml has metadata-complete set to true, and no ejb-jar.xml is present, no EJB-IN-WAR processing is done, even when EJB annotations are present in the WAR file.
With regards to EJB-IN-WAR, when the web.xml has metadata-complete set to false (or when the web.xml is absent), and when no ejb-jar.xml is present, EJB-IN-WAR processing is performed only when EJB annotations are present in the WAR file.
With regards to EJB-IN-WAR, when an ejb-jar.xml is present, the metadata-complete setting of the web.xml is not used to determine what EJB processing is done. When an ejb-jar.xml is present, what EJB-IN-WAR processing is done is determined by the metadata-complete setting of the ejb-jar.xml.

Related tasks

Update enterprise application files
Remove enterprise files
(dist)(zos) Install enterprise application files by adding them to a monitored directory
(dist)(zos) Install enterprise application files by adding properties files to a monitored directory
Get started with wsadmin scripting
Start applications
Use administrative programs (JMX)
Manage applications through programming
Start an application through programming
Update installed applications using wsdmin.sh

Enterprise application collection
Commands for the AdminApp object
Commands for the AdminControl object

Related information:

IBM WebSphere Developer Technical Journal: System management for WebSphere Application Server V6 -- Part 5 Flexible options for updating deployed applications applications

Option	Method	Comments	Start after update
Administrative console update wizard See Update enterprise applications with the console. To remove a single file from a Java EE application or module, see the topic on removing enterprise files.	Briefly, do the following: Go to the Enterprise applications page. Click Applications > Application Types > WebSphere enterprise applications in the console navigation tree. Select the application to update and click Update. On the Preparing for application update page, identify the application, module or files to update and click Next. Complete steps in the update wizard and click Finish.	On the Preparing for application update page: Use Full application to update an .ear file. Use Single module to update a .war, .sar, enterprise bean .jar, or connector .rar file. Use Single file to update a file other than an .ear, .war, .sar, EJB .jar, or .rar file. Use Partial application to update or remove multiple files.	On the Enterprise applications page, select the updated application and click Start.
(dist)(zos) Monitored directory	If we installed an application or module by adding it to a monitored directory, we can update it by adding an application or module that has the same file name to the monitored directory.	Refer to the topic on installing enterprise application files by adding them to a monitored directory.	After application or module installation, the product starts it automatically. 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.
(dist)(zos) Application properties files	Create a properties file that specifies to update application files. Then, run the wsadmin applyConfigProperties command in any of the following ways: In a script At a command prompt By adding the properties file to a monitoredDeployableApps/deploymentProperties monitored directory	Refer to the topic on installing enterprise application files by adding properties files to a monitored directory.	After application or module installation, the product starts it automatically. 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.
wsadmin scripts See the topic on updating installed applications using wsdmin.sh.	Use the update command or the updateInteractive command in a script or at a command prompt. For more information on the update and updateInteractive commands, see the topic on commands for the AdminApp object.	The Getting started with wsadmin scripting topic provides an overview of wsadmin.	Start the application using the invoke command and the startApplication attribute. For more information about the invoke command, see the topic on commands for the AdminControl object.
Java APIs See the topic on using administrative programs (JMX).	Update deployed applications by completing the steps in the topic on managing applications through programming.	Update an application in the following ways: Update the entire application Add to, replace or delete multiple files in an application Add a module to an application Update a module in an application Delete a module in an application Add a file to an application Update a file in an application Delete a file in an application	Invoke the AdminApp startApplication command. Invoke the startApplication method on an ApplicationManager MBean using AdminControl.
Rapid deployment tools See topics under Rapid deployment of J2EE applications.	Briefly, do the following: Update the J2EE application files. Set up the rapid deployment environment. Create a free-form project. Launch a rapid deployment session. Drop the updated application files into the free-form project.	Rapid deployment tools offer the following advantages: You do not need to assemble the J2EE application files prior to deployment. You do not need to use other installation tools mentioned in this table to deploy the files.	Use any of the previous options to start the application. Clicking Start on the Enterprise applications page is the easiest option.
Hot deployment and dynamic reloading	Briefly, do the following: Update the application (.ear), web module (.war), enterprise bean .jar or HTTP plug-in configuration file. Follow instructions in Hot deployment and dynamic reloading to update your file.	If we are new to WebSphere Application Server, use the administrative console to update applications. That option is easier. Hot deployment and dynamic reloading is more difficult to complete. We must directly manipulate the application or module file on the server where the application is deployed. In particular, any new function which uses annotations can interact substantially with Hot Deployment. See the information below under The metadata-complete attribute for more information on these interactions when deploying applications with hot deployment.	Use any of the previous options to start the application. Clicking Start on the Enterprise applications page is the easiest option.