You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Lifecycle Callback handlers

The Lifecycle Callback Handler manage callbacks on the component when the component state changes.

Lifecycle Callbacks

The lifecycle callbacks allow calling methods when the component state changed. You can use this features if your component need to do some actions when it becomes valid (for example create and launch a thread) or need to do some actions when it becomes invalid (for example stop the thread).

Component lifecycle transition

figure

iPOJO components have two states: VALID and INVALID The state is valid when all handlers are valid. The state becomes invalid when one or more handlers are not valid. The next figure shows the component states automata. When you use the iPOJO standard component model, the only handler interfering with the component state is the dependencies. Consequently, a component is valid when all its dependencies are valid, and a component is invalid when one or several dependencies are invalid.

Lifecycle Callback Metadata

The next figure shows the lifecycle callbacks metadata.
Figure

A callback owns a method and describes the transition on which the method should be called. The initial and final attributes defines the initial and the final state of the transition. So the value can be either VALID either INVALID The method attribute contains the name of the method to call. The last attribute is optional. isStatic is "true" when the method is a static method. By default, isStatic is "false".

Examples

Source code

The following code shows you a component with two callbacks: starting and stopping.

 package fr.imag.adele.escoffier.hellorequester.impl;

 import fr.imag.adele.escoffier.hello.HelloService;

 public class HelloRequesterImpl implements Runnable {

    final static int DELAY=10000;
    HelloService[] m_hello;  // Service Dependency
    boolean end;

    public void run() {
        while (!end) {
            try {
        synchronized (this) { {
                for(int i = 0; i < m_hello.length; i++) {
                        System.out.println(m_hello[i].sayHello("Clement"));
                    }
        }
                Thread.sleep(DELAY);
            } catch (InterruptedException ie) {
                /* will recheck quit */
            }
        }
    }
   
    public void starting() {
        Thread T = new Thread(this);
        end = false;
        T.start();
    }
   
    public void stopping() { end = true; }

XML Metadata

Hence, XML-metadata associated with this component need to contain:

<Callback initial="INVALID" final="VALID" method="starting"/>
<Callback initial="VALID" final="INVALID" method="stopping"/>

Manifest Metadata

The manifest-metadata associated with this component need to contain:

Callback

Unknown macro: { $initial=INVALID $final=VALID $method=starting }

Callback

Unknown macro: { $initial=VALID $final=INVALID $method=stopping }

Component Instance Creation

When a non-static "starting" callback is called, it needs a component instance. Therefore, the callback asks the component manager to create an instance. Each callback and each singleton provided service would use this instance.

Callback on multi-component instance

When several instance of the component are created, the callback are called on each instance in the creation order.

Limitation and perspectives

The main limitation of the lifecycle callbacks is that the component lifecycle is very small. Therefore, we are thinking about how extends the component lifecycle with extensible and customizable lifecycle.

  • No labels