Committer Status on Apache Sling

I woke up this morning to the fantastic news that I’ve been offered committer status on Apache Sling! I graciously and excitedly accepted the opportunity to become an Apache committer.
The various points of processing are in motion, so expect to see more Sling posts from me as I get ramped up into being a more productive member of Apache Sling.


Basics of OSGi and Declarative Services

This is a slide deck for a talk I gave at the Sakai 2010 conference in lovely Denver, Colorado. The title to the talk was “Using OSGi in Nakamura” which was my original intention, but after reviewing the slides I seemed to have given a talk about the basics of OSGi. Good information under a wrong marquee.

No matter the intention, I found today that I needed to refer to the slides for setting up an activator, so I’m reposting it here to give myself and hopefully others faster access. Be on the lookout for a repeat performance of this presentation at the Sakai 2011 conference in Los Angeles. I might even try to show it around a bit once the European conference is announced.

When To Immediately Activate An OSGi Component

OSGi has a fantastic feature for immediate components [1] and delayed components [2]. This allows components to delay their possibly expensive activation until the component is first accessed. At the very least it allows the OSGi platform to consume resources as needed. No sense is sucking up those server resources for something that can wait.

As developers start their adventure into OSGi, I’ve noticed a pattern creeping up that I’m not sure folks are aware of: just because you like your component doesn’t mean it needs to start immediately. Unless your component has something it needs to do before other components can do their work, there’s little need to start a component immediately. A lot of times, the work can be moved into the bundle activator or is fine being delayed.

People often see that a component does something in its activation method and assume it should start immediately. The questions to ask yourself are:

  • Will the things that need to use this component have a reference to it?
    Yes? Delayed activation.
  • Before activation, will functionality be missing that should be available as soon as possible?
    Yes? Immediate activation.
  • Can something else do the job of activating the component at a later time?
    Yes? Delayed activation.

Registering with an external service, such as JMS, is a perfect scenario for an immediate component. If the JMS service were in OSGi, declarative services could do the work of making sure service trackers know your component exists, but OSGi has no jurisdiction over external resources. Binding to a JMS topic requires manual interaction and therefore should happen by way of immediate component activation.

Getting and setting of properties is not a case for immediate component activation. Neither is because the service is referenced by something else.

When using declarative services, a reference to your not-yet-started component will be given to anything that has said it wants to collect an interface you implement. This requires no effort on the part of the service being referenced and thusly does not require the referenced service to be activated immediately. Fret not! On first access of this service by any consumer the service will get activated.

OSGi has not been the fastest thing for me to learn but understanding the nuances of little things like this really helps me understand why it is a good approach at decoupled services and modular software construction.

1. OSGi compendium spec version 4.2, section 112.2.2
2. OSGi compendium spec version 4.2, section 112.2.3