The Tyranny of Choice

As I’ve mentioned before, my company is trying to decide if we really need to keep using Spring now that we’re in a "full" JEE environment. As I’ve pondered this over the past few days, I’ve realized (as I figured we would) that the choice is not so simple. Our desire in this evaluation is to try to make the best decision for our company, but that’s not so easy with the cacophony of voices out there.

As I detailed in "A Little Less Spring in Our Step?", our thinking was that since we use JSF, we could use its IoC, supplemented by container injection to replace what Spring does for us (templates notwithstanding). I started a new app this week, so we decided I’d experiment with that and see how it goes, and, thus far, it really hasn’t been too bad. I have things working, but things aren’t quite as easy as they once were. Under the old way, I could tell Eclipse to deploy my app to the server and start debugging, but, with EJB3, we have to package our app correctly to get injection and such to work. Since MyEclipse does not appear to support EJB3 yet, that means I have to use ant to package and deploy my archive, which means a lot of window switching. That’s not a big deal, but it’s not a nice feature either. ;)

Recently, there have been a number of articles about Spring and JPA, which is one of our main interests in EJB3 (we need to do some SOA stuff, so the ease of development and deployment of session beans and web services is also of interest. Plus JMS, JMX, …​). This shows that we can maintain our commitment to and investment in Spring, and still gain the advantage of using the standard ORM (of course, "standard" here means "official", not standard as in "commonly used." That title clearly goes to Hibernate), making switching providers, should the need arise, even easier. But what do we lose? Session bean injection? We’re not doing that right now anyway. DataSource injection? We’re doing that now through Spring, but defining a JNDI lookup bean and wiring it in through the config. Hmm…​

Ater reading the comments here, I’m really not sure. Gavin, of course, loves EJB3 (as do I), but Rod and others seem not to. Both parties are, of course, a bit biased, but is that because they feel that way honestly, or because they have to because preivous public positions or employers require that they do. Or a mix of both. It’s tough to say, and far be it from me to try to guess at then malign someone’s motives, but that uncertainty does require that I take their comments with a grain of salt the size of a <a title: "I stole this line :)">Ford Taurus</a>. Rick Hightower seems to be somewhere in the middle, tied to neither platform, and he prefers Spring. Being someone whose opinion I tend to value and trust (though I’ve never actually met him ;) ), his stance lends a good deal of support to maintaining our Spring commitment. Gavin (and Rod), though, are no slouches themselves. Ah, the tyranny of choice. I feel like Robin Williams in Moscow on the Hudon trying to buy coffee. Maybe we should just switch to Ruby where, apparently, we’d pretty much have only one choice. Ugh. Forget I said that. :)"

So, we have a dilemma that we need to resolve and move on. I don’t want it to come down to the toss of a coin, but, personally, I’m having a hard time making a decision. My experience this week, though, has made me wonder if our all-EJB3 experiment is worth finishing, so maybe that tells me something. I’m certainly leaning toward ending the experiment. I’ve long been a Spring fan, and 2.x looks really exciting. If we need session bean injection, I think we can always use aspects (neatly handled by Spring) to force container injection at object creation time. That may be the route we go. As Matt Drudge would say,

Developing…​