OSGi: The Gravity ServiceBinder

[Joachim Draeger <jd...@joachim-draeger.de>]

Hi!

One target of OSGi is dynamically use and offer Services. Ideally
bundles do react on events like other services are started/stopped.

Doing the first steps it did remind me quite much to the Avalon
ServiceManager.
When the start method of your bundle Activator is called you have to
lookup your needed services yourself. You even have to register the
services you are offering.
Of course you have to deregister everything in the stop method. 
Much code and not very POJO like.

Doing everything in Activator start() and stop() makes your bundle quite
static. It can not react to the lifecycle of the services it uses. If a
needed service is not available at start, starting will fail.

To be more dynamic you can implement a ServiceListener so you will be
notified and you are able to react. But that produces even more ugly
code!
Using a ServiceTracker like described in the Knopflerfish tutorial does
not bring much relief. 

Then I tried the Gravity ServiceBinder
http://gravity.sourceforge.net/servicebinder/ and found things as I
expected them. :-) 
It is really well documented. Have a look at
http://gravity.sourceforge.net/servicebinder/servicebinder-index.html
(BTW Richard Hall is involved at Felix)

It was really impressive. I removed all that service listener code. Just

public class Activator extends GenericActivator {
}

And a simple xml like this:

<bundle>
  <component class="org.simpleclient.impl.ServiceImpl">
    <provides service="org.simpleclient.SimpleClientServiceA"/>
    <requires
        service="org.simpleservice.SimpleService"
        filter="(version=*)"
        cardinality="1..n"
        policy="static"
        bind-method="setServiceReference"
        unbind-method="unsetServiceReference"
    />
  </component>
</bundle>

It's a bit like the Avalon xinfo block but it works automatically. 
You use a class like this: 

public class ServiceImpl() implements Lifecylce {

  public void activate() { 
//  All static dependencies are fulfilled;
//  do what ever you like;  
  }

  public void deactivate() { 
// bundle has been stopped or a required  service is going to be  
// removed; 
// stop everything;
  }

  public void setServiceReference(..) {..}
  public void unsetServiceReference(..) {..}
}

Note that unsetServiceReference is only called after deactivate() has
finished.
As far as I can say it now this could replace well assembly.xml, xinfo
and Serviceable. 
Now I hope for something like this for configuration.

Joachim



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org