...

Spell Checker Sample

This section presents a quick overview of the capabilities and usage of the DependencyManager java 5 annotations. In particular, we will recap the DependencyManager annotation architecture, and identify some  simple usage scenarios using a SpellChecker sample application with annotated components (the application is available from the felix trunk, in the dependencymanager/samples.annotation maven subproject).

...

Instead of writing Activators which extends the DependencyActivatorBase class, service components can now be annotated using the annotations provided by the org.apache.felix.dependencymanager.annotation bundle. Annotations are not reflectively parsed at runtime; but we use a BND plugin which scans annotations at compilation phase and generates a compact metadata file in the bundle's OSGIMETA-INF/dependencymanager subdirectory. This has the following benefits:

• JVM startup speed is not affected, and class files are not parsed when the framework is starting
• Moreover, since the annotations are not retained by the VM at runtime, it is not necessary to load the annotation API bundle at runtime.

At runtime, the metada metadata generated during the compilation phase are processed by a specific DependencyManager Runtime bundle, which is in charge of managing the service component lifecycle and dependencies. This Runtime bundle actually uses the DependencyManager programmatic API in order to manage the annotated components. Annotated components can then be inspected with the DependencyManager Gogo shell, as it is the case with DM components declared through the programmatic DM API.

...

To illustrate this, we are now introducing a SpellChecker application which provides a Felix "spellcheck" Gogo shell command. Gogo is the new shell supported by the Felix Framework. Our "spellcheck" command is implemented by the SpellChecker component which accepts a string as parameter. This string is then checked for proper existence. To do the checking, The SpellChecker class has a required/multiple (1..N) dependency over every available DictionaryService services. Such DictionaryService represents a real dictionary for a given langage language (it has a lang service property), and is configurable/instantiable from Configuration Admin.

...

@FactoryConfigurationAdapterService(factoryPid="DictionaryServiceFactoryDictionaryImplFactoryPid", updated="updated")  
public class DictionaryImpl implements DictionaryService {
    /**
     * We store all configured words in a thread-safe data structure, because ConfigAdmin
     * may invoke our updated method at any time.
     */
    private CopyOnWriteArrayList<String> m_words = new CopyOnWriteArrayList<String>();

    /**
     * Our Dictionary language.
     */
    private String m_lang;

    /**
     * Our service will be initialized from ConfigAdmin, and we also handle updates in this method.
     * @param config The configuration where we'll lookup our words list (key="words").
     */
    protected void updated(Dictionary<String, ?> config) {
        m_lang = (String) config.get("lang");
        m_words.clear();
        String[] words = (String[]) config.get("words");
        for (String word : words) {
            m_words.add(word);
        }
    }
           
    /**
     * Check if a word exists if the list of words we have been configured from ConfigAdmin/WebConsole.
     */
    public boolean checkWord(String word) {
        return m_words.contains(word);
    }
}

Our DictionaryImpl class implements a DictionaryService, and our class will be registered under that interface (all directly implemented interfaces are used when registering the service, but you can select some others using the provides attribute). The @FactoryConfigurationAdapterService annotation will instantiate our service for each configuration created from web console (and matching our "DictionaryServiceFactoryDictionaryImplFactoryPid" factoryPid).

We also use the updated attribute, which specifies a callback method which will handle properties configured by ConfigAdmin. The updated callback will also be called when our properties are changing. Every properties are propagated to our service properties, unless the properties starting with a dot ("."). Configuration properties starting with a dot (".") are considered private and are not propagated.

...

  @FactoryConfigurationAdapterService(factoryPid="DictionaryServiceFactoryDictionaryImplFactoryPid",
    propagate=true,
    updated="updated",
    heading="Dictionary Services",
    description="Declare here some Dictionary instances, allowing to instantiates some DictionaryService services for a given dictionary language",
    metadata={
        @PropertyMetaData(
            heading="Dictionary Language",
            description="Declare here the language supported by this dictionary. " +
                "This property will be propagated with the Dictionary Service properties.",
            defaults={"en"},
            id="lang",
            cardinality=0),
        @PropertyMetaData(
            heading="Dictionary words",
            description="Declare here the list of words supported by this dictionary.",
            defaults={"hello", "world"},
            id="words",
            cardinality=Integer.MAX_VALUE)
    }
)  
public class DictionaryImpl implements DictionaryService {
    ... code same as before
}

...