Skip navigation.
Downloads | Product Documentation | Support

Developing Applications with WebLogic Server

# Developing Applications for Production Redeployment

The following sections describes how to program and maintain applications use the production redeployment strategy:

- What is Production Redeployment?
- Supported and Unsupported Application Types
- Programming Requirements and Conventions
- Assigning an Application Version
- Upgrading Applications to Use Production Redeployment
- Accessing Version Information

# What is Production Redeployment?

Production redeployment enables an Administrator to redeploy a new version of an application in a production environment without stopping the deployed application or otherwise interrupting the application's availability to clients. Production redeployment works by deploying a new version of an updated application alongside an older version of the same application. WebLogic Server automatically manages client connections so that only new client requests are directed to the new version. Clients already connected to the application during the redeployment continue to use the older, retiring version of the application until they complete their work.

See Using Production Redeployment to Upgrade Applications for more information.

# Supported and Unsupported Application Types

Production redeployment is supported primarily for applications with a Web application entry point (HTTP clients). WebLogic Server can automatically manage HTTP client entry points to isolate connections to the newer and older application versions. This means that production redeployment is supported for standalone Web Application modules, and for Enterprise Applications that are accessed via an embedded Web Application module.

Applications that are accessed by Java clients, including applets, are specifically not supported with production redeployment. Java clients that attempt a JNDI lookup of global bindings for a versioned application receive a warning about this issue. These types of lookups must be avoided because WebLogic Server does not property track the work initiated by the Java clients that is still in progress, such as transactions or method calls that are still active. As a result, the application version may be retired prematurely, while thework initiated by the Java clients is still in progress. Clients can disable this checking by setting `weblogic.jndi.WLContext.ALLOW_EXTERNAL_APP_LOOKUP` to `true` when performing JNDI lookups.

Enterprise Applications can contain any of the supported J2EE module types except Web Services modules. Web Services modules are not supported for production redeployment, even if you package the service in a WAR file. When a production redeployment operation is requested, the WebLogic Server deployment API checks for the presence of Web Services modules and throws an exception if one is found. Enterprise Applications can also include application-scoped JMS and JDBC modules.

If an Enterprise Application includes a JCA resource adapter module, the module:

- Must be JCA 1.5 compliant
- Must implement the `weblogic.connector.extensions.Suspendable` interface
- Must be used in an application-scoped manner, having `enable-access-outside-app` set to `false` (the default value).

Before resource adapters in a newer version of the EAR are deployed, resource adapters in the older application version receive a callback. WebLogic Server then deploys the newer application version and retires the entire older version of the EAR.

For a complete list of production redeployment requirements for resource adapters, see Production Redeployment in Programming WebLogic Resource Adapters.

## Additional Application Support

Additional production redeployment support is provided for Enterprise Applications that are accessed by inbound JMS messages from a global JMS destination, and that use one or more message-driven beans as consumers. For this type of application, WebLogic Server suspends message-driven beans in the older, retiring application version before deploying message-driven beans in the newer version. Production redeployment is not supported with JMS consumers that use the JMS API for global JMS destinations. If the message-driven beans need to receive all messages published from topics, including messages published while bean are suspended, use durable subscribers.

# Programming Requirements and Conventions

WebLogic Server performs production redeployment by deploying two instances of an application simultaneously. You must observe certain programming conventions to ensure that multiple instances of the application can co-exist in a WebLogic Server domain. The following sections describe each programming convention required for using production redeployment.

## Applications Should Be Self-Contained

As a best practice, applications that use the in-place redeployment strategy should be self-contained in their use of resources. This means you should generally use application-scoped JMS and JDBC resources, rather than global resources, whenever possible for versioned applications.

If an application must use a global resource, you must ensure that the application supports safe, concurrent access by multiple instances of the application. This same restriction also applies if the application uses external (separately-deployed) applications, or uses an external property file. WebLogic Server does not prevent the use of global resources with versioned applications, but you must ensure that resources are accessed in a safe manner.

Looking up a global JNDI resource from within a versioned application results in a warning message. To disable this check, set the JNDI environment property `weblogic.jndi.WLContext.ALLOW_GLOBAL_RESOURCE_LOOKUP` to `true` when performing the JNDI lookup.

Similarly, looking up an external application results in a warning unless you set the JNDI environment property, `weblogic.jndi.WLContext.ALLOW_EXTERNAL_APP_LOOKUP`, to `true`.

## Versioned Applications Access the Current Version JNDI Tree by Default

WebLogic Server binds application-scoped resources, such as JMS and JDBC application modules, into a local JNDI tree available to the application. As with non-versioned applications, versioned applications can look up application-scoped resources directly from this local tree. Application-scoped JMS modules can be accessed via any supported JMS interfaces, such as the JMS API or a message-driven bean.

Application modules that are bound to the global JNDI tree should be accessed only from within the same application version. WebLogic Server performs version-aware JNDI lookups and bindings for global resources deployed in a versioned application. By default, an internal JNDI lookup of a global resource returns bindings for the same version of the application.

If the current version of the application cannot be found, you can use the JNDI environment property `weblogic.jndi.WLContext.RELAX_VERSION_LOOKUP` to return bindings from the currently active version of the application, rather than the same version.

Warning: Set `weblogic.jndi.WLContext.RELAX_VERSION_LOOKUP` to `true` only if you are certain that the newer and older version of the resource that you are looking up are compatible with one another.

## Security Providers Must Be Compatible

Any security provider used in the application must support the WebLogic Server application versioning SSPI. The default WebLogic Server security providers for authorization, role mapping, and credential mapping support the application versioning SSPI.

## Applications Must Specify a Version Identifier

In order to use production redeployment, both the current, deployed version of the application and the updated version of the application must specify unique version identifiers. See Assigning an Application Version.

## Applications Can Access Name and Identifier

Versioned applications can programmatically obtain both an application name, which remains constant across different versions, and an application identifier, which changes to provide a unique label for different versions of the application. Use the application name for basic display or error messages that refer to the application's name irrespective of the deployed version. Use the application ID when the application must provide unique identifier for the deployed version of the application. See Accessing Version Information for more information about the MBean attributes that provide the name and identifier.

## Client Applications Use Same Version when Possible

As described in What is Production Redeployment?, WebLogic Server attempts to route a client application's requests to the same version of the application until all of the client's in-progress work has completed. However, if an application version is retired using a timeout period, or is undeployed, the client's request will be routed to the active version of the application. In other words, a client's association with a given version of an application is maintained only on a "best-effort basis."

This behavior can be problematic for client applications that recursively access other applications when processing requests. WebLogic Server attempts to dispatch requests to the same versions of the recursively-accessed applications, but cannot guarantee that an intermediate application version is not undeployed manually or after a timeout period. If you have a group of related applications with strict version requirements, BEA recommends packaging all of the applications together to ensure version consistency during production redeployment.

# Assigning an Application Version

BEA recommends that you specify the version identifier in the `MANIFEST.MF` of the application, and automatically increment the version each time a new application is released for deployment. This ensures that production redeployment is always performed when the administrator or deployer redeploys the application.

For testing purposes, a deployer can also assign a version identifier to an application during deployment and redeployment. See Assigning a Version Identifier During Deployment and Redeployment in Deploying Applications to WebLogic Server.

## Application Version Conventions

WebLogic Server obtains the application version from the value of the `Weblogic-Application-Version` property in the `MANIFEST.MF` file. The version string can be a maximum of 215 characters long, and must consist of valid characters as identified in Figure 7-1.

Table 7-1 Valid and Invalid Characters

Valid ASCII Characters | Invalid Version Constructs
--- | ---
a-z | ..
A-Z | .
0-9 |
period ("."), underscore ("_"), or hyphen ("-") in combination with other characters |

For example, the following manifest file content describes an application with version "v1":

>     Manifest-Version: 1.0
>          Created-By: 1.4.1_05-b01 (Sun Microsystems Inc.)
>          Weblogic-Application-Version: v1

# Upgrading Applications to Use Production Redeployment

If you are upgrading applications for deployment to WebLogic Server 9.1, note that the `Name` attribute retrieved from `AppDeploymentMBean` now returns a unique application identifier consisting of both the deployed application name and the application version string. Applications that require only the deployed application name must use the new `ApplicationName` attribute instead of the `Name` attribute. Applications that require a unique identifier can use either the `Name` or `ApplicationIdentifier` attribute, as described in Accessing Version Information.

# Accessing Version Information

Your application code can use new MBean attributes to retrieve version information for display, logging, or other uses. Table 7-2 describes the read-only attributes provided by `ApplicationMBean`.

Table 7-2 Read-Only Version Attributes in ApplicationMBean

Attribute Name | Description
--- | ---
`ApplicationName` | A String that represents the deployment name of the application
`VersionIdentifier` | A String that uniquely identifies the current application version across all versions of the same application
`ApplicationIdentifier` | A String that uniquely identifies the current application version across all deployed applications and versions

`ApplicationRuntimeMBean` also provides version information in the new read-only attributes described in Table 7-3.

Table 7-3 Read-Only Version Attributes in ApplicationRuntimeMBean

Attribute Name | Description
--- | ---
`ApplicationName` | A String that represents the deployment name of the application
`ApplicationVersion` | A string that represents the version of the application.
`ActiveVersionState` | An integer that indicates the current state of the active application version. Valid states for an active version are: ACTIVATED—indicates that one or more modules of the application are active and available for processing new client requests. PREPARED—indicates that WebLogic Server has prepared one or more modules of the application, but that it is not yet active. UNPREPARED—indicates that no modules of the application are prepared or active. See the WebLogic Server 9.1 API Reference for more information. Note that the currently active version does not always correspond to the last-deployed version, because the Administrator can reverse the production redeployment process. See Rolling Back the Production Redeployment Process in Deploying Applications to WebLogic Server.