6-2 Developing Applications for Oracle WebLogic Server
■
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 Resource Adapters for Oracle WebLogic
Server.
6.2.1 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.
6.3 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.
6.3.1 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.
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
