Saturday, April 21, 2007

The Simplest Thing That Could Possibly Work

Motivated by a recent thread on the osgi-dev mailing list, here's the infamous Buns 'n Wieners example of building an OSGi service-oriented bundle activator using SAT.

This is a good showcase for SAT since it demonstrates the simplicity of building a bundle that imports multiple dynamic services as a prerequisite to exporting a service.

public class Activator extends BaseBundleActivator {
private HotdogVendor vendorService;
public Activator() {
vendorService= new HotdogVendor();
protected String[] getImportedServiceNames() {
return new String[] {
protected void activate() {
System.out.println("Hotdog Vendor has been activated");
BunService bunService = getBunService();
WienerService wienerService = getWienerService();
vendorService.bind(bunService, wienerService);
addExportedService(VendorService.SERVICE_NAME, vendorService, null);
protected void deactivate() {
System.out.println("Hotdog Vendor has been deactivated");
private BunService getBunService() {
return (BunService) getImportedService(BunService.SERVICE_NAME);
private WienerService getWienerService() {
return (WienerService) getImportedService(WienerService.SERVICE_NAME);

  • The method getImportedServiceNames() returns the names of the imported services. The SERVICE_NAME field is the fully qualified name of the service interface and is an SAT convention.

  • The methods getBunService() and getWienerService() are helper methods; another SAT convention.

  • The activate() method is a hook method that only gets called when all the bundle's imported services have been acquired. When called from the activate() method, the getBunService() and getWienerService() method are guaranteed to not return null.

  • The deactivate() method is a hook method that only gets called when the bundle loses one of its imported services.

  • The use of a bind method in activate() and an unbind method in deactivate() is another SAT convention that simplifies the binding and unbinding of imported services. It would be equally valid to call setter methods instead.

  • The methods activate() and deactivate() are a pair and will get called multiple times during the lifetime of the bundle as its imported services change.

Historically this has always been the first example used to teach SAT since everyone understand that you're not selling hotdogs without both buns and wieners!

Credit for this example goes squarely to Paul Vanderlei, my colleague and buddy at IBM. Paul has been involved with SAT from the very start while developing it at OTI and later at IBM. Paul is the first person to tell me when "it's too hard for the caveman". Much of SAT's simplicity is thanks to Paul and his alter-ego, the caveman, who has existed long before the Geico ad campaign.

To learn more about SAT, check out the introductory tutorial.

Monday, April 2, 2007

Implementing Equinox's CommandProvider to Extend the Console

The Equinox console can be extended by any bundle that registers a CommandProvider service. SAT now includes such a bundle that adds the following commands to the console:

---SAT Bundle Dependencies---
  depend <id> - show dependents the specified bundle
  dependall <id> - show all dependents of the specified bundle
  prereq <id> - show prerequisites of the specified bundle
  prereqall <id> - show all prerequisites of the specified bundle
---SAT Logging---
  loglevel {(debug|info|warning|error)} - query and control log level
  trace {(on|off)} - query and control tracing

The bundle is called org.eclipse.soda.sat.equinox.console.cmdprov, and is optional and specific to the Equinox console.

Chris Aniszczyk has a good article on developerWorks titled "Explore Eclipse's OSGi console".

Planet Eclipse

Jazz Community News