Disclaimer and Legal Information
Binding Registry Contexts and Remote Objects
| Version | Version Information | Date |
| Initial version | Vasily Zakharov, Nadya Morozova: document created. | March 23, 2006 |
Copyright 2005-2006 The Apache Software Foundation or its licensors, as applicable.
Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0.
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
This document describes the functionality of the DRL RMI [2] Registry Service Provider for JNDI [1]. The document gives details on the provider design.
The target audience for the document includes a wide community of engineers interested in using the RMI registry in their JNDI applications and in further work with the product to contribute to its development. The document assumes that readers are familiar with RMI, JNDI and the Java programming language.
This document uses the unified conventions for the DRL documentation kit.
The RMI registry context, based on a registry location, and the RMI Registry Service Provider allow JNDI applications to access remote objects bound in the RMI registry, as described in the Java* RMI Specification [2].
The provider supplies JNDI with the same essential functionality as
the java.rmi.Naming class does.
The DRL RMI Service Provider is an independent implementation of the RMI Service Provider for JNDI. You can also consult additional information resources on RMI [2], RMI Service Provider [3] and JNDI in general [1].
The provider can store java.rmi.Remote, javax.naming.Reference
and javax.naming.Referenceable objects. The RMI registry context
and references to individual RMI objects can be bound into other JNDI contexts.
The DRL provider does not support binding other contexts into the RMI registry,
so that you cannot address objects in this context using composite name requests
through the registry.
In addition to the general properties [3], the DRL RMI Registry Provider uses the following JNDI environment properties:
java.naming.factory.initial
javax.naming.InitialContext class.
env.put(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.harmony.jndi.provider.rmi.registry.RegistryContextFactory");
Use this property with the java.naming.provider.url
property, which specifies the location of the RMI registry
for the usage of the initial context. Otherwise, the initial
context you created can only resolve complete RMI URLs.
org.apache.harmony.jndi.provider.rmi.registry.clientSocketFactory
java.rmi.server.RMIClientSocketFactory
interface. The instance of this class is passed to the java.rmi.registry.LocateRegistry.getRegistry()
method. The URL context factory, org.apache.harmony.jndi.provider.rmi.rmiURLContextFactory,
enables passing RMI URLs as names to the JNDI initial context.
The class org.apache.harmony.jndi.provider.rmi.registry.RegistryContextFactory
implements the javax.naming.spi.ObjectFactory interface
and provides converting registry references into the corresponding registry
contexts or remote objects.
[1] Sun about JNDI, http://java.sun.com/j2se/1.5.0/docs/guide/jndi/
[2] RMI Specification, http://java.sun.com/j2se/1.5.0/docs/guide/rmi/spec/rmiTOC.html
[3] Sun's RMI Provider, http://java.sun.com/j2se/1.5.0/docs/guide/jndi/jndi-rmi.html
* Other brands and names are the property of their respective owners.