- The package and all its classes and interfaces
+ 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.
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
+ 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 interfaces are:
These two interfaces provide the means to bind/unbind names and object
@@ -68,7 +68,7 @@
the idlj compiler creates Java classes that can be thought of
as auxiliary classes.
Comments for the generated auxiliary classes
- used by the interfaces A name is an array of one or more
@@ -159,7 +159,7 @@
If the method Usage is as follows:
The following holder classes are generated for the package
- Note that in the
Note also that there is a
There is only one method in a helper class that an
application programmer uses: the
@@ -282,7 +282,7 @@
Sun's implementation of the
This associates
-Now when an application calls the method
+Now when an application calls the method
Interfaces
- The package org.omg.CosNaming contains two public interfaces
- and several auxiliary classes.
+ The package org.omg.CosNaming contains two public interfaces
+ and several auxiliary classes.
-
NamingContext
+ BindingIterator
NamingContext and
+ used by the interfaces NamingContext and
BindingIterator are included here.
Classes Used by
NamingContext and
@@ -78,7 +78,7 @@
generated for each of the classes listed here, are discussed below.)
-
public final class NameComponent --
+ public final class NameComponent --
a building block for names. (Names are bound to object references
in a naming context.)
NameComponent objects.
@@ -99,7 +99,7 @@
rather than a file extension or some other syntactic convention.
Examples of the value of the kind field include the strings
"c_source", "object_code",
- "executable",
+ "executable",
"postscript", and "". It is not unusual
for the kind field to be the empty string.
@@ -110,7 +110,7 @@
This is similar to a path name, in which the last name is the
file name, and all names before it are directory names.
- public final class Binding --
+ public final class Binding --
an object that associates a name with an object reference or a
naming context.
A Binding object has two fields:
@@ -142,9 +142,9 @@
Binding or used as parameters or return values. These
BindingType objects are:
-
public static final BindingType nobject --
+ public static final BindingType nobject --
to indicate that the binding is with an object reference
- public static final BindingType ncontext --
+ public static final BindingType ncontext --
to indicate that the binding is with a naming context
from_int is supplied with anything other
than _nobject
or _ncontext, it will throw
- the exception org.omg.CORBA.BAD_PARAM.
+ the exception org.omg.CORBA.BAD_PARAM.
BindingType btObject = from_int(_nobject);
@@ -189,7 +189,7 @@
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.
+ it to perform the function of an OUT or INOUT parameter.
org.omg.CosNaming:
@@ -202,17 +202,17 @@
NameHolder
org.omg.CORBA package,
+ Note that in the org.omg.CORBA package,
there is a holder class for each of the basic Java types:
- IntHolder, ShortHolder,
+ IntHolder, ShortHolder,
StringHolder, and so on.
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
+ 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
@@ -245,7 +245,7 @@
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.
+ those types.
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
+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.
@@ -292,18 +292,17 @@
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
+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:
/tmp/services and put the following in it:
- NameService, <Stringified IOR of the Root Naming
-Context>.
+ NameService, <Stringified IOR of the Root Naming Context>.
NameService with the Root Naming
- Context of the CosNaming implementation that you
+ Context of the CosNaming implementation that you
want to use.
@@ -318,7 +317,7 @@
specifying a port number is optional.
org.omg.CORBA.ORB.resolve_initial_references, CORBA
processes will contact the Bootstrap Server to get the Root Naming
Context.
@@ -326,13 +325,13 @@
Package Specification
-
Related Documentation
-For an overview and examples of how to use the
+For an overview and examples of how to use the
CosNaming API, please see: