Peter Friese is a software engineer with 15+ years hands-on experience in software development, technical writing and public speaking. Peter works as a software engineering consultant at Zühlke Engineering. Having worked on a host of industry projects in diverse domains and being an active committer on a number of open source projects, he has in-depth knowledge in a broad range of technologies. His main areas of expertise are model-driven software development, cross-platform mobile development (iPhone, Android, Windows Phone 7, and mobile web) and Eclipse tooling. Peter blogs at and tweets at @peterfriese. Peter is a DZone MVB and is not an employee of DZone and has posted 29 posts at DZone. View Full User Profile

OSGi & Servlets: Flexibility by Simplicity

  • submit to reddit

Strangely enough, simple things tend to be more flexible than complex things. I bet you too have seen people go to great lengths to ensure a certain solution provides utmost flexibility. Often, this flexibility isn't needed, so you're introducing accidental complexity.

In a recent post, I showed you how to create a plain servlet and register it in an OSGi environment. As both Jeff and Scott pointed out, my using a ServiceTracker to register and unregister the servlet is a little bit clumsy and can be improved by using Declarative Services.

I highly recommend reading chapter 15 in "OSGi and Equinox", but in a nutshell Declarative Services allow you to define components which can provide and consume services. Binding and unbinding references between components and services is performed by the DS runtime (also known as the Service Component Runtime).

Without further ado, here are the changes I had to make to DS-ify my simple servlet:

  1. Remove the activator. Yes, that's true: we don't need an Activator any more. Delete the class and also remove it from META-INF/MANIFEST.MF
  2. Delete HttpServiceTracker. Registering the servlet with the HTTPService will be handled by the DS runtime.
  3. Implement a component to register and unregister the servlet with the HttpService:
    public class SimpleComponent {
    private static final String SERVLET_ALIAS = "/hellods";
    private HttpService httpService;

    public void setHttpService(HttpService httpService) {
    this.httpService = httpService;

    protected void startup() {
    try {
    System.out.println("Staring up sevlet at " + SERVLET_ALIAS);
    SimpleServlet servlet = new SimpleServlet();
    httpService.registerServlet(SERVLET_ALIAS, servlet, null, null);
    } catch (ServletException e) {
    } catch (NamespaceException e) {

    protected void shutdown() {

    As you can see, the HttpService will be injected into this component using it's setter method, setHttpService.

  4. Register this component with the DS runtime by adding a component description:
    <?xml version="1.0" encoding="UTF-8"?>

    I saved this file in OSGI-INF/component.xml and added it to the Service-Component section of META-INF/MANIFEST.MF. In fact, as I used the Create New OSGi Component wizard, the wizard added the entry to the ServiceComponent section - it's really easy to forget this if you do it manually!

That's it!

Please note that I did not change the servlet implementation at all (apart form issuing a different text to make it easier to tell the servlets apart)!

Before launching, please make sure to add org.eclipse.equinox.ds and org.eclipse.equinox.util to your launch config to enable Declarative Services.

The biggest advantage of this approach is that you do not have to take care of acquiring the HTTPService. The DS runtime will only activate your component when all prerequisites have been met, i.e., all dependencies are available. If the HttpService is not available for any reason, your component will not be started. This makes the code for registering the servlet simpler and cleaner.

You can download the source for the DS-ified servlet from my SVN repository on Google Code.



Published at DZone with permission of Peter Friese, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Jacek Furmankiewicz replied on Tue, 2010/04/27 - 9:08pm

Any chance this could be accomplished without that blob of XML? Reminds of all the things in J2EE and Spring (prior to @Autowired) that we wanted to get away from.

Are there any plans in the OSGi world to avoid XML and just scan for annotated components?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.