In the heady months leading up to Databinder’s debut (fall of ’05, for the newbs) I was bouncing around the Wicket listserv trying to determine if Wicket core or extensions would ever integrate with persistence technologies like Hibernate. The answer was a resounding “no.”

That had a lot to do with Wicket’s already-laid plans to become an Apache project, specifically the need to keep the codebase license-pure. Good reason! Also, Spring filters can open and close Hibernate sessions for you, so all you have to do is blah blah blah—bad reason!

Spring-managed transactions for Wicket make a fine configuration (and one we use at my job), but it’s not trivial to get it working. Wicket’s IModel is a difficult concept on its own, and one that particularly affects how you persist your data. Sending inquisitors off to ponder an example app with a dozen source files to determine how to accomplish a fundamental task is not much of a welcome wagon.

Besides, not everyone is using Spring, or even interested in using it. Why expect them to?

About that Spring

Spring is the kudzu of Java programming. The library’s chastity pledge is that “application code should not depend on Spring APIs,” a clever misdirection. Without any classpath dependencies, it hooks its tendrils around applications, projects, and programmers themselves.

The Spring mindset and coding style (interfaces, interfaces, interfaces!) deeply affect any application they touch. Perhaps the changes are all reasonable and helpful, or perhaps half of them are made only to flaunt the latest programming fad. Either way, the result is program code that is harder to follow, for both humans and computers.

This is my biggest gripe with Spring-style coding: you can’t click from one class to another in Eclipse; you end up at an interface dead-end. If my IDE can’t tell where the next statement is, how am I supposed to find it? I have to either know it or look it up in an XML file. That is bullshit.

Even more confusing is unrelated code that runs as I call a normal-looking method. Thanks to those famous Spring interceptors, there’s no hint of the altered execution path in the program source. It’s almost as if they set out to make software code harder to read.

Interceptors are worse than goto.

That’s just my own, unfashionable opinion. I recognize that there is some good stuff in Spring and that some projects benefit from using it sensibly. But when you elect to contort your inheritance hierarchy and execution path (hello, fundamentals of object-oriented and procedural programming!), you’d better have a damn good reason.

Spring problem-solving steps

1. Is there even a “problem” you’re solving here? Or just some trick you want to perform? Well don’t.
2. Ok, real problem? Can’t solve it with traditional OOP? Try harder.
3. Umm, fine. Inject, intercept, cross-cut your heart out, but do not expect me to debug in that ridiculous call stack.

We can all just get along

So much for spite, new releases of Databinder will work with Spring-managed Hibernate transactions.

It’s something we might have done all along, had we known better. We don’t even have to pander to Spring specifically. In Databinder 1.1-SNAPSHOT releases, we’re using Hibernate’s “current” session facility. Instead of calling DataRequestCycle.getHibernateSession() (now deprecated), you’ll call DataStaticService.getHibernateSession(), which itself calls getCurrentSession on the Hibernate session factory that it owns. Please, try it yourself.

A standard Databinder app will use a ManagedSessionContext bound by DataRequestCycle, but applications are free to manage sessions and transactions externally with JTA or Spring’s LocalSessionFactoryBean or whatever is cool next week. All you have to do is tell DataStaticService what session factory your app is using. Then you can use our sought-after Wicket persistence models. We won’t even charge you for ’em.

♪You know it’s hard out here for a pimp…