Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

Include Page
apache-felix-ipojo-header
apache-felix-ipojo-header

...

HTML

...


<div class="content">

The extender pattern handler

The objective of this handler is to simplify the development of extender-based architecture. This architecture-style is based on two different entities:

  • The extender (also called host)
  • The extensions
Div
classtoc
Table of Contents
maxLevel4
minLevel2

The Extender pattern

This architecture-style is based on two different roles:

  • The extender
  • The extension

Image Added

The relation is basically a 1..n relation. The extender tracks extensions. The particularity of this architecture-style is that extensions are packaged in different bundles. An extension is detected by analyzing the bundle. Indeed these bundles can have a special mark in their manifest of a special file...
Implementing an extender pattern could be complex as the extender needs to track these marks dynamically. When a bundle starts, it needs to look at the mark. Then a bundle leave, the extender must release all object created from this bundle.
This handler tracks bundle for you based on the specified required mark. At each time a matching bundle appears or disappears, a callback is invoked. The mark is currently a header in the bundle manifest.
Nowadays, a lot of frameworks use this pattern such as iPOJO it-self (to find both bundles containing components and bundles adding a new implementation type), Spring-DM ...

Using the handler

First of all, you need to configure the component type to use the handler such as:

Code Block
xml
xml

<ipojo{html}

h1.  The extender pattern handler
_The objective of this handler is to simplify the development of extender-based architecture. This architecture-style is based on two different entities:_
* _The extender (also called host)_ 
* _The extensions_

{div:class=toc}
{toc:maxLevel=4|minLevel=2}
{div}

h2. The Extender pattern

This architecture-style is based on two different roles:
* The extender 
* The extension

!extender.png!

The relation is basically a 1..n relation. The extender tracks extensions. The particularity of this architecture-style is that extensions are packaged in different bundles. An extension is detected by analyzing the bundle. Indeed these bundles can have a special mark in their manifest of a special file...
Implementing an extender pattern could be complex as the extender needs to track these marks dynamically. When a bundle starts, it needs to look at the mark. Then a bundle leave, the extender must release all object created from this bundle.
This handler tracks bundle for you based on the specified required mark. At each time a matching bundle appears or disappears, a callback is invoked. The mark is currently a header in the bundle manifest.
Nowadays, a lot of frameworks use this pattern such as iPOJO it-self (to find both bundles containing components and bundles adding a new implementation type), Spring-DM ...

h2. Using the handler
First of all, you need to configure the component type to use the handler such as:
{code:xml}
<iPOJO xmlns:extender="org.apache.felix.ipojo.extender">
	<component
		classname="org.apache.felix.ipojo.extender.myextenderMyExtender">
		
                <!-- Extender Pattern handler configuration -->
		<extender:extender 
                  extension="My-Extension"
                  onArrival="onBundleArrival" 
                  onDeparture="onBundleDeparture" 
                />

		<callback transition="invalidate" method="stopping" />
		<callback transition="validate" method="starting" />
		<provides />
	</component>
</iPOJO>
{code}
Notice ipojo>

Notice that,

...

this

...

handler

...

is

...

an

...

external

...

handler.

...

So,

...

it

...

uses

...

the

...

"org.apache.felix.ipojo.extender" namespace.
You can also use annotations:

Code Block

@Component
@Extender(
	onArrival="onBundleArrival",
	onDeparture="onBundleDeparture",
	extension="My-Extension")
public class MyExtender {

	@Validate
	public void starting() {
	  // ...
	}
	
	@Invalidate
	public void stopping {
	  // ...
	}

	void onBundleArrival(Bundle bundle, String header) {
	         // Do something
	}

	void onBundleDeparture(Bundle bundle) {
	        // Do something
	}
}

The methods specified methods will be called when a matching bundle arrives or leaves.
In the previous example, these methods could be:

Code Block
 namespace.
Once described, you can implement your component. The methods specified methods will be called when a matching bundle arrives or leaves.
In the previous example, these methods could be: 
{code}
void onBundleArrival(Bundle bundle, String header) {
         // Do something
}

void onBundleDeparture(Bundle bundle) {
        // Do something
}
{code}

Notice

...

the

...

different

...

signatures

...

of

...

the

...

methods.

...

The

...

arrival

...

method

...

is

...

called

...

with

...

the

...

arriving

...

bundle

...

and

...

the

...

matching

...

header

...

value

...

(i.e.

...

the

...

value

...

of

...

the

...

My-Extension

...

header

...

of

...

the

...

bundle

...

manifest).

...

The

...

departure

...

method

...

just

...

receives

...

the

...

leaving

...

bundle.

...

Configuration

The handler has only three mandatory attributes:

  • Extension: declaring the looked manifest header.
  • onArrival: declaring the method to invoke when a matching bundle arrives
  • onDeparture: declaring the method to invoke when a matching bundle leaves

HTML

<div class="box">
	<div class="box-yellow-header">
	<div class="box-yellow-title">
		<img src="http://people.apache.org/~clement/ipojo/site/warning.gif"> <b>Called despite being invalid</b>
	</div>
	</div>
	<div class="box-yellow-content">
		The implementation will be notified of arrivals and departures despite the instance is invalid. Indeed, the implementation must release all objects created from another bundle as soon it leaves.
	</div>
	<div class="box-yellow-footer"></div>
</div>

...

Download

The handler is available on the download page.
Sources are available on the Felix trunk at the following location: http://svn.apache.org/repos/asf/felix/trunk/ipojo/handler/extender/

...

Configuring the handler with annotations

It is possible to configure the handler with a simple annotation available in the annotation pack ('annotation'

...

project

...

in

...

the

...

iPOJO

...

trunk).

...

Here

...

is

...

an

...

example

...

of

...

usage:

Code Block
java
java

{code:java}
import org.apache.felix.ipojo.annotations.Component;
import org.osgi.framework.Bundle;

@Component
@org.apache.felix.ipojo.extender.Extender(extension="foo", onArrival="onArrival", onDeparture="onDeparture")
public class Extender {
    
    public void onArrival(Bundle bundle, String foo) {
        // do something
    }
    
    public void onDeparture(Bundle bundle) {
        // do something
    }
}
{code}

The {{extension}} attribute allows setting the bundle filter.


h2. A more realistic example
The Junit4OSGi framework, available [here|https://svn.apache.org/repos/asf/felix/trunk/ipojo/examples/junit4osgi] , uses this handler to track Junit Test Suite offered by the installed bundles. The Junit4Osgi bundle has a component using this handler to be notified when a bundle with the {{Test-Suite}} header appears or leaves.
\\
\\
{include:

The extension attribute allows setting the bundle filter.

A more realistic example

The Junit4OSGi framework, available here , uses this handler to track Junit Test Suite offered by the installed bundles. The Junit4Osgi bundle has a component using this handler to be notified when a bundle with the Test-Suite header appears or leaves.

Include Page
apache-felix-ipojo-footer
apache-felix-ipojo-footer

...