You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by Chad Schoettger <ch...@gmail.com> on 2007/02/06 18:47:11 UTC
JDBC control out-of-container testing
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
Re: JDBC control out-of-container testing
Posted by Drew Varner <dr...@redops.org>.
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
Re: JDBC control out-of-container testing
Posted by Drew Varner <dr...@redops.org>.
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