Consider the following pretty standard EJB 2.x code that uses JDBC connection
public class MyBean extends AbstractSessionBean {
public void myBusinessMethod() {
Connection conn = getConnection();
try {
... BUSINESS CODE
} catch (SQLException e) {
throw new EJBException(e);
} finally {
closeConnection(conn);
}
}
}
There are few things to note here. First, this exact code will be replicated in every business method that uses JDBC connections. Second, getConnection/closeConnection are declared in AbstractSessionBean which is the base class for all my stateless session beans. And last, the only place that does JNDI lookup is getConnection.
Unless I am missing something, EJB3 only saves me few JNDI lookup lines. It does not "improve ability to test outside of container" that much, as I still have to provide functional DataSource implementation to be able to test this code. It does not simplify exception and resource management.
Basically I still have to use custom "around business method" interceptor to inject Connection and take care of the rest of the "plumbing". And hey, if I am writing my custom interceptor I may as well add few JNDI lookup lines.
So I guess my question is what I am missing here? Is there something in current EJB3 draft or maybe something that is coming in later drafts that solves this common problem.
