Monday, July 9, 2012

Evangelizing OSGI



I've read a number of posts about OSGI and most of them do not mention the framework's greatest strength.  In a traditional JEE or Web application server, they all come with built in jars.  Every app server contains a stack of jars that are not the same from version to version or for that matter are not the same across vendor implementations. I've even seen variations in the jar stack in the same version of a container. In theory, you are supposed to be able to drop any web app into any JEE compliant app server and it would just work.  We all know that is just not true.

I was once on a project where the container jar set was manipulated throughout the dev cycle that no one knew how it was derived and for what reason.  The only thing we knew was that one of our developers had a working set of jars.  We were set to go into production within a matter of days, so to get us back on track, all of the jars from his machine were copied into the production instances.  The final app container did not even closely resemble the named version of the app containers GA'd release.  Talk about a cluster.  Whenever we came across a 'ClassNotFoundException' or a 'MethodNotFoundException', we just took the working stack of jars and replaced the jars and hand jammed them into the container.  That is no way to develop.

So the point of this post is that OSGI eliminates uncertainty in your jar dependencies and your OSGI app will always be consistent and you wont be left guessing on hard to find bugs related to runtime dependencies not to mention the class loader problems.  And finally, your app becomes the container and you distribute your app as a self contained tar ball or zip file.  Not a war or ear deployed into an app server (although your app contains war files) where it may or may not satisfy all of your apps dependencies.  I value my sleep and I don't want to be on a 3 am call trying to diagnose class loader issue.  Thanks for reading my post.

No comments:

Post a Comment