OSGi? No Thanks

November 9 2010


There have been bubbles of interest about in the Java community over recent years. I for one was very excited about the advent of a modular Java platform that freed us from the classloader issues in the JDK manifested best by Jakarta commons-logging (clogging our app servers).

OSGi was going to change everything, dependencies would be completely isolated (no more tripping over conflicting dependency versions), visibility and would be strictly enforced between each ‘bundle’. I was so bought into the promise of OSGi, like many others, I focused our engineering team on making Mule OSGi-enabled.

After months of our team wrangling with manifests, packaging our own bundles and endless fiddling with our build, the benefits of OSGi started to dwindle. ‘No pain no gain’ we thought, but then we hit our roadblock. How do we hide the complexities of OSGi from our users?

Great for Vendors

OSGi is a great specification for middleware vendors, but a terrible specification for the end user. This is because OSGi was never build for application developer consumption. Its roots lie in set-top boxes that needed to have software updates deployed to them remotely without any user intervention. It is a great specification for this type of software deployment since only the vendors needed to deal with deploying bundles.

Middleware vendors have jumped on OSGi because, frankly its right up our street. It promises to modularize software stacks and enable plug n’ play of your middleware infrastructure. Unfortunately, not even these promises are easily delivered with some bundles not working the same way across different containers.

Developer Burden

As if developers didn’t have enough to think about, OSGi adds another complexity to building applications. Furthermore, the promise of bundles working cross-container doesn’t always work, making re-use more painful too. Every developer-focused blog around-OSGi tends to be complex and steeped with technical detail that demonstrates that OSGi just isn’t ready for the developer yet. A technology like OSGi should almost be completely invisibile to a developer. The requirement on the developer should be to define an application in terms of modules but without the need to mess with manifest, bundles and build systems.


The fundamental principles of OSGi are rock solid and we definitely need modularization on the JVM in order for it to flourish in its new defacto role of the polyglot platform. I think OSGi has potential but the user interaction part of it needs to be re-thought now that OSGi is being targeted at regular application development.

When we designed the hot deployment model for Mule 3, we took a lot of cues from OSGi (and avoided the pitfalls of the JEE classloader model). If the next revision of the OSGi specification made it easier for developers to work with OSGi bundles (maybe relying more on convention over configuration) the Mule team would be very happy to re-investigate. As it stands modularization and hot deployment is very possible on the JVM without OSGi and the pain of day-to-day development with OSGi out-weighs its benefits.

Follow: @rossmason, @mulesoft

We'd love to hear your opinion on this post

44 Responses to “OSGi? No Thanks”

  1. Hi Ross. These are discouraging words and it’s a real shame that you and your development team didn’t find what you were looking for. For example tools like bnd do already make OSGi nearly invisible to the developer. The problem right now, I believe, is that the choice of alternative approaches and tools for developing on OSGi is overwhelming and it’s difficult to sort the wheat from the chaff. And you have obviously found yourselves eating a lot of chaff.

    Nevertheless I remain convinced that the pain of day-to-day JVM development *without* OSGi out-weighs any of the short-term benefits.

  2. Hi Neil, While I do think that the JVM needs a module system, the focus for OSGi has traditionally been on embedded systems and doesn’t fit the developer model. Anecdotally, I have heard many passing comments about the complexity that OSGi introduces to their dev team is disruptive and the results haven’t been worth the effort. Lets not forget the Spring bet the farm on dm Server and finally gave it up, this is another indication that the model is not right for OSGi yet.

  3. Well said, though the OSGi thought police have noted your dissidence and will shortly be pointing out how it’s your ignorance that is to blame, since everyone knows OSGi is the perfect solution for everything vaguely related to modular Java.

    I’d fire your engineering team, surely if a group of people spent months trying to wrangle OSGi into some semblance of usability and failed, the fault must entirely be their own ignorance and incompetence.

  4. Hi Ross,

    We have also wrestled for months in the past with OSGi-fying our whole stack. We also had to stop work for a while because Hibernate’s class loader wasn’t ready for that sort of thing. I think once you have a good Maven build process in place (leveraging the bnd plugin etc) it gets a lot easier. Testing is also getting easier all the time with STS and IntelliJ supporting OSGi. I would also venture to say that I would only use Spring OSGi bundles at this point as I believe it to be the best combination of technologies.

    …..but I definitely know what you mean by fiddling 😉

  5. I’d love to hear more about how OSGi doesn’t fit the “developer model”, whatever that might be, and how you think that developers should be exposed to the concept of modularity.

    As for complexity, isn’t a large system such as Mule inherently complex? Modularity exposes complexity and allows it to be managed. Shoot the messenger if you like, but that complexity isn’t going to go away on its own.

    I don’t think that dm Server’s failure as a commercial product had anything to do with technology. As you also found, it’s much easier to monetize a product that everybody is already using by packaging it up with some support contracts… hence tc Server and your own Tomcat-based effort (sorry I forget what you call it). The technology itself is still going strong as Eclipse Virgo, and they just had a 2.1 release.

    @Hani: actually nobody thinks OSGi is a perfect solution. It’s the best solution we currently have but it can be improved, particularly in the area of tooling.

  6. @Neil What you and all the other OSGi zealots/advocates don’t quite see is that the issue isn’t tooling or anything on a higher level, that’d just be clever hackery around a broken model. It’d like all the EJB 1/2 advocates saying ‘well nobody creates all that stuff by *hand*! You should use tooling, then it’s easy!’

    While that attitude works for IBM type people (who will merrily charge for versions of eclipse that are broken and 3 years out of date), it’s also what resulted in the Spring/EJB3 mentality (the old Spring, not the ridiculous ‘we’ll spread our cheeks for the highest bidder, even if it is some random virtualisation company).

    Clever classloader hacks aside, OSGi is a good model on a conceptual level, it’d just too hampered by the language not natively supporting it. The reluctance to start over with all that we’ve learned has meant that it’ll always remain an obnoxious unwieldy framework that nobody (that I know of, obviously if all you hang out is OSGi fruits then your experience will differ) honestly enjoys using.

    The real tragedy is that the OSGi nazis have also managed to hijack the attempts at native modular Java support, so that effort will likely also end up being underwhelming at best. At least, that was the case the last time I looked, but that was a while back.

  7. @Hani: I think we’re talking about different levels of tooling. I’m not talking about source code generation or xdoclet-type crap that people were forced to use for EJB 1/2.

    When’s the last time you wrote a .class file by hand? Probably never, you compile it from Java source. The OSGi manifest is the same kind of thing, it should be the output of a compiler-like tool. Dependencies should be defined in some kind of source file. Like, say, Java source, which already has import statements after all. I can even put annotations in my Java source that define which packages are to be exported, what the version of each package is, etc.

    Sounds like OSGi isn’t so hampered by Java language support after all. By the way this isn’t a pipe dream, this is how I develop OSGi bundles right now.

  8. Totally agree with Neil. @Ross, i jumped to your article because this is a common thing i ear while OSGI was first for me like lot of fresh air in coding, thanks to the Maven SCR Plugin of Apache Felix, check it out.

  9. OSGi sounds cool, but I had BAD experiences with it. It’s absolute pain. Perhaps in years to come…

  10. Arguing with Neil about osgi is pointless. His career is completely dependent on it . It’s like trying to convince an oil executive that global warming is true.

    All I can say is it seems like every osgi story has a thread about how it’s too complex. Not worth the effort. Perhaps that’s a sign….

    From my own experience, the probs are: it’s very difficult to write tests. Pure unit testing is hard and you have to wait for the container to start (very slow). Also, the build systems are a nightmare, especially PDE. Trying to use an IDE other than eclipse is quite difficult. Everything is extremely eclipse centric.

    I would argue good coding practices get you modularity for a lot less effort

  11. Ross,

    You should have asked us (Paremus). We’d have sorted you out in a couple of days. We’ve dealt with code bases much large than Mules.

    Ping Mike Francis for our consulting rates 😉

  12. For the record, we _were_ using the maven-bundle-plugin which is based on BND to auto-generate our manifests based on Java imports (http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html). Other than forcing us to clean up our package naming a bit, I think that part was working pretty well.

    The real source of pain, from what I recall, was dealing with all the 3rd party jars used by Mule (over 150 of them in the latest EE release), of which at the time only a handful had been OSGi-fied. That situation might be much better nowdays, as many of those jars have become OSGi-fied at the source over time.

    The classloading issues, such as Hibernate which was mentioned above, and the user deployment story (how do we get the user to package + deploy their app as OSGi without them needing to know about it?) were also sticking points, but things we eventually had to solve for our current hot deployment strategy as well.

  13. @Neil, @Hani – both of you are right, even if it sounds ridiculous. Neil’s point – a greenfield project with a solid team _may_ rip some benefits of OSGi if done right. And only if done right. And we are moving to @Hani’s point – it’s too easy to make mistakes with OSGi for an average Joe. It’s human nature.

    I wish there were only super-talented star teams around, but that’s somewhere in a different universe. E.g. Mule build had used the bnd as part of the process and all the bells and whistles, every module was OSGi enabled. In 2-3 years I remember only 1 mention on the list of anyone trying to use those. That brings us to a point – not every modular app must be modularized via OSGi.

    And the most important part – at the end of the day what matters is the user experience, and mass market will see a much larger share of John Does who don’t know the intricates of Java classloading model (and thus may not always understand why they have to declare various import/export/buddy headers in OSGi manifests).

  14. @Neil: I also wrestled with OSGi. The promise is great, but support in existing packages is almost non-existent. This means it’s tricky to find an OSGified bundle of a package you need (the best shot is the spring repository, but they don’t have the latest versions) plus you’re in bad shape if the package uses non-OSGi class loading. For example, if they use ServiceLoader (e.g., I couldn’t get Jersey to work a year ago).

  15. If you come to OSGi and expect all legacy JARs to work perfectly and still reap all of the benefits of modularity, then you might as well not even try. That’s sort of like switching from C to C++ back in the 1980s and just hoping that everything automatically becomes object oriented.

    Unfortunately, we are still largely at an infancy when it comes to modularity in Java. There is pain when you want to move to OSGi, no doubt about it. For some, the pain is worth it now. For others, they need to wait until more work is done by others to get more stuff working.

    From my point of view, the biggest failing of OSGi is that we have someone convinced people we can get all of the legacy crap working, when in reality it should all be refactored. We are doing evolution instead of revolution, which is death by a thousand cuts rather than one big one. I guess we’ll have to wait for whatever comes after Java.

  16. I blogged about OSGi last year and came to the conclusion that it wasn’t ready for enterprise development, yet. I was hoping for some sudden surge of tooling to ease the pain of configuring manifests, etc, but it doesn’t look like that will happen any time soon. I thought 2010 would be a major year for OSGi and modular Java. I think it’s still a promising technology, but will probably suffocate under its own mass of complexity, at least for average (non-product shop) development teams. I couldn’t imagine introducing the complexities of OSGi to the average developer. The tooling really needs to support automated manifest generation and bundle deployment with a few clicks, until then, it’s just better to watch from the sidelines and wait for Java’s replacement. Hopefully it will have modularity baked in rather than sprinkled on top.

  17. Gosh how I miss the days of “The Bile Blog”…. good hear from Hani again!

  18. @Grope, aside from class loader issues (Hibernate is OSGi’s commons-logging) and ServiceLocator not working, the real issue we faced was we couldn’t hide OSGi from our users. Also remember not everyone uses Maven AFAICT there is not much OSGi support for them.

  19. @Richard, Ah so consulting is the answer to OSGi complexity. I’ll let everyone know 🙂

  20. Wow it’s fun to come back to this thread after a day offline. @Joe Sampson — thanks for comparing me to an oil exec, it’s at least better than being called a Nazi by Hani. For what it’s worth my career is completely dependent on *Java*, but OSGi-related work only accounts for about a third of my earnings at present.

    Not that this is relevant anyway, one might as well say that there is no point having an argument with Ross about Mule. It would be more constructive for you to criticise my arguments than my character or my source of income.

  21. Well said Ross.

    Your experiences echo my own experiences. In it’s current form, I could not recommend moving to OSGi.

    However, I agree with the intentions of what OSGi is trying to achieve. Loose coupling, isolation, modularization, independent life-cycle models of modules are all wonderful concepts.

  22. @Neil You undermine your own stance though by always blaming the user rather than acknowledging that OSGi is not the right solution, or is sup-optimal in some way. If you’re going to be overly defensive about a technology, it’s hardly surprising people will pick up on that and poke at your adopted religion, since it’s sorta fun making fun of religious people (cheap shot I know, but human nature nevertheless!)

    @Richard wow, I never thought I’d see you acknowledge that, so kudos there for giving a much more balanced view of OSGiland.

    Does anyone know of any large public modular application that is unrelated to Eclipse that is built on OSGi? I know the Atlassian folks use it, but they do a great job of hiding the complexity and hacking it up sufficiently so that it works. If anything though, it’s another example of how broken OSGi is, that it requires that much hackery before even allowing mere mortal *developers* to utilise it.

  23. Every new technology have its own learning curve and troublesome until things become standart. It was same for Enterprise Java, web projects, or even midlets. However nobody is complaining on those today. Either you become an early adoptor and face those difficulties or wait until things become standardized and use it afterwards.
    It is a matter of choice and I respect your decision 🙂

  24. Okay, OSGi is not easy, Maven and Ant aren’t easy too, even Java isn’t easy without having great tools like Eclipse or Netbeans. But using OSGi with bundles like fileinstall and ipojo for providing a (quite simple) plugin system is great. Faster builds, immediate deploy.

    Especially with Maven it’s quite hard to getting started, but with Maven everything seems to be hard what has nothing todo with just declaring dependencies. Using Eclipse to build bundles is really easy, as bundles are nothing else than Eclipse plugins with no concrete dependency to Equinox, but only OSGi in general (+bundles).

    I think the biggest problem embedding OSGi in an existing application is not to know the “org.osgi.framework.system.packages.extra” parameter.

  25. A trackback:


    @Hani – ebay are currently running around 400m transactions per *day* through an OSGi based runtime.


  26. We had a LOT of success with OSGi as an application level module framework.

    However, it’s quite amusing that the only problems we ever had were indeed class loader issues. Once you start combining OSGi with other frameworks with classloader quirks (say, Jetty), you’re in for a lot of trouble.

    Other than, OSGi has worked out perfectly. Not hard at all.

  27. OSGi definitely has a steep learning curve, but this is mostly due to general modularization issues, not because of the framework itself. But once you wrapped your head around the basic concepts, it seems natural to write modular software, that doesn’t assume to be the owner of the current JVM process, but interact with the environment via well-defined interfaces and services.

    I’ll give you that debugging is sometimes hard. I just spent a couple of nights to get integration testing running with Gemini Blueprint, Gradle as build tool and Groovy, but now that it works, it’s nice.

    @Hani: LinkedIn is using OSGi as part of their architecture. See the LinkedIn engineering blog for details: http://blog.linkedin.com/category/engineering/feed/

  28. @Hani, not sure if you were referring to me or not, but if so then obviously you don’t know me and do not actually know my position. I have always been against trying to shoehorn in legacy crap. Typically what people see as OSGi complexity is the result of getting non-modular legacy code to work in it. Sort of defeats the purpose of going to OSGi in the first place. Any module system that has to work with all legacy will suffer the same fate. The only way to make a simpler/better solution is by forcing people to abandon non-modular practices. Whether a modularity solution is baked into the JVM or not won’t change that fact.

  29. @Hani: I forgot to add, don’t you consider app servers like GlassFish and WebSphere to be large modular applications? Or are they not “public”?

    I might also echo some of the other comments, that OSGi is actually pretty easy and natural to use (which is what attracted me to it in the first place) if you have a system designed for modularity. And especially if you’ve learned to grow with it. It should come as no surprise to anyone that starting out as an OSGi newbie and trying to tackle moving some huge, complex legacy system to OSGi results in difficulty.

    In the end, it really doesn’t matter to me, which is why I try to avoid these sorts of discussions in the first place. I have long ago given up trying to convince people to like OSGi. Not everyone likes Java, not everyone will like OSGi. I’m fine with that.

  30. I’d like to add more colour to my earlier statement about my experiences with OSGi. The project I was leading was brand new – it was designed to be modular from the ground-up and OSGi (Equinox) was certainly not an after-thought but a key part of the architecture from day 1. The reason we chose OSGi was because we wanted to allow an extensions layer to support custom requirements (delivered via professional services) without disturbing the core functionality (and thus avoiding costly regression tests of the whole product).

    Everything worked great in Eclipse, however the target run-time was not Eclipse – but a headless AIX machine. When we attempted to run the project in it’s target environment, we quickly descended into the seventh layer of class loader hell. We got it working in the end but lost a lot of time and it came close to putting our project at risk. The experience left a bad taste.

  31. I skipped the last comments, my blood pressure does not take flame wars very well, so sorry if I repeat something.

    While I agree that non-OSGi-fied dependencies lead to some fiddling, I actually had an entirely different experience. We used OSGi as a primary means to separate a standard software product’s (end user, not middleware, also large) core from the extension/customizing API exposed to consultants and external partners.
    This allowed us to define a clear API contract and manage both upgrades of deployed systems gracefully and without nasty surprises when it comes to extensions.

    This approach was generally well perceived by both customers (who liked the clear separation of std. vs. customizing as opposed to core modifications) and consultants (who knew which parts of the API they could use safely across versions and found issues before deploying).

    Sorry to hear it didn’t work for you.

    Managing your dependencies & versioning certainly is a lot work, but that won’t go away if you deny it’s an issue. You might be lucky and get away without addressing it, but you probably won’t.

  32. @Hani good to hear bullying and name calling again. But where are the scatological comments? You’re off your game.

    Two years ago I wouldn’t have given a fig about OSGi. But with some of the latest specifications, Spring DM, Karaf, Derby, ActiveMQ, bnd, etc. the toolsets and frameworks are proliferating. Many open source projects are tucking OSGi definitions and Activator classes into their jar files. The number of books coming out on the subject is also telling of a trend.

    Two years ago OSGi would have been nearly irrelevant on any decision I might make on a new project. As I’m now starting on a new project in which Mule will undoubtedly play a part, it’s a bit unfortunate that it isn’t OSGi friendly out of the box.

  33. From comments left by others on my own blog – OSGi is not the problem, Modularity is.

    Really, OSGi is not that complicated. Rather, it’s the law of unintended consequences. The consequences of modularizing dependencies is much more problematical than one might first assume.

    OSGi has kicked my ass for months but to be fair I budget about an hour a week to dick with it and I’m out of time after three, so I never get over the hump. I’ll bet that happens to everyone else too, which explains why tools are never up to speed, dependencies are never found in proper OSGi bundles, and my own skills are always less than what they need to be.

    I don’t pretend to know if OSGi will ever make it over the hump, but if it does it won’t be until 2012 at the earliest, lots of people will have racked up lots of billable hours dicking with it, and critical mass will be the defining factor. With those factors, it doesn’t seem to likely eh?

  34. We have thought a lot about OSGi, and found the effort not worth the benefit. One of our competitors touts the benefits of OSGi and hot deployment, but what we heard from the real world (i.e. those that actually use their software) is that they reboot app servers just like they did before OSGi, because that is the only way to ensure the hot deployed module really works. So before you think about fixing all the nightmarish complexity inherent in OSGi through clever tooling, think about actually making it work at all. Trust me, we’d love to have an easy way for hot-deployable modules. OSGi ain’t it.

  35. OSGI not ready for devs? I think it’s more or a case of devs not ready for OSGI. Get better devs.

  36. […] to your specific case. Others can be debated, and people have. There are both success stories and not-so-awesome stories about implementing […]

  37. @boris: right on!

    Java already supports modularity at the language level. If you require hot pluggability, implement your own classloader (look how tomcat scans for new wars, etc.).

    This will be immeasurably easier to debug (e.g., memory leaks or graceful shutdown of shared libraries) than some hulking be-all-end-all of ‘modularity’ like OSGi.

    I have been making a career in ignoring smelly APIs.
    OSGi looks and has looked like overkill from the very beginning. Seeing it go belly up is yet another glorious vindication.

  38. Boris: “what we heard from the real world (i.e. those that actually use their software) is that they reboot app servers just like they did before OSGi”

    Indeed. Isn’t the Eclipse plug-in model OSGi-based (or have I misunderstood something there)? I seem to remember it recommends a restart after every addition.

  39. […] A disadvantage for some projects might be that Mule says no to OSGi: /osgi-no-thanks/ […]

  40. It’s too bad Mule decided not to go with OSGI. Here we are 2 years later after this post and the tooling has improved significantly, to the point where deves dont really need to worry about the pains of OSGi.

    • Jamie, I’d say the tools have gotten a little better, but devs do still have to worry about OSGi, usually when things go wrong. As stated in my posted we architected with OSGi in mind in case OSGi did figure out the consumer side, but it needs to be assessed according to effort/benefit. Definitely not a slam dunk.

  41. I guess some people here don’t get the fact that OSGi as a technology doesn’t bring you modularity or even hot-pluggability as a free lunch. I don’t really wonder why an attempt to build OSGi into an existing application might fail. But, as Neil pointed out, “Modularity exposes complexity and allows it to be managed. Shoot the messenger if you like, but that complexity isn’t going to go away on its own”. Very well said. I totally agree. And it’s not a tooling issue.

    Years ago, I led the development of a software platform for kiosk machines (like ATM, but with other functionality), and we based on OSGi, even using hot deployment to implement “zero donwtime” manageability. It worked great, and it seemed to me that the development process was going even smoother than in other projects in which we did not use OSGi, because OSGi helped us to design better encapsulated components (versioned bundles) with defined dependencies (taking the bundle versions into account), instead of trying to manage the dependencies of an very fine granular Java package structure. With OSGi, you can manage those mid/coarse grained bundle dependencies much easier, just because they reside on a higher level. And because of this higher level, you better know where to focus on in your software architecture. You can generate beautiful bundle dependency trees and stick them to the wall to communicate the software architecture, and so on. Try this one with a Java package dependency structure.

    Sure, implementing hot-deployment is a bigger deal, as you have to teach the software what to do if a specific bundle is not present. If you don’t have the explicit requirement, e.g. for “zero downtime”, I would think twice before using it.

    To round up, I think what is missing is a small set of best practices newbies can rely on. The books I read about are either going into too much detail, or try to broadly explain all usage possibilities.

  42. Even configuring logging is a pain in OSGi, not saying about real-life applications.
    The idea perhaps is good, however cannot be applied in real world (I’m frustrated trying to run a RESTEasy application in OSGi and can’t stop comparing OSGi to another great idea developed by Karl Marx that did a lot of damage to the world).
    It is good for running hello-world like applications only.

  43. Just had a short stint with it. Aside from Eclipse plugin development (with tycho)

    I think OSGi is good for appliance development just because of the smaller form factor so we can run it on smaller platforms that do not require the entire JEE stack.

    Hot deploy is good for development just so we can debug things faster.

    As an enterprise app though, it needs to be vetted by the enterprise architecture team who realistically shouldn’t just because there isn’t sufficient people in the market that they can obtain lower rates from.