In Relation To

We were doing some work with a customer with a very large project recently, and they were concerned about traceability of the SQL issued by Hibernate. Their problem is one that I guess is common: suppose I see something wong in the Hibernate log (say, some N+1 selects problem), how do I know which of my business classes is producing this? All I've got in the Hibernate log is org.hibernate.SQL, line 224 as the source of the log message!

There's been a certain amount of noise recently surrounding simple JDBC frameworks like iBATIS. I've liked the idea of iBATIS myself, for use in applications which don't need an object-oriented domain model, and don't work with deep graphs of associated entities in a single transaction. A JDBC framework also makes good sense if you are working with some kind of insane legacy database; ORM solutions tend to assume that associations are represented as nice clean foreign keys with proper referential integrity constraints (Hibernate3 much less so than Hibernate 2.x).

Just had an interesting discussion on ejb3-feedback@sun.com, started by David Cherryhomes, which saw me stupidly insistingthat something can't be done when in fact, now that I think about it, /I realize I've actually done it before/, and that even the Hibernate AdminApp example uses this pattern!

Simple is a seductive notion. We all want to make things simple. But when we talk about software, simple could mean at least two different things.

Cedric and Bill have proposed solutions. My preference is basically similar to Bill's, but here's how I would write it:

This item is a prediction about the future. Predicting the future is a dangerous business, and exposes the author to ridicule in both the future and present. Nevertheless, articulating a /nice/ vision of the future can help bring about that future.

Now that the EJB 3.0 early draft is out there, it's definitely time to move on from all the recent politics, and start thinking about what we can actually /do/ with this stuff. EJB is the only Java standard which addresses server-side /business logic/, and is thus central to J2EE. The EJB spec committee recognizes that EJB has fallen short of achieving some of its ambitious goals, and is in need of an overhaul. This overhaul has focused very much upon ease of use, primarily via simplification of the requirements upon bean implementors. However, the spec committe also identified a number of critical functional enhancements that facilitate ease of use and the elimination of certain J2EE anti-patterns.

Another blogger, who will remain unmentionable, is upset that some of the guys at JBoss are beginning to throw the term AO around. According to him, the AOP community is just terribly attached to their P, and quite concerned that JBoss might be about to dominate the world with their P-less aspects.

I've posted the slides for two recent presentations.

Recently, we've started to hear complaints that we don't put enough effort into free support in the Hibernate forums. This really kinda hurts, since everyone /used/ to comment that we gave such /great/ support, and since I still spend hours most days reading and responding to forum posts. I don't get paid for this, and I rarely get thanked for it either (even by the people I do get time to respond to). I've been doing this for almost three years now.