beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Varner <>
Subject Re: JDBC control out-of-container testing
Date Tue, 06 Feb 2007 18:41:53 GMT
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

View raw message