OSGi & Servlets: Flexibility by Simplicity

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) {
         e.printStackTrace();
       } catch (NamespaceException e) {
         e.printStackTrace();
       }
     }
   
     protected void shutdown() {
       httpService.unregister(SERVLET_ALIAS);
     }
   }
   

   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"?>
   <scr:component
     xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"
     activate="startup"
     deactivate="shutdown"
     name="simple.ds.component">
     <implementation
       class="simple.ds.servlet.SimpleComponent"/>
     <reference
       bind="setHttpService"
       interface="org.osgi.service.http.HttpService"/>
   </scr:component>
   

   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.

From http://www.peterfriese.de/osgi-servlets-flexibility-by-simplicity/