Jan has posted 2 posts at DZone. View Full User Profile

Is OSGi ready for Enterprise yet?

  • submit to reddit

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.

Published at DZone with permission of its author, Jan .

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


Doug Barnum replied on Sat, 2012/01/28 - 7:29pm

We use Pax logging in Apache Servicemix and it's like as you expect in JEE. It comes down to what you actually want to use - we stuck with log4j as we had a ton of code that used it. So why change? Not sure on your Transaction stuff as that isn't a part of our world. Seems to me if you can do it in Spring and Spring bundles are plentiful it should not be a hard thing to figure out.

Ali Yang replied on Sat, 2012/01/28 - 11:56pm

Spring transaction work fine in ServiceMix

Jan replied on Sun, 2012/01/29 - 5:38am in response to: Doug Barnum

Hi Doug,

 ok so Pax logging really looks promising. I will look into that! Yet it does seem rather complicated to change the  logging configuration and supply a custom one.



Harald Wellmann replied on Sun, 2012/01/29 - 5:05pm

Pax Logging is great if you really need an OSGi Log Service. However, it is tied to a log4j logging backend and you can't simply configure it by a log4j.properties file as usual. (A logback backend is under development.)

On the other hand, if you're used to SLF4J anyway, then there's no reason not to use the vanilla SLF4J and logback artifacts in OSGi - the JARs are OSGi bundles (or fragments).

Regarding transactions or enterprise features in general: The OSGi enterprise specifications are fairly new and they still lack a number of features you're used to from Java EE or Spring. E.g. configuration by annotation. I never used to mind the XML config stuff when I was working with OSGi Declarative Services and the Eclipse PDE support for the XML files a few years ago, but once you got used to Java EE 6 annotations, you never really want to bother with XML configuration again (and this includes Spring XML!)...

Sadly, annotation support is completely absent in OSGi Enterprise specs (don't know about current drafts, though).

Have you looked at Eclipse Gemini and Apache Aries? These projects implement some parts of the OSGi enterprise specs. Eclipse Gemini is the successor of Spring Dynamic Modules and uses Spring internally. However, I don't recommend Gemini on the grounds that it forces you to explicitly import packages for proxy support etc - this should be an implementation detail hidden from the user.

Apache Aries is independent of Spring and IMHO has a cleaner architecture, avoiding the import issues of Gemini. The biggest problem with Aries is the release (in)frequency. There's lots of new features in trunk, but the last release is almost a year old.

It's more than half a year since I looked at Gemini and Aries, so what I'm saying may not be quite up to date.

Some of my experiments with Gemini and Aries are here: http://code.google.com/p/osgi-enterprise/

Not very polished and not in tutorial style, but feel free to take a look...

Another option: GlassFish 3.x is a Java EE 6 server fully built on OSGi. You can deploy both OSGi bundles and Java EE WARs or EARs to it and even combine both artifact types in so-called hybrid applications. With this approach, declarative transactions are a no-brainer.


Ant Kutschera replied on Mon, 2012/01/30 - 2:56am

In my experience osgi is something that belongs under the hood. That said, its interesting with Eclipse e4 development, for assembling dependencies through injection. But serverside its (currently) something on which to build servers, not business code. Jboss and glassfish (and possibly websphere?) are built on it, and so it is possible to deploy bundles. But I've yet to find a use case where I really need that. Versioning in osgi is good. But not too compatible with Maven (try creating an automated build for eclipse applications). And java 8 is only going to confuse it all by introducing its own versioning concept... My 2 cents: shoot the kid who got over excited building you app with his new toy and stick to what is known to work.

Andreas Schilling replied on Mon, 2012/01/30 - 3:03am

Actually we've built one of our (Eclipse RCP-)applications on top of OSGi using Spring Dynamic Modules and it worked like a charm. Not sure whether you tried that way, but having all the stuff we know and love from Spring is there :-) Especially declarative transactions, what btw. was also one of our crucial requirements we wanted to have before we started implementing. Logging is done with pax logging. Took some time to configure and make it run with the JNLP deployment we unfortunately have to use on customer side, but after that also works just fine.

So, for us OSGi is totally ready for the enterprise. Spring DM just plugs in fine and also integrating our company's own base library which builds upon OSGi but not on Spring or any other DI framework was no problem at all.

Jan replied on Mon, 2012/01/30 - 3:19am in response to: Andreas Schilling

Hi Andreas,

 using Spring DM is also my favorite approach at the moment. Yet I probably will start on Eclipse Gemini rightaway. Do you have sample projects how you got started?



Andreas Schilling replied on Mon, 2012/01/30 - 8:34am

unfortunately we didn't really have examples, but maybe in the end it was also better that way. we kind of built or own. we had an old project lying around which an intern once did (very small datamodel with 3 tables and a minimalistic UI) and transformed that to use Spring DM, transactions, OSGi services and all that. that worked fine as it took us less than one week to get that done and building a real application then in the end just meant having more bundles, more services, more beans and stuff.

doing it that way is something we probably will do also for future projects. it's really good to build the basics once from scratch to get a feeling for how to approach finding a structure and very rough base architecture. I think one of the strengths of Spring DM/OSGi based applications is, that you are encouraged to have more bundles and thus a better structure. therefore we also threw away that prototype and built the real application's bundle structure again from scratch. your boss won't like that, but you and your customer will :-)

Charlie Mordant replied on Thu, 2012/02/02 - 6:55am



You can easily plug slf4j and logback + logging conf fragment in an OSGI environment, just take a look at springsource ebr to find the jars.


For the transaction stuff, I know two osgi compliant frameworks: Atomikos that goes well with Spring (I tested it), and Apache Aries wich is an osgi jta spec implementation.

IMO blueprint spec (spring-dm was the initiator) is a good service injection resolver, you also have spi-fly (look at Aries on how it works).



Caspar MacRae replied on Tue, 2012/02/07 - 11:17am


Erm, is it just me or does this post in no way relate to either of the titles;  "Is OSGi ready for Enterprise yet?" and subtitle "How to propertly handle logging and transactions in an OSGi enterprise app"

This is just an account of how the author inherited a very badly written app (just so happens it was OSGi) and then did zero research on the topic (iPOJO reference card?  So if it doesn't fit on cheat sheet it doesn't exist?).

Google "OSGi logging" and pax is the 2nd result in the list, look at some (successful) projects using OSGi and you'll find PaxLogging, or even ask on stackoverflow and again it'll be PaxLogging.

Transaction-wise look at Apache Aries, Eclipse Gemini (both Blueprint and very Spring-like).

Sorry to be a troll, but I believe my criticism is objective and warranted  - the title and content are a complete mismatch; consider sending code sample to the DailyWTF instead.

Comment viewing options

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