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
