Programming Application Life Cycle Events 10-5
The following example illustrates how you configure application life cycle events without using the URI parameter.
Example 10–5 Configuring Application Life Cycle Events without Using the URI
Parameter
listener listener-classMyListenerlistener-class
listener startup
startup-classMyStartupstartup-class startup
shutdown shutdown-classMyShutdownshutdown-class
shutdown
10.5 Understanding Application Life Cycle Event Behavior During Re-deployment
Application life cycle events are only triggered if a full re-deployment of the application occurs. During a full re-deployment of the application—provided the
application life cycle events have been registered—the application life cycle first commences the shutdown sequence, next re-initializes its classes, and then performs
the startup sequence.
For example, if your listener is registered for the full application life cycle set of events preStart, postStart, preStop, postStop, during a full re-deployment, you see the
following sequence of events:
1.
preStop{}
2.
postStop{}
3.
Initialization takes place. Unless you have set debug flags, you do not see the initialization.
4.
preStart{}
5.
postStart{}
10.6 Programming Application Version Life Cycle Events
The following sections describe how to create applications that respond to WebLogic Server application version life cycle events:
■
Section 10.6.1, Understanding Application Version Life Cycle Event Behavior
■
Section 10.6.2, Types of Application Version Life Cycle Events
■
Section 10.6.3, Example of Production Deployment Sequence When Using Application Version Life Cycle Events
10.6.1 Understanding Application Version Life Cycle Event Behavior
WebLogic Server provides application version life cycle event notifications by allowing you to extend the ApplicationVersionLifecycleListener class and specify a
life cycle listener in weblogic-application.xml. See Appendix A, Enterprise
Application Deployment Descriptor Elements and
Section 10.4, Examples of Configuring Life Cycle Events with and without the URI Parameter
.
10-6 Developing Applications for Oracle WebLogic Server
Application version life cycle events are invoked:
■
For both static and dynamic deployments.
■
Using either anonymous ID or using user identity.
■
Only if the current application is versioned; otherwise, version life cycle events are ignored.
■
for all application versions, including the version that registers the listener. Use the ApplicationVersionLifecycleEvent.isOwnVersion method to determine
if an event belongs to a particular version. See the ApplicationVersionLifecycleEvent class for more information on types of
version life cycle events.
10.6.2 Types of Application Version Life Cycle Events
Four application version life cycle events are provided with WebLogic Server:
■
public void preDeployApplicationVersionLifecycleEvent evt
– The preDeloy event is invoked when an application version deploy or
redeploy operation is initiated.
■
public void postDeployApplicationVersionLifecycleEvent evt
– The postDeloy event is invoked when an application version is deployed or
redeployed successfully.
■
public void preUndeployApplicationVersionLifecycleEvent evt
– The preUndeloy event is invoked when an application version undeploy
operation is initiated.
■
public void postDeleteApplicationVersionLifecycleEvent evt
– The postDelete event is invoked when an application version is deleted.
10.6.3 Example of Production Deployment Sequence When Using Application Version Life Cycle Events
The following table provides an example of a deployment V1, production redeployment V2, and an undeploy V2.
Note: A postDelete event is only fired after the entire application
version is completely removed. It does not include a partial undeploy, such as undeploying a module or from a subset of targets.
Table 10–1 Sequence of Deployment Actions and Application Version Life Cycle Events
Deployment action Time
Version V1 Version V2
Deployment of Version V1 T0 preDeployV1 invoked.
T1 Deployment starts.
T2 Application life cycle listeners for V1
are registered. T3
V1 is active version, Deployment is complete.
T4 postDeployV1 invoked.
Programming Application Life Cycle Events 10-7
T5 Application Listeners gets
postDeployV1. Production Redeployment
of Version V2 T6
preDeployV2 invoked. T7
Application version listener receives preDeployV1.
T8 Deployment starts.
T9 Application life cycle listeners for V2
are registered. T10
If deployV2 succeeds, V1 ceases to be active version.
If deployV2 succeeds, V2 replaces V1 as active version.
Deployment is complete. T11
postDeployV2 invoked.
Note:
This event occurs even if the deployment fails.
T12 Application version listener gets
postDeployV2. If deployV2 fails, V1 remains active.
T13 Application listeners gets
postDeployV2. T14
If deployV2 succeeds, V1 begins retirement.
T15 Application listeners for V1 are
unregistered. T16
V1 is retired. Undeployment of V2
T17 preUndeployv2 invoked.
T18 Application listeners gets
preUndeployv2 invoked. T19
Undeployment begins. T20
V2 is no longer active version. T21
Application version listeners for V2 are unregistered.
T22 Undeployment is complete.
T23 If the entire application is
undeployed, postDeleteV2 is invoked.
Note:
This event occurs even if the undeployment fails.
Table 10–1 Cont. Sequence of Deployment Actions and Application Version Life Cycle Events
Deployment action Time
Version V1 Version V2
10-8 Developing Applications for Oracle WebLogic Server
11
Programming Context Propagation 11-1
11
Programming Context Propagation
The following sections describe how to use the context propagation APIs in your applications:
■
Section 11.1, Understanding Context Propagation
■
Section 11.2, Programming Context Propagation: Main Steps
■
Section 11.3, Programming Context Propagation in a Client
■
Section 11.4, Programming Context Propagation in an Application
11.1 Understanding Context Propagation
Context propagation allows programmers to associate information with an application which is then carried along with every request. Furthermore, downstream components
can add or modify this information so that it can be carried back to the originator. Context propagation is also known as work areas, work contexts, or application
transactions.
Common use-cases for context propagation are any type of application in which information needs to be carried outside the application, rather than the information
being an integral part of the application. Examples of these use cases include diagnostics monitoring, application transactions, and application load-balancing.
Keeping this sort of information outside of the application keeps the application itself clean with no extraneous API usage and also allows the addition of information to
read-only components, such as 3rd party components.
Programming context propagation has two parts: first you code the client application to create a WorkContextMap and WorkContext, and then add user data to the
context, and then you code the invoked application itself to get and possibly use this data. The invoked application can be of any type: EJB, Web Service, servlet, JMS topic
or queue, and so on. See
Section 11.2, Programming Context Propagation: Main Steps for details.
The WebLogic context propagation APIs are in the weblogic.workarea package. The following table describes the main interfaces and classes.
11-2 Developing Applications for Oracle WebLogic Server
For the complete API documentation about context propagation, see the weblogic.workarea Javadocs.
11.2 Programming Context Propagation: Main Steps
