--- old/src/java.corba/share/classes/org/omg/CosNaming/package.html 2018-01-30 20:29:10.000000000 -0500 +++ /dev/null 2018-01-30 20:29:10.000000000 -0500 @@ -1,351 +0,0 @@ - - - - - - - - Provides a naming service for Java IDL. The Object Request Broker Daemon - (ORBD) also includes both a transient and persistent naming service. - - -

- The package and all its classes and interfaces - were generated by running the tool idlj on the file - nameservice.idl, which is a module written in OMG IDL. - -

Package Specification

- -

For a precise list of supported sections of official specifications with which -the Java[tm] Platform, Standard Edition 6, ORB complies, see Official Specifications for CORBA -support in Java[tm] SE 6. - -


- The package org.omg.CosNaming contains two public interfaces - and several auxiliary classes. -

- The interfaces are: -


- These two interfaces provide the means to bind/unbind names and object - references, to retrieve bound object references, and - to iterate through a list of bindings. The NamingContext - interface supplies the main functionality for the naming service, and - BindingIterator provides a means of iterating through a list - of name/object reference bindings. - -

Auxiliary Classes

- In order to map an OMG IDL interface to the Java programming language, - the idlj compiler creates Java classes that can be thought of - as auxiliary classes. - Comments for the generated auxiliary classes - used by the interfaces NamingContext and - BindingIterator are included here. - -

Classes Used by NamingContext and - BindingIterator

- The following are classes used by - the naming service. (Helper and holder classes, which are - generated for each of the classes listed here, are discussed below.) - - - -

Holder Classes

- - OMG IDL uses OUT and INOUT parameters for returning values from operations. - The mapping to the Java programming language, which does not have OUT - and INOUT parameters, creates a special class for each type, called - a holder class. - An instance of a holder class can be passed to a - Java method as a parameter, and - a value can be assigned to its value field. This allows - it to perform the function of an OUT or INOUT parameter. -

The following holder classes are generated for the package - org.omg.CosNaming: -


- Note that in the org.omg.CORBA package, - there is a holder class for each of the basic Java types: - IntHolder, ShortHolder, - StringHolder, and so on. -

- Note also that there is a NameHolder class even though - there is no Name class; similarly, there is a - BindingListHolder class even though there is no - BindingList class. This is true because in the OMG IDL - interface, Name and BindingList are - typedefs. There is no mapping from an IDL - typedef to a Java construct, but holder classes - are generated if the typedef is for a sequence or - an array. As mapped to the - Java programming language, Name is an array of - NameComponent objects, and a BindingList - is an array of Binding objects. - - All holder classes have at least two constructors and one field: -


- A holder class for a user-defined type (a Java class) has three more - methods, but application developers do not use them directly. - -

Helper Classes

- Helper classes, which are generated for all user-defined types - in an OMG IDL interface, supply static methods needed to manipulate - those types. -

- There is only one method in a helper class that an - application programmer uses: the - method narrow. Only Java interfaces mapped from IDL - interfaces will have a helper class that includes a narrow - method, so in the CosNaming package, only the classes - NamingContextHelper and BindingIteratorHelper - have a narrow method. -


Package org.omg.CosNaming.NamingContextPackage

-This package supplies Helper and Holder classes for the exceptions used -in the package org.omg.CosNaming and also for the class -NotFoundReason, which supplies a reason for the exception -NotFound. -

-There are Helper and Holder classes for the following exceptions: -

- -

Naming Service Compatibility

- -Sun's implementation of the CosNaming package complies -with the OMG COSNaming specification. In other words, -the APIs in Sun's naming service are implemented according to the -guidelines for a naming service provided by OMG. Therefore, if a -third-party vendor has implemented a naming service that is OMG -compliant, it is possible to switch between Sun's implementation of -CosNaming and the third-party vendor's implementation. -However, it is important to understand that there can be minor -variations in the way different vendors implement the naming service, -such as differences in the exception strings. - -

Instructions for Using a Third Party's Naming Service

-Although we encourage using an ORB and ORB services that are both -from one vendor, it is possible to plug in a third party's -COSNaming implementation with Sun's RMI-IIOP ORB. -Here are the steps to follow: -
  1. Create a properties file for the Bootstrap server and give it - two entries. For example, you could call this properties file - /tmp/services and put the following in it: - NameService, <Stringified IOR of the Root Naming Context>. -

    - This associates NameService with the Root Naming - Context of the CosNaming implementation that you - want to use. -

  2. Start the standalone Bootstrap server using the following command: -
    -      java -classpath $(CLASSPATH)
    -      com.sun.corba.ee.internal.CosNaming.BootstrapServer -InitialServicesFile
    -      "/tmp/services" [-ORBInitialPort port]

    - Note that the square brackets at the end of the command indicate that - specifying a port number is optional. -


-Now when an application calls the method -org.omg.CORBA.ORB.resolve_initial_references, CORBA -processes will contact the Bootstrap Server to get the Root Naming -Context. - -

Package Specification

- - - -

Related Documentation

- -For an overview and examples of how to use the -CosNaming API, please see: - -

-For an overview of Java IDL, please see: -

- -@since JDK1.3 - - - - - -