Service Boss Level: Service Factories
I’ve always wondered how the Apache Sling Logging Logger Configuration worked. I like the idea of being able to configure multiple configuration instances through the OSGi Console and could see how this would cut down on the UI code I’d need to write in many circumstances.
Since working on the Apache Sling project, I have taken the time to peruse the code for the Sling logger. Unfortunately, the Sling logging code uses a fairly arcane method for registering the service. After looking around a bit, I took a look at the code for the Apache Sling Job Queue Configuration, which was much easier to follow.
The Sling Logger Configuration Screen
It turns out creating, factory was easer than I suspected. The solution is to simply add the following attributes to your
That’s it! Once you load the bundle for your component you will see a new component factory on the configuration page with your component label. The form generated will be based on the
@Property annotations on your component class, just like a regular service.
So how do you use the configuration instances from your service factory? Well you could query Felix every time you need the configurations or can use a ServiceTracker which allows you to react to services being registered and update a cache. Probably the easiest option, however would be to set the component to start automatically by adding the
immediate=true attribute to the
@Component annotation and updating a separate configuration cache service in the activate and deactivate methods for your service.
Since these methods will be called when the service is stopped or started including creation and the start/stop of the console, you can keep the cache in sync with any of the changes of the configuration services.
Hopefully this article has helped you see how easy it is to create Sling Service Factories and gives you another tool to enhance the administrative capabilities of the OSGi console and avoid creating configuration pages.