Over a million developers have joined DZone.
Platinum Partner

Annotations for OSGi Declarative Services

· Java Zone

The Java Zone is brought to you in partnership with ZeroTurnaround. Discover how you can skip the build and redeploy process by using JRebel by ZeroTurnaround.

Recently I took a deeper look at OSGi Declarative Services (DS), Spring Dynamic Modules, iPOJO and Peaberry. I have to admit that I like DS a lot (and even more in the upcoming OSGi 4.2 spec). But one thing I particularly liked about iPOJO was the possibility to either use XML or Java annotations. So, just for fun, I wrote a little Java 6 annotation processor for DS. The benefits I see are:

  • Easier to use: Most Java programmers are familiar using annotations but probably don’t want to deal with XML
  • Better refactoring support: The annotation processor takes care of it, like the renaming of bind/unbind methods
  • Annotations know about the attributes of a class/method etc. and can make assumptions about the intention of the developer

I would like to give you an example. Let’s consider a simple use case: We have a Java POJO (TestComponent) that wants to be a DS Service component, provides two service interfaces (ITestServer, ITestService2) and depends on another service (ITestReference). The corresponding Java class looks like this:


The corresponding XML for DS looks like this:

If you use Eclipse 3.5M5 you could easily edit this file using the new Service Component Editor, but with annotations you could create it automatically from a Java source. In my prototype I have created annotations for components and bindings. The annotated source code looks like this:

Using this file as input, my annotation processor generates exactly the above XML file. Let’s explain the above code a bit. The annotation processor knows about the class and the interfaces the class implements. From the fully qualified class name, both the component name and the implementation class are derived. Another convenience is: if no services interfaces are stated explicitly, the processor assumes that all implemented interfaces are supposed to be services this component want to provide. I took this idea from iPOJO since I like it a lot and I guess this is a very common scenario. The bind annotation interprets the method’s parameter to be a service reference. In my prototype I just put the cardinality “1..1″ and the policy “dynamic” as default values for the corresponding attributes of the annotation.

To use my annotation processor in Eclipse, I just had to extend the extension point org.eclipse.jdt.apt.core.annotationProcessorFactory and deploy my plug-in to the dropins folder of my current Eclipse IDE. If I want to use these annotations in a Java 6 project, I just have to enable the Java Compiler/Annotation Processing properties of that project and add my processor. Now, after every save of any Java file in that project, the annotations are processed and the XML files for DS are generated.

Before I continue the put more effort in this I would appreciate feedback from the community. So, please let me know if you would find this useful (and let me also know if you find this completely stupid :) )

If someone would be interested in seeing the sources for the annotation processor, I could publish them shortly after a bit cleanup.

Have Fun!

From http://www.toedter.com/blog

The Java Zone is brought to you in partnership with ZeroTurnaround. Discover how you can skip the build and redeploy process by using JRebel by ZeroTurnaround.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}