1 Reply Latest reply on Jun 17, 2005 4:10 PM by Dimitris Andreadis

    LifeCycle events

    George Icho Newbie

      I'am porting an application from weblogic to jboss, and I
      have a problem with the lifecycle events. Weblogic has a
      feature for handling lifecycle management. This feature is
      called "Application lifecycle listener events" and it provide
      handles on which developers can control behavior during
      deployment, undeployment, and redeployment.
      I asked about this before on the Jboss site, and I got the
      answer to use the subdeployers. So what I did was to write a
      class that extends the SubDeployerSupport and overrides the
      start() and stop() methods. But I can't get it to work so
      I'am wondering if I have missed something.

      Here is why I want to do this.

      Some of my enterprise applications need to run some code when the application is deployed or undeployed. For example when the subscription realm is deployed I want to start a periodic timer to cleanup any subscriptions that are marked for delete. When the subscription realm is undeployed I want to cancel this timer and run a final cleanup action.

      Thanks in advance/George

        • 1. Re: LifeCycle events
          Dimitris Andreadis Master

          You only write a SubDeployer if you need to plugin a new package type to jboss (e.g. .myear).

          SubDeployers, however, produce notifications whenever something gets deployed/undeployed. For example, to see those notification from the .war deployer, using the NotificationListener mbean, use:

           <mbean code="org.jboss.monitor.services.NotificationListener"
           <attribute name="SubscriptionList">
           <mbean name="jboss.web:service=WebServer">
           <filter factory="NotificationFilterSupportFactory">
           <enable type="org.jboss.deployment.SubDeployer.start"/>
           <enable type="org.jboss.deployment.SubDeployer.stop"/>

          If you want a different package type (e.g. .sar) configure the corresponding subdeployer objectname.

          So either implement a listener mbean and re-act to those notifications using:


          or a normal mbean that will be started/stopped in tandem with the deployment/undeployment by using the new barrier controller service: