I was speaking at the Raleigh/Durham No Fluff show this weekend, and one of the attendees caught me in the hallway to ask a question. At this show, I wasn't even presenting on Spring; my talks were on SOA, Security Web Services and Hibernate. However, this attendee presented to me his problem: his company is dealing with a longstanding WebSphere project. One of his colleagues has been introducing Spring slowly into the group. Another told the assembled team that Spring was just an open-source J2EE wannabe, and it was silly to use it since they already had WebSphere. He wanted to know what I thought.

I told him that his colleague who was introducing Spring quietly to the group had it right. I also told him that his other colleague was a blowhard who hadn't read TFM. Rod n Co. created Spring in the first place to make J2EE easier to configure, more flexible and more fun to use. They will be the first to admit that they were trying to eliminate *EJB* from their toolkit, but we all know that EJB != J2EE. His colleague apparently went on to say that the overhead of the Spring framework on top of WebSphere was too burdensome to the project. Now, I haven't looked at the current footprint of WebSphere, but I'm willing to guess that the 90K Spring adds isn't damaging the overall image or resource usage.

So I'd like to remind everybody that Spring, while a perfectly capable "lightweight container" all on its own, shines in an environment that has been struggling to corral the goodness of J2EE through the sometimes labyrinthine configuration and management strategies of the container vendors. Spring is the outcome of several very smart people's struggles to do just that; if you can use Spring all on its own, then ballyhoo for you. But Spring seems to be being adopted most often by teams with existing "enterprise" apps with standing investments in Big Container X.