Over a million developers have joined DZone.

Is OSGi ready for Enterprise yet?

DZone's Guide to

Is OSGi ready for Enterprise yet?

· Java Zone ·
Free Resource

"I love writing authentication and authorization code." ~ No Developer Ever. Try Okta Instead.

OSGi and enterprise computing, no problem - is there? Being a Spring enthusiast used to plain old Spring and JEE projects I recently took over a project based on OSGi. The scope of the project was to build the future enterprise platform based on OSGi. So as it was my first real OSGi project I was very eager to learn how to finally build modular and dynamic enterprise applications in Java. And I was so happy that from now on I would not have to worry about some application server using a different version of commons-lang than my current project!

Having a first view over the source code I had to discover that there was a lot of ugly hand written boilerplate code. Among these I picked the two most important ones for you:

  • a custom logging implementation
  • boilerplate code to handle transactions manually

I was shocked! Ok so I thought someone must not have understood how to do these things properly. All of  these problems have been very successfully adressed for plain old enterprise applications. My favorite stack for these problems is logging using sl4j, RESTful services with apache cxf, Spring data JPA for all DAOs and declarative Spring transactions to top it off.

 So having my favorite stack in the back of my head I tried to find a way to get all of that working in OSGi as in plain old enterprise apps. If you can help me out – I am still looking! Here are my first insights in how all above things can be done using OSGi:

The logging implementation

 The schoolbook of OSGi tells you that logging is done via the OSGi LogService. Yet this ties your jar files to the OSGi framework only because of some log statements. I don't see that's worth it! Besides the API of the LogService is very ugly. Then I thought someone must have written a SL4J binding for OSGi! Unfortunately that is not the case. So now I can either stick with the hand coded logging implementation based on log4j, switch to the OSGi LogService or let all of that be damned and go on using my favorite logging implementation just like before. Either way the problem of logging has not at all become easiery but even worse as the OSGi has added another logging API. So right now this small enterprise application needs to basically support all major logging frameworks and the OSGi LogService. The worst thing about that is that OSGi happily allows all of these logging implementation to live in the same container, so I can't even make them all use the same logging mechanism.

Handling transactions

Getting transactions right is crucial no doubt about that. And getting it right in manually written boilerplate code is most probably not a good solution. So in plain old enterprise apps I suggest using a framework that knows well how to handle transactions like Spring or EJBs. But what about OSGi? So yes there is an OSGi TransactionService. Of course that can be used to manually handle transactions. But then again we have tied ourselves to the OSGi framework and are still handling transactions manually. Then I started looking for ways to use Spring transactions in OSGi. That turns out not to be easy. Spring transactions heavily rely on bytecode manipulation which does not work the same way in the OSGi container. So believing the talk Transactional OSGi applications done right the way to go is iPOJO transactions. When I was looking for some documentation on that I was surprised not to find anything about transactions on the iPOJO documentation or reference card. So either that feature is well hidden or not well tested. Handling transactions in iPOJO requires integrating it in the build and in the IDE as iPOJO needs to manipulate bundles during build time (as it is not allowed to manipulate the bytecode). I am not really sure whether I want to do that.


I figured out that whoever came up with a custom logging implementation and manual transaction handling did actually know what he was doing. Both of these issues are not easily solved in OSGi and doing it that way is absolutely reasonable. Yet coming from outside the OSGi world it feels kind of strange to worry about these things again. Maybe someone can enlighten me on how to do these things right! And I have more topics on my mind that need to be addressed in OSGi like web services and JPA integration but more about that another time.

"I love writing authentication and authorization code." ~ No Developer Ever. Try Okta Instead.


Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}