Developing Applications for Production Redeployment 6-3
6.3.2 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.
6.3.3 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.
6.3.4 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 Section 6.4, Assigning an Application Version
.
6.3.5 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 applications
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
Section 6.6, Accessing Version Information for more information about the
MBean attributes that provide the name and identifier.
6.3.6 Client Applications Use Same Version when Possible
As described in Section 6.1, What is Production Redeployment?
, WebLogic Server attempts to route a client applications requests to the same version of the application
until all of the clients in-progress work has completed. However, if an application version is retired using a timeout period, or is undeployed, the clients request will be
routed to the active version of the application. In other words, a clients association with a given version of an application is maintained only on a best-effort basis.
Note:: 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.
6-4 Developing Applications for Oracle WebLogic Server
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, Oracle recommends packaging all of the applications together to ensure version
consistency during production redeployment.
6.4 Assigning an Application Version
