How do I lookup a JNDI Datasource from outside a web container?

Question

I have the following environment set up:

• Java 1.5
• Sun Application Server 8.2
• Oracle 10 XE
• Struts 2
• Hibernate

I'm interested to know how I can write code for a Java client (i.e. outside of a web application) that can reference the JNDI datasource provided by the application server.

The ports for the Sun Application Server are all at their defaults. There is a JNDI datasource named jdbc/xxxx in the server configuration, but I noticed that the Hibernate configuration for the web application uses the name java:comp/env/jdbc/xxxx instead.

Most of the examples I've seen so far involve code like

Context ctx = new InitialContext();
ctx.lookup("jdbc/xxxx");

But it seems I'm either using the wrong JNDI name, or I need to configure a jndi.properties or other configuration file to correctly point to a listener? I have appserv-rt.jar from the Sun Application Server which has a jndi.properties inside of it, but it does not seem to help.

There's a similar question here, but it doesn't give any code / refers to having iBatis obtain the JNDI Datasource automatically: Accessing Datasource from Outside A Web Container (through JNDI)

Solution 1

I got stuck on this exact same problem. I wrote a small tutorial. Basically you have to create your own implementation of the DataSource objects and add them to your own custom initial context. There are source examples here:

Running Beans Locally that use Application Server Data Sources

Solution 2

Try Simple-JNDI. It gives you an in-memory implementation of a JNDI Service and allows you to populate the JNDI environment with objects defined in property files. There is also support for loading datasources or connection pools configured in a file.

To get a connection pool you have to create a file like this:

type=javax.sql.DataSource
driver=com.sybase.jdbc3.jdbc.SybDriver
pool=myDataSource
url=jdbc:sybase:Tds:servername:5000
user=user
password=password

In your application you can access the pool via

Context ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("path/to/your/connectionPool");

I haved used Simple-JNDI for this purpose for years now. But it is not under active development anymore. Because I found some issues concerning shared contexts (especially using datasources), I decided to branch the original project and to add some new features. Now there is a 0.13.0. You can find more about it at https://github.com/h-thurow/Simple-JNDI.

Solution 3

If you're talking some every day generic Java application running outside of the container, then you're out of luck. Effectively you would need to configure your own JNDI implementation, with it's own configure connection pool, etc.

However, you can write Java EE "standalone" applications. These are applications that run within the Java EE application client. Basically, it's an app that is deployed and packaged, but then executed using a launcher that's provided by your Java EE container.

When running within an application client environment, all of the resources of the app server (connection pools, EJBs, queues, etc.) are available to your app just like they would be if the code were deployed within the app server.

Here is some tutorial documentation for Sun App Server 8.2, which is a J2EE 1.4 container.

If it's possible I'd strongly suggest upgrading to Glassfish v2.1, just a more modern, better all around server that should deploy your apps just fine as is, since it's a descendant of 8.2.

Comments

[masotime]

Hi, thanks for the response. The application client is interesting, but it's a little too heavy for my needs. The intent was to reuse the connection defined in the web-server to maintain consistency as a single point to get a database connection.

[masotime]

Thanks for the idea of writing a standalone JEE application. It's an interesting alternative, but I was hoping for the possibility of using the app server as a direct JNDI provider to obtain the remote datasource directly. The choice of Sun App Server 8.2 is due to legacy reasons unfortunately, so we can't shift to Glassfish, which would definitely be better.

[Anthony Fammartino]

The blog post was extremely useful. Thanks!