Upgrading a running application in a J2EE production environment isn't easy. You either have to undeploy the old version of the application and deploy the new one—causing a temporary outage—or you may have to set up a redundant server/cluster to route the new requests.
BEA WebLogic Server 9.0 supports a production redeployment feature that provides a way to seamlessly upgrade an application in a production environment without affecting application availability. After redeploying a new version of the application, all new client connection requests go to the new application. The existing client connections continue to use the old application that will be undeployed/retired after all the existing connections are closed. The two application versions are completely isolated from each other and do not share any resources. Alternatively, the old version of the application can be retired by specifying a retire timeout for the application.
This article uses a sample application to demonstrate this functionality.
Currently, WebLogic Server 9.0 supports this production redeployment feature only for Web application (WAR) modules and enterprise applications (EARs). All other types of archives (EJB JAR, JCA RAR, WebServices archives, JMS, or JDBC standalone modules) are not supported. EARs can contain all supported module types, except WebServices archives. Production redeployment only supports HTTP clients; Java clients are not supported. Attempting to perform production redeployment with an unsupported archive type will result in an error. To redeploy such modules, remove their version identifiers and explicitly redeploy the modules.
In addition, only versioned applications can be redeployed using this feature. A versioned application is an application that has an application archive version specified in the manifest of the application archive.
A deployed application must specify a version number before you can perform subsequent production redeployment operations on the application. In other words, you cannot deploy a non-versioned application and later perform production redeployment with a new version of the application.
WebLogic Server 9.0 can host a maximum of two different versions of an application at any one time. Also, when you redeploy a new version of an application, you cannot change the application's deployment targets, security model, or persistent store settings. To change any of the above features, you must first undeploy the active version of the application.
The application version information can be specified in the MANIFEST.MF file's
WebLogic-Application-Version property. The manifest is a special file that can contain information about the files packaged in a JAR file. By tailoring this "meta" information that the manifest contains, you enable the JAR file to serve a variety of purposes.
For example, an application archive whose application archive version is "v1" could have the following manifest content:
Manifest-Version: 1.0 Created-By: 1.4.1_05-b01 (Sun Microsystems Inc.) WebLogic-Application-Version: v1
The application archive version is a string that can only contain the following characters: alphanumeric ("A"-"Z," "a"-"z," "0"-"9"), period ("."), underscore ("_"), and hyphen ("-"). The length of the application archive version should be less than 215 characters. Additionally, the application archive version string cannot be "." or "..". You can either specify a version for an application using the manifest file, or assign one when using the Deployer tool's
-appversion option. The value specified in MANIFEST.MF file will take precedence over the
The version number is important when considering the redeployment of versionable applications. If a new application archive version is specified, WebLogic Server will perform production redeployment with version isolation. If the same application archive version is specified, WebLogic Server will perform in-place redeployment.
The attached sample application (VersionedApp1) contains a Web application, which has three JSP files:
versionedjsp.jspfile contains a simple print statement.
session.invalidate()command to invalidate all the sessions.
timeoutsession.jspfile contains code to set the timeout value for the session.
The other application, VersionedApp2, contains the same set of files, but the
versionedjsp.jsp file will print a different message.
We'll use these applications to demonstrate the versioning process.
The sample applications provided along with this article do not have version information in their manifest files. If you want to use production redeployment with an application that does not include a version string in the manifest file, the Deployer tool allows you to manually specify a unique version string using the
-appversion option when deploying or redeploying an application. Run this command to deploy the application with a version of
java weblogic.Deployer -adminurl http://localhost:8802 -username weblogic -password weblogic -name VersionedApp -targets adminServer -deploy -source C:/tmp/VersionedApp1 -appversion version1
Deployer is a Java-based deployment tool that provides a command-line interface to the WebLogic Server deployment API. Deployer is intended for administrators and developers who want to perform interactive, command line-based deployment operations.
Note that the version string specified with
-appversion is applied only when the deployment source files do not specify a version string in MANIFEST.MF. For applications with version information in the manifest files, you need not provide the
You can also display version information for deployed applications from the command line using the Deployer
-listapps command. So for example, after deploying the above application you can run this command to list the application:
java weblogic.Deployer -adminurl http://localhost:8802 -user weblogic -password weblogic -listapps
Now that we've deployed the application, let's look at redeploying it. Since our deployment files do not contain version information in the manifest files, we perform redeploy with the
-appversion option as mentioned above:
java weblogic.Deployer -adminurl http://localhost:8802 -username weblogic -password weblogic -name VersionedApp -targets adminServer -redeploy -source C:/tmp/VersionedApp2 -appversion version2
If you want to specify a fixed time period after which the older version of the application is undeployed (regardless of whether clients finish their work), use the
-retiretimeout option with the
-redeploy command. (
-retiretimeout specifies the number of seconds after which the older version of the application is retired):
java weblogic.Deployer -adminurl http://localhost:8802 -username weblogic -password weblogic -name VersionedApp -targets adminServer -redeploy -source C:/tmp/VersionedApp2 -appversion version2 -retiretimeout 300
If WebLogic Server has not yet retired an application version, you can immediately undeploy the application version without waiting for retirement to complete. This may be necessary if, for example, an application remains in the retiring state with only one or two long-running client sessions that you do not want to preserve. To force the undeployment of a retiring version of an application, use the
-undeploy command and specify the application version:
java weblogic.Deployer -adminurl http://localhost:8802 -username weblogic -password weblogic -name VersionedApp -targets adminServer -undeploy -name VersionedApp -appversion version1
If you do not explicitly specify an application version with the
-appversion option, WebLogic Server undeploys the active version and all retired versions of the application.
After deploying the first version of the application, open a browser and invoke the
That should establish an HTTP session to the VersionedApp1 application. In the browser window we should see the "Output from VersionedApp1 JSP" message. After deploying the VersionedApp2 application, open another browser window and invoke the
versionedjsp.jsp. Now we should see the "Output from VersionedApp2 JSP" message from the VersionedApp2 application. At this time, both the versions of application should be alive.
Now invoke the
invalidatesession.jsp from the first browser window:
This will invalidate all the established sessions to the VersionedApp1 application. Take a look at the server console window. The retirement process should have started now. Wait a few moments for the retirement process to complete and invoke
versionedjsp.jsp from the first browser window:
This time you should see the "Output from VersionedApp2 JSP" message from the VersionedApp2 application.
Reversing the production redeployment process switches the state of the active and retiring applications and redirects new client connection requests accordingly. Reverting the production redeployment process may be necessary if you detect a problem with a newly deployed version of an application, and you want to stop clients from accessing it.
To roll back the production redeployment process, issue a second
-redeploy command and specify the deployment source files for the older version:
java weblogic.Deployer -adminurl http://localhost:8802 -user weblogic -password weblogic -redeploy -name VersionedApp C:/tmp/VersionedApp1 -retiretimeout 300
Production redeployment is a very powerful functionality. With this functionality, customers get the ability to roll out application upgrades in a production environment transparently, without disruption to clients. Production redeployment not only requires fewer hardware resources but also provides more flexibility and control of application availability. Administrators should definitely consider using this functionality in production environments, which will not only make their tasks easier, but also provide minimal disruption to the end user.
Abhijit Patil works as a Senior Software Engineer at BEA Systems. His expertise includes WebLogic application clustering and deployment.
Seetharam Param works as a Senior Software Engineer at BEA Systems. His expertise includes application deployment in WebLogic Server.