Screaming Penguin

So Eric Burke and I have been (somewhat) bashing OSGi on Twitter today. I have picked this fight with the OSGi people about a hundred times now, but I feel compelled to actually rant about it. There are generally 3 models for OSGi on the server side: First, you bundle your WAR file effectively as an OSGi module, you install it into a running OSGi container, then start Pax, or something else that has a servlet container in it. There are better versions of this tact, like using Spring DM, which makes some of the day to day stuff easier. This is all well and good, unless you want support from your Operations group. This amount of black magic and non-"This is my server" weirdness generally pisses off your IT group. Moreover, using embedded servlet containers, you lose a lot of the "real" server configuration you get with a real app server. Second, and this is what I have been working on, is you have your servlet containers that are standardized and you want to run OSGi underneath a plain webapp context. This is doable, but results in much gnashing of teeth, and honestly, I am not sure how much it buys you. Looking at what I have now, a GWT RPC layer that bootstraps as an OSGi web app, then proxies calls into another OSGi module that goes to the "Enterprise" services. This lets me, let's say, upgrade the Enterprise service layer without altering the GWT webapp. OK. Let's put bookmark here and come back to it. Third, you can use something like Glassfish which now has built in OSGi support -- as I understand it, never used it. This sounds like it might be a pretty good way to do this, but, aah. At that point, who really cares? What level of "modularity" am I getting from OSGi that a full EE server isn't already giving me? If someone can tell me why an OSGi bundle is so much better than good old EAR files, I am willing to listen. Or you could use something like Spring DM which is basically a whole new container. Now you have just replaced EE with OSGi. So, aah. Yeah. it is an OSGi app instead of an EE app. Now, let's talk about reality: First, OSGi hot deployment works every time, 60% of the time. It is WAY too often that multi-module dependencies get a class reference that won't die and you end up having to bounce the whole server anyway to get them to refresh. Oh, and did I mention you can't actually tell that this has happened until it fails? EE, or heaven forbid, something web service-y work a lot more reliably for this stuff. And again, to be an ass about it, if OSGi hot deploy works so damned well, why does Eclipse tell me to restart every time I install a new plug in? Secondly, baring a minor bug fix, any real change to the Enterprise service layer is likely going to warrant a change to the webapp module anyway. At this point, I might as well just build a new WAR and redeploy it, because I have to dump the webapp anyway. Thirdly, and this is still the one that gets me every time, WARs and EARs have very clear, mostly monolithic artifacts. They can be moved from build to QA to stage to prod in one fell swoop, carrying with them all they need. Doing what I would call "fractional" deployment to multiple servers seems like a great way to introduce unexpected errors, or misconfigurations. None of the OSGi containers (that I have seen) have a concept of a transactional deployment. I said this on Twitter and I will say it now: OSGi is EJB 2.1. If you really need it, it can do some things really well. For the most part, though, it just adds complexity that is mostly needless to 95% of projects. Maybe JAM/Jigsaw/Whatever will be the EJB 3 of OSGis. I don't know. I haven't followed it that closely, but for right now, OSGi is solving problems I don't have.