Archive for category OSGi

via Jerome Dochez (Du côté de chez…) it looks like Glassfish v3 will be running in top of OSGi (hopefully Felix).

Now the interesting question that everyone will be asking soon, are we switching to OSGi as our underlying module subsystem ? Today I can say yes, we will.

I don’t know very much about Glassfish, but knowing the Sun position
on OSGi (or lack thereof) made me wonder if this was a belated April Fool’s joke. This seems like a very bold move and hopefully there is more news like this on the way (crossing fingers). Given the recent analysis of JSR-277 by Peter Kriens (Ghost Town JCP) and Neil Bartlett (No Way to Run a JSR), maybe my one time wish that “common sense would prevail” might show a glimmer of hope?

Peter Kriens has posted an interesting blog entry that pretty much summarizes the current situation between the OSGI camp (aka JSR-291) and the Sun JSR-277 and JSR-316 camp. I have to say that I pretty much agree that as far as technology goes, I would much prefer that Sun be more open to adopting OSGi as a standard technology for all of the Java runtimes (Java ME, Java SE, and JavaEE). OSGi has proven itself already and has had years to evolve and become what it is while being driven by real world requirements and usage.

I think the big conflict between Sun and OSGi is a very simple political battle over control and licensing. Technology be damned! Once again the politics of Java are eschewing the common sense and logic that would normally prevail among intelligent individuals. I have been very hopeful that Java was making a resurgence in its ability to innovate and evolve, but this is the kind of thing that makes me worry…

To be perfectly fair, I think the resolution to this lies just as much with the OSGi Alliance as it does with Sun. I am not privy to the details of such conflicts, but I am confident that there is a fair amount of ego involved in this issue on both sides and having an external company structured around a “specification” such as OSGi does not lend itself well to being community driven. However, I will continue to use OSGi and recommend it because I feel that it is far superior to any of the “from scratch” specifications being authored in the JCP, and I can only hope that in the long run common sense will prevail in some fashion with both parties involved.

I think pretty much all of my clients, friends, and project mates read my blog so in an effort to reduce my workload I am posting items of interest here instead of sending them in emails like I have been. One thing I do frequently is send OSGi sightings in the wild (mostly to convince my consulting clients that I am, in fact, not crazy). I am not going to bore anyone with the obvious, like Equinox, WebSphere 6.1, etc., but I do want to point out new and interesting uses of OSGi.

First installment: Zutubi appears to be commited to using OSGi as a foundation in a future release of Pulse, their continuous integration and build automation server. Jason and Daniel talk about OSGi in several of their blog entries. I think this is a great application of OSGi and I wish them lots of luck. For those new to OSGi, they have also blogged about some resources to help get started and learning OSGi and it looks like they are taking a live blog approach to their experience and I expect to see some good anecdotal entries regarding OSGi as they go along.

So obviously Steve Jobs’ comments about 3rd party apps and Java on the iPhone have started a storm of blog entries and discussions about Java’s deployment footprint and the feasability of deploying Java apps to mobile devices. For that one guy out there who hasn’t seen the quote, here is the meat of it:

“Java’s not worth building in. Nobody uses Java anymore. It’s this big heavyweight ball and chain.”– Steve Jobs

As an OSGi cheerleader, I feel like its my duty to point out that this is exactly the type of thing that the OSGi specification and the community around it is trying to address. I am not going to give an OSGi 101 class here (yet), but most people know that OSGi is a very organic way to address dynamic components and deployment management. Of course there are many other aspects to it as well, but the runtime management of dependencies is where most people get their “A-ha!” moment.

Right now, I am deploying my own application code (Swing apps, embedded apps, J2EE middleware) in small (dynamic) chunks using OSGi, but what about the Java runtime? I think it would do a lot for the future of Java if we had the opportunity to deploy the actual Java runtime in the same manner, using only what is needed. In this way, you can imagine J2ME, J2SE and J2EE being pre-configured OSGi systems, but also be able to remove unnecessary parts if you don’t need them, like in an embedded application for instance. Obviously I am totally biased, but I think an OSGi based JVM would make a lot of sense for the future of Java. Oh, and don’t even get me started on JSR-277

One more thing, I am running an OSGi based Java application with Wi-Fi, VOIP, IM, GPS, and Bluetooth on a Gumstix platform that is probably 1/4 the size of the iPhone. I am not sure I really buy the heavyweight ball and chain crap to begin with

In the past year or so I have had a recurring nightmare in dealing with Apache’s comons-logging project and its pervasive (and I think misguided) use by a lot of open source projects. The difficulties are well known to those who have had issues using it within web apps on many different web containers, but I think a lot of people are still in the dark about how bad some of these problems are.

I think the memory leak issues have been resolved by simple means, but the use of the dynamic discovery mechanism continues to baffle me to this day. I think this only accurately works in simple java applications that all share a simple classloader mechanism. The problems with commons-logging classloader tricks first showed up in servlet containers because of the classloader heirarchy and I have spent many hours working through those issues in the past year or maybe even two. Today some of us in the OSGi community have run across it again trying to use commons-logging within OSGi frameworks (more specifically, libraries that use commons-logging).

Lather, rinse, repeat…

I have pretty much had it with commons-logging and long ago started using the slf4j library and its toolbox of hacks to get around the dynamic discovery mechanism. Slf4j is similar to commons-logging except that you specify your logging imeplementation by including a log adapter as a jar file so the linking is static. On top of that, slf4j includes a facade that also imeplements the commons logging API so that you can take out commons-logging altogether and use slf4j instead. Obviously this is mainly useful because many, many open source projects blindly use commons-logging even though it is known to have had these issues for quite some time. I have done this many times in the past year with great success, so if you even remotely suspect commons-logging causing problems in your app, I suggest reading this page and give it a shot.