I submitted the setConnection() patch.
I still believe the correct way to go about this is to lazily grab
the connection. You would not have to add a new annotation and it
would not break any existing code.
- Drew
On Feb 6, 2007, at 12:47 PM, Chad Schoettger wrote:
Last December a user patch was submitted for BEEHIVE-1019 which added
a new API to the JDBC system control. Then new API was
'setConnection()' which allowed a user to provide an external JDBC
connection to the control.
Recently I've been working on a new Beehive sample which demonstrates
how to test the JDBC out-of-container (as well as some other JDBC
control features). I was planning on using the setConnection API to
supply the JDBC connection from my JUnit test, but found that when a
JDBC control has either the @ConnectionDriver or @ConnectionDatasource
annotation specified that invoking setConnection will cause the
control to attempt to acquire the connection specified in the
annotation (which will fail if set for a production environment),
causing the setConnection api call to except.
In short, it is still difficult to test a JDBC control out-of-
container.
I was thinking of adding a new annotation attribute, something like
'useExternalConnection' to the @ConnectionOptions annotation of the
JDBC control. If set to true, the JDBC control would not try to get
or free a connection when it receives a resource context event. This
would be a very small change to the JDBC control (literally about 2
lines of code) and it would make it much easier to test the control
out of container.
Questions / comments?
Chad
