The following sections describe how to create applications that respond to WebLogic Server application lifecycle events:
WARNING: | Application-scoped startup and shutdown classes have been deprecated as of release 9.0 of WebLogic Server. The information in this chapter about startup and shutdown classes is provided only for backwards compatibility. Instead, you should use lifecycle listener events in your applications. |
Application lifecycle listener events provide handles on which developers can control behavior during deployment, undeployment, and redeployment. This section discusses how you can use the application lifecycle listener events.
Four application lifecycle events are provided with WebLogic Server, which can be used to extend listener, shutdown, and startup classes. These include:
public void preStart(ApplicationLifecycleEvent evt) {}
public void postStart(ApplicationLifecycleEvent evt) {}
public void preStop(ApplicationLifecycleEvent evt) {}
public void postStop(ApplicationLifecycleEvent evt) {}
WARNING: | Application-scoped shutdown classes have been deprecated as of release 9.0 of WebLogic Server. Use lifecycle listeners instead. |
WARNING: | Application-scoped shutdown classes have been deprecated as of release 9.0 of WebLogic Server. Use lifecycle listeners instead. |
Note: | For Startup and Shutdown classes, you only implement a main{} method. If you implement any of the methods provided for Listeners, they are ignored. |
Note: | No remove{} method is provided in the ApplicationLifecycleListener, because the events are only fired at startup time during deployment (prestart and poststart) and shutdown during undeployment (prestop and poststop). |
In order to use these events, you must register them in the weblogic-application.xml deployment descriptor. See Application Deployment Descriptor Elements. Define the following elements:
You create a listener by extending the abstract class (provided with WebLogic Server) weblogic.application.ApplicationLifecycleListener. The container then searches for your listener.
You override the following methods provided in the WebLogic Server ApplicationLifecycleListener abstract class to extend your application and add any required functionality:
Listing 9-1 illustrates how you override the ApplicationLifecycleListener. In this example, the public class MyListener extends ApplicationLifecycleListener.
import weblogic.application.ApplicationLifecycleListener;
import weblogic.application.ApplicationLifecycleEvent;
public class MyListener extends ApplicationLifecycleListener {
public void preStart(ApplicationLifecycleEvent evt) {
System.out.println
("MyListener(preStart) -- we should always see you..");
} // preStart
public void postStart(ApplicationLifecycleEvent evt) {
System.out.println
("MyListener(postStart) -- we should always see you..");
} // postStart
public void preStop(ApplicationLifecycleEvent evt) {
System.out.println
("MyListener(preStop) -- we should always see you..");
} // preStop
public void postStop(ApplicationLifecycleEvent evt) {
System.out.println
("MyListener(postStop) -- we should always see you..");
} // postStop
public static void main(String[] args) {
System.out.println
("MyListener(main): in main .. we should never see you..");
} // main
}
Listing 9-2 illustrates how you implement the shutdown class. The shutdown class is attachable to preStop and postStop events. In this example, the public class MyShutdown does not extend ApplicationLifecycleListener because a shutdown class declared in the weblogic-application.xml deployment descriptor does not need to depend on any WebLogic Server-specific interfaces.
import weblogic.application.ApplicationLifecycleListener;
import weblogic.application.ApplicationLifecycleEvent;
public class MyShutdown {
public static void main(String[] args) {
System.out.println
("MyShutdown(main): in main .. should be for post-stop");
} // main
}
Listing 9-3 illustrates how you implement the startup class. The startup class is attachable to preStart and postStart events. In this example, the public class MyStartup does not extend ApplicationLifecycleListener because a startup class declared in the weblogic-application.xml deployment descriptor does not need to depend on any WebLogic Server-specific interfaces.
import weblogic.application.ApplicationLifecycleListener;
import weblogic.application.ApplicationLifecycleEvent;
public class MyStartup {
public static void main(String[] args) {
System.out.println
("MyStartup(main): in main .. should be for pre-start");
} // main
}
The following examples illustrate how you configure application lifecycle events in the weblogic-application.xml deployment descriptor file. The URI parameter is not required. You can place classes anywhere in the application $CLASSPATH. However, you must ensure that the class locations are defined in the $CLASSPATH. You can place listeners in APP-INF/classes or APP-INF/lib, if these directories are present in the EAR. In this case, they are automatically included in the $CLASSPATH.
The following example illustrates how you configure application lifecycle events using the URI parameter. In this case, the archive foo.jar contains the classes and exists at the top level of the EAR file. For example: myEar/foo.jar
<listener>
<listener-class>MyListener</listener-class>
<listener-uri>foo.jar</listener-uri>
</listener>
<startup>
<startup-class>MyStartup</startup-class>
<startup-uri>foo.jar</startup-uri>
</startup>
<shutdown>
<shutdown-class>MyShutdown</shutdown-class>
<shutdown-uri>foo.jar</shutdown-uri>
</shutdown>
The following example illustrates how you configure application lifecycle events without using the URI parameter.
<listener>
<listener-class>MyListener</listener-class>
</listener>
<startup>
<startup-class>MyStartup</startup-class>
</startup>
<shutdown>
<shutdown-class>MyShutdown</shutdown-class>
</shutdown>
Application lifecycle events are only triggered if a full re-deployment of the application occurs. During a full re-deployment of the application—provided the application lifecycle events have been registered—the application lifecycle 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 lifecycle set of events (preStart, postStart, preStop, postStop), during a full re-deployment, you see the following sequence of events:
The following sections describe how to create applications that respond to WebLogic Server application version lifecycle events:
WebLogic Server provides application version lifecycle event notifications by allowing you to extend the
ApplicationVersionLifecycleListener
class and specify a lifecycle listener in weblogic-application.xml
. See
Application Deployment Descriptor Elements and Examples of Configuring Lifecycle Events with and without the URI Parameter.
Application version lifecycle events are invoked:
ApplicationVersionLifecycleEvent.isOwnVersion
method to determine if an event belongs to a particular version. See the
ApplicationVersionLifecycleEvent
class for more information on types of version lifecycle events.Four application version lifecycle events are provided with WebLogic Server:
public void
preDeploy(ApplicationVersionLifecycleEvent evt)
public void
postDeploy(ApplicationVersionLifecycleEvent evt)
public void
preUndeploy(ApplicationVersionLifecycleEvent evt)
public void
postDelete(ApplicationVersionLifecycleEvent evt)
The following table provides an example of a deployment (V1), production redeployment (V2), and an undeploy (V2).
|
||||
|