beehive-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Hogue" <>
Subject Re: Testing Controls that use JNDI
Date Wed, 26 Jul 2006 17:26:25 GMT
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.



On 7/26/06, Chad Schoettger <> 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 <> 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
> >

View raw message