JNP - Java Naming Provider

Description

This is a pure Java implementation of a JNDI provider. It's primarily intended as a replacement for the RMI Registry in RMI applications.

Features

• Hierarchical namespace (i.e. supports subcontexts)
• Supports References
• Supports remote access
• Licensed as OpenSource

Documentation

Download

The latest version of JNP can be downloaded here.

Installation

Follow these steps to install and run JNP:

1. Unzip jnp.zip
2. Make sure that .jar-files are set as executable in your environment. Note: this is done automatically when you install the JDK or JRE
3. Execute /bin/jnpserver.jar to start the server. On a Windows-system this is done by double-clicking on the jar file.

Configuration

The JNP server is configured through system properties. For convenience the JNP server automatically loads the resource "jnp.properties" into the system properties, so by editing that file you can easily configure the server. This file may either be located in the same directory as the jnpserver.jar file, or in the directory "../lib/resources". If you run the server as provided in this package, there is a sample provided in /lib/resources which you may edit.

If you instantiate and run the server from within your own application you may use the JavaBeans get/set methods to configure it at runtime. See javadoc for more details.

Client usage

To connect with a running JNP server by using the JNDI API, please look at the provided example client. Basically, you need to do the following:

• Set the inital context factory to "masteringrmi.naming.interfaces.NamingContextFactory"
• Set the URL of the provider host (the machine where the server is running)
• Set the URL context factory package to "masteringrmi.naming.interfaces"
• Add naming.jar to your clients classpath.
• Add jndi.jar (the standard classes) to your classpath, or at least place it next to the naming.jar file (naming.jar will reference it through its manifest file)

These settings can be provided as described in the JNDI specification. The example client uses a jndi.properties file, which is a recommended technique as it does not clutter the source code with hardcoded settings.

JNP understands URL's prefixed with "jnp:". For example, "jnp://myhost/somedir/somename" is a valid URL.

JNP also understands URL's prefixed with "java:". This is a local thread-sensitive variant which adheres to the definition of environment contexts as specified in J2EE. The context can be switched by calling masteringrmi.naming.interfaces.java.javaURLContextFactory.setRoot(Naming), where Naming is an instance of NamingServer which implements the JNDI namespace.

Here is some sample code of how you would bind an object in JNP. Note that this is generic JNDI code so if you're using the RMI Registry through JNDI there is no code change if you decide to use JNP instead.

Server server = new ServerImpl();
new InitialContext().bind("server",theServer);

Here is some sample code of how you would lookup a bound object. Again, this is generic JNDI code. The only situation in which your RMI application would be code-dependent on JNP is if you decide to run it in embedded mode.

Server server = (Server)new InitialContext().lookup("server");

Testing

Run the file /bin/run.bat to show a test run of JNP. The source to the test can be found in /src/masteringrmi/client/Main.java.

Comparison with RMI Registry

The JNP is intended to be used as a replacement for the RMI Registry. Here is a brief comparison of key features.

• Class availability:
  • The RMI Registry requires you to either use dynamic classloading, or to have the classes (including stub) installed on the registrys classpath
  • JNP have no requirements on class availability. Since it stores any bound object in a marshalled state the classes only have to be available to the client. If any state in a bound object is made of dynamically loaded classes, the codebase of those classes will be stored, and restored upon lookup.
• Usage modes:
  • The RMI Registry can be run externally as a standalone application, or it can be embedded in applications. It does not support graceful shutdowns.
  • JNP can be run externally through an executable JAR, or it can be embedded as a JavaBean in any application. If used in embedded mode, the application can control the naming server through start/stop commands.
• Namespace:
  • The RMI Registry uses a flat namespace.
  • JNP uses a hierarchical namespace, where you can create subcontexts, and do listings of subcontexts etc.
• Access:
  • The RMI Registry allows only local hosts to bind objects.
  • JNP does not have any restrictions on who may bind what. A single JNP server may serve an entire network.

Support

Contact me if you have any questions about this application at rickard@dreambean.com. Bug reports and enhancement requests are also welcome.

License

JNP is licensed through GPL (see www.gnu.org for details).