Spring Criticism, part 2

Ok, I am back with a funky track.

First off, this is not a rant, or a complaint. I just recently hit some functionality within the Spring OSGI container which seems poorly designed, and I wanted to share the love.

So, OSGI is all the rage these days, supposedly. Or so it seems on various marketoblogs disguised as blogs. After a lot of hatin' on/at those blogs, I finally got around to checking it out. Imagine my surprise! OSGI is actually really goddamned awesome. Bundles, dependencies, dynamically bringing them up and down, eeehhh, not so much, but bundles and dependencies! Yayyy. I'm happy.

Enter Spring, with their "I gonna configure your world so hard, you're not gonna know how I configure your world so hard" mentality. After a tiny learning curve, I was happily writing Spring configuration XML files, lusting after the functionality that lay hidden behind various goodies such as spring-osgi-web and spring-osgi-web-extender. I have some experience with the Servlet spec, and it all made sense.

What I wanted to do was deploy a war in an already existing OSGI container, as a bundle. Well, that sounds pretty simple, right? You throw together the webapp, required libraries follow the Servlet spec and reside in the warfile's ${home}/WEB-INF/lib. Throw it in the osgi startup and you're done!

java.lang.ClassNotFoundException

O_o. No! This cannot be! I did everything riiiiiight. Wait a second... The docs say you have to add the jars required by your webapp to the MANIFEST.MF file within ${home}/META-INF. Of course, how could I be so stupid, this is OSGI. Duh!

Or is it a "Duh?" This specifically allows for war files that break the Servlet spec to actually work within an OSGI container's Spring-powered web bundles. Not only can jars be outside of WEB-INF/lib, classes don't have to be within WEB-INF/classes. This is where things kinda get weird. Why would Spring folks (now VMWare, blah blah) want to do this? Why not spend a little extra effort and scan the war file as a J2EE-compliant server would, and make our lives even easier by automatically including the jar files found within to our bundle's classpath?

I don't know. Perhaps they ran out of time. Perhaps no one is using their DM server tech and this has not come up. I do know that this does not quite fit in with their philosophy of "non-invasive configuration." It effectively breaks the Servlet spec.

I am all for that don't get me wrong, technology has to move forward. But why this sudden break with backwards compatibility?

For conspiracy theorists, the other possibility is that Spring is attempting to become the dominant Java enterprise tech puddle that we, the Spring semi-programmers (now with 110% more configuration skills) lurk in.

My two cents? I like the mud here. But I'll be damned if I don't call it out for being mud.