Right, agreed that #2 would be more flexible. It looks like the JdbcControl started to create a means to do this, but it's got the quirk about having to reference the generated bean to null out the data source.
I like the mock JNDI environment better for the reasons you stated--it's more flexible and closer to how you'll use the control in your app. Until there's more integrated support it seems like using the Naming component from Tomcat is a reasonable way to do this. A few jars and a couple lines of code in setUp() takes care of getting the environment set up. Or it allows you to externalize the binding of resources in an xml file. Thanks. -Chris On 7/26/06, Chad Schoettger <[EMAIL PROTECTED]> wrote:
Hi Chris, Currently there isn't a good user-friendly way to do this. Both the approaches below will work but it would be nice to come up with some form of explicit support for out-of-container JNDI look ups for controls testing. Of the two methods you list below the second is a bit safer since the first has more of a dependency on the jdbc control's implementation. It seems like there are a couple of options for making this more user friendly moving forward: 1) Add a new annotation to the JDBC control which could be used to specify a datasource for out-of-container testing. 2) Take a look at modifying the ControlTestContainer to include a JNDI context or service which could be used for standalone testing. Option #2 would take a bit more work but is probably the best choice since it could be used by any control, not just the JDBC control. - Chad On 7/26/06, Chris Hogue <[EMAIL PROTECTED]> wrote: > I'm curious what others are doing to test controls that use JNDI, and > what the Beehive folks would recommend. In particular I'm thinking > about the JdbcControl, but it should apply to the other system > controls where they use JNDI as well. > > A couple of approaches I've heard others using are: > > 1. Don't use JNDI, use the ConnectionDriver properties (on the > JdbcControl). Looks like you can set the @ConnectionDriver annotation > on the @Control field in the test case, but you still have to > programmatically null out the ConnectionDataSource, requiring you to > reference the generated bean. So it's a little different usage > (hopefully trivial) than you would be using in a normal @Control usage > where you reference the Interface. > > I wonder if there's a way for the control to recognize that the > connection driver properties are meant to supersede the connection > data source. For example, can it tell that it's been set on the field > rather than the interface itself? This may make it a little easier > to test out-of-container. > > > 2. Create a JNDI environment in the test case. This can be > accomplished with the Apache Naming component, though it takes a > little more setup and dependencies than #1. I think there may also be > some JUnit helpers that help to set up a context. > > > Are there any other recommended approaches that people have run across? > > > Thanks. > > -Chris >
