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 (ITestService, 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 wants 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.
This Post Has 19 Comments
For me, one of the attractions of DS is the ability to provide/use services without a dependency on additional org.osgi classes etc. For that reason, while I think this is cool, I think I’d continue to use the javadoc based serviceComponent.xml generation provided by the felix maven-scr-plugin
Good point! OSGi annotations like these are only useful if you target a Java 5 or 6 environment anyway. But these annotations are only needed at compile time so there would be no technical need to have a runtime dependency. But I did not find a solution for this issue yet.
Thanx Tom, you saved my day 🙂
I’ve used the service frameworks iPojo, DS and Spring DM, but I can’t comment on Peabody. I favor the DS for several reasons, the first being the standardization within OSGi. The second being the tooling that is coming with Eclipse 3.5. Kai you’ve provided me with a third!
Kai, that’s great stuff! BTW, if you annotate the annotation with @Retention(RetentionPolicy.SOURCE) the annotations should be discarded by the compiler and not appear in the generated byte code.
great idea 🙂
…think I can test it next week
that’s exactly what I was testing before I went home today 🙂 I will keep you posted.
I really like this idea. Especially because I have to use the 3.4 release and therefore have to live without the Service Component Editor.
I’m looking forward to give it a try.
Interesting, perhaps you could open an RFP to standardize these annotations in OSGi, then iPOJO and other frameworks could share them. Kind of like the AOP Alliance types used in various DI frameworks.
This is exactly what I’m missing in the current DS implementation. Would be nice to have the thing as ant plug-in. 🙂
Having all the information in one file (the java source file) is much simpler to manage
than the current way using component.xml.
Although the new service component editor is a big help to find problems, you still have to keep at least two files in sync.
Hehehe… I just did something like this the other day. Mine looks like
This generates a separate component.xml for each service class.
The problem is that if you have more than one service class, updating the manifest.mf gets wonky.
If you’re doing a full build, the annotation processor knows about all the services and can properly set up the Service-Component header in the manifest.
If you’re doing an incremental build, it only knows about the classes that require rebuild…
I could have it add to Service-Component if it doesn’t exist, but then there’s no good way to remove obsolete entries.
If you’re interested in seeing what I’ve got, please email me: firstname.lastname@example.org
Does the AP also modify the MANIFEST.MF?
Not yet, but it could. Currently you have to specify the header manually in the MANIFEST.MF:
This leads to the loading of all xml files in the OSGI-INF directory
I wrote a Wiki page with instructions how to browse and test the examples, see http://max-server.myftp.org/trac/pm/wiki/a4ds
I like this idea, very very nifty feature. To be honest, the XML way to declare services looks like a small step ahead if you compare it with the annotations way. I definitively give support to this idea and I hope to see it included in the specs very soon.
Pingback: 3 variations on OSGi themes: part 5 « CodingAndBeyond
Pingback: 3 variations on OSGi themes « CodingAndBeyond
Pingback: 3 variations on OSGi themes: part 8 « CodingAndBeyond