Re: How do I register this data source with JNDI?
On Fri, 8 Jan 2010, laredotornado wrote:
Using Java 1.5. In my Java application server (Resin 3.0.19), I have
this configuration to set up a data source ...
<database>
<jndi-name>jdbc/myco-dor-online-interlock</jndi-name>
<driver type="oracle.jdbc.driver.OracleDriver">
<url>jdbc:oracle:thin:@test-database:1521:orcl11</url>
<user>user</user>
<password>password</password>
</driver>
<prepared-statement-cache-size>8</prepared-statement-cache-size>
<max-connections>5</max-connections>
<max-idle-time>30s</max-idle-time>
</database>
However I am running tests outside of the container and was wondering
what I can do to create and register the above datasource so that it can
be looked up through a JNDI call. Specifically, what do I need to
configure in my system/classpath?
The general approach would be to use dependency injection here - rather
than having your component do a JNDI lookup to get the datasource, have it
be passed in to it. Then, to test the component, the test framework can
pass in a suitable datasource. You have to have another component which
does the injection, but (a) you can use an existing, reliable, framework
like spring, or (b) if you have to write it yourself, at least it's
simple, and you only have to have JNDI set up for testing for that one
component.
However, if you do want to have JNDI happening in your tests, it's not too
hard. You need to add a JNDI provider to your classpath, do whatever magic
it takes to make it usable, set the java.naming.factory.initial system
property to refer to the initial context factory class for that provider,
then in your test framework, create a context and bind the datasource to
it.
So, whch JNDI provider? Well, i'd suggest using the Simple Flat Context
which is the most basic example in the JNDI SPI documentation:
http://java.sun.com/j2se/1.3/docs/guide/jndi/spec/spi/spi-egs.frame.html
With two changes: make the 'bindings' field static, and remove the
'bindings = null' line from close(). That will give you a simple, VM-wide
memory-resident, non-threadsafe (i think) JNDI namespace. In this case,
there's no further magic required to set it up. In your test code, do
(assuming JUnit 4):
@Before
public void bindDataSource() throws various exceptions {
System.setProperty("java.naming.factory.initial", FlatInitCtxFactory.class.getName());
new InitialContext().bind("my/data/source", createDataSource());
}
There's then the problem of creating the datasource. What you want is a
simple implementation of that interface which you can configure with a
JDBC URL and a driver class, and which will call through to JDBC to create
a connection. There isn't one in the JDK, but it's trivial to write, so i
suggest you do that.
Or, if you want to use the same XML you use inside the container, you
could write a little XML parser to read those configuration files.
Wouldn't be hard.
tom
--
There are lousy reviews, and then there's empirical shitness. -- pikelet