What is the purpose of JNDI

JNDI is an API used to access the directory and naming services (i.e. the means by which names are associated with objects). The association of a name with an object is called a binding.

A basic example of a naming service is DNS which maps machine names to IP addresses.

Using JNDI, applications can store and retrieve named Java objects of any type.

Within the context of java this can be used in configuration files where you don't want to hard-code environment specific variables.

Spring Example:

Spring context file

<bean id="WSClientConfig" class="com.example.BaseClientConfigImpl">
<property name="protocol">
    <jee:jndi-lookup jndi-name="java:comp/env/protocol" />
</property>
<property name="endpoint">
    <jee:jndi-lookup jndi-name="java:comp/env/endpoint" />
</property>
<property name="requestPath">
<jee:jndi-lookup jndi-name="java:comp/env/requestPath" />    
</property>

Tomcat context file

<Environment name="protocol" type="java.lang.String" value="https://"/>
<Environment name="endpoint" type="java.lang.String" value="172.0.0.1"/>
<Environment name="requestPath" type="java.lang.String" value="/path/to/service"/>

JNDI is a very powerful mechanism for both organizing configuration information and discovering and listening to services via using the EventContext. In JNDI you can lookup and listen to any object (not just DataSources), assuming your JNDI service provider supports it.

Of course, the only issue is actually having a JNDI service provider; the great thing about this is that it surprisingly easy to roll your own. After all you can encode any Java instance into XML using the JavaBeans XMLEncoder and XMLDecoder: you don't need to rely on running within an application server!

So what is the difference between this an having configuration files? Well, it can be much cleaner because all of your applications can get their configuration from the same place. If they need to share configuration information (e.g. database locations) then this can be defined once in JNDI. Suppose you moved database servers: you don't need to remember the gazillion config files with the location in it. You just go to the one place: JNDI.

JNDI is the Java Naming and Directory Interface. It's used to separate the concerns of the application developer and the application deployer. When you're writing an application which relies on a database, you shouldn't need to worry about the user name or password for connecting to that database. JNDI allows the developer to give a name to a database, and rely on the deployer to map that name to an actual instance of the database.

For example, if you're writing code that runs in a Java EE container, you can write this to get hold of the data source with JNDI name "Database":

DataSource dataSource = null;
try
{
    Context context = new InitialContext();
    dataSource = (DataSource) context.lookup("Database");
}
catch (NamingException e)
{
    // Couldn't find the data source: give up
}

Note there's nothing here about the database driver, or the user name, or the password. That is configured inside the container.

JNDI is not restricted to databases (JDBC); all sorts of services can be given names. For more details, you should check out Oracle's tutorial.