Testing Controls that use JNDI

[Chris Hogue <cs...@gmail.com>]

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

Re: Testing Controls that use JNDI

[Chris Hogue <cs...@gmail.com>]

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 <ch...@gmail.com> 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 <cs...@gmail.com> 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
> >
>

Re: Testing Controls that use JNDI

[Chad Schoettger <ch...@gmail.com>]

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 <cs...@gmail.com> 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
>