Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JNDI overview, Part 4: the Doc-u-Matic, a JNDI application

Pull together your JNDI knowledge with a JNDI-enabled application

By Todd Sundsted, JavaWorld.com, 03/31/00

Page 2 of 6

Before you proceed, make sure you've obtained, installed, and configured the following (if necessary, refer back to my earlier columns):

• An LDAP implementation
• Sun's JNDI reference implementation and the LDAP service provider

You'll also need to create the initial context that the application will connect to. I assume the following:

  ou=HowTo,o=JavaWorld

If you're not sure how to do this, you'll need to refer to your LDAP service's documentation.

Usage

Before we dive into the code, let's stop for a moment and look at how to use Doc-u-Matic.

There are two usage roles: the administrator and the user. The administrator (think of a librarian) creates or deploys the library and publishes objects of various types in the library. The administrator also creates and distributes a properties file that contains all of the information necessary to connect to and use the library. Users, on the other hand, retrieve objects from the library.

The administrator's role

Let's begin by assuming the role of the administrator. The deployment tool is named JNDIDeploy. Before you deploy a library, you must create a properties file that contains the information necessary to connect to an initial context. The properties file must also contain the name that the JNDILibrary object will be bound to. If you configured your LDAP service with the LDIF I've supplied (see Resources), the following properties file will provide a good place to start:

# DEPLOYMENT PROPERTIES
# This properties file contains all of the information necessary to
# find and connect to the JNDI service that holds the library and all
# published objects.
java.naming.factory.initial = com.sun.jndi.ldap.LdapCtxFactory
java.naming.provider.url = ldap://localhost:389/ou=HowTo,o=JavaWorld
library.name = cn=library

The library deploys as follows (I assume you've already set up the classpath to point to the jndi.jar and ldap.jar JAR files):

  java JNDIDeploy <properties file>

Once you, as administrator, have deployed a library, you must distribute a properties file to all users. The client applications I've developed all read a properties file pointed to by a URL. Therefore, the easiest way to distribute this file is to put it on a Web server and distribute the URL of the properties file.

Once you have deployed a library, you can publish objects to the library. By objects, I mean instances of Java classes. Objects play the role of abstract containers of information. As such, the simplest object is probably an instance of the String class. I've purposefully placed few requirements on publishable objects; they must be instantiateable via the Beans.instantiate() method, and they must be storable via JNDI. Objects are published as follows:

  java Publish <properties URL> [name class]...

The Publish command requires the URL of the properties file mentioned above. It also accepts any number of additional pairs of arguments. The first value in each pair is the name of the object. The second is the name of the class (including package information) that will be instantiated and stored. The name must conform to whatever naming policy the JNDI service provider requires. In the case of LDAP, names will be of the form: