An AccessException is thrown by certain methods of the java.rmi.Naming class (specifically bind, rebind, and unbind) and methods of the java.rmi.activation.ActivationSystem interface to indicate that the caller does not have permission to perform the action requested by the method call. If the method was invoked from a non-local host, then an AccessException is thrown.
An AccessException is thrown by certain methods of the java.rmi.Naming class (specifically bind, rebind, and unbind) and methods of the java.rmi.activation.ActivationSystem interface to indicate that the caller does not have permission to perform the action requested by the method call. If the method was invoked from a non-local host, then an AccessException is thrown.
The Activatable class provides support for remote objects that require persistent access over time and that can be activated by the system.
For the constructors and static exportObject methods, the stub for a remote object being exported is obtained as described in UnicastRemoteObject.
An attempt to serialize explicitly an instance of this class will fail.
The Activatable class provides support for remote objects that require persistent access over time and that can be activated by the system. For the constructors and static exportObject methods, the stub for a remote object being exported is obtained as described in UnicastRemoteObject. An attempt to serialize explicitly an instance of this class will fail.
This exception is thrown by the RMI runtime when activation fails during a remote call to an activatable object.
This exception is thrown by the RMI runtime when activation fails during a remote call to an activatable object.
An activation descriptor contains the information necessary to activate an object: the object's group identifier, the object's fully-qualified class name, the object's code location (the location of the class), a codebase URL path, the object's restart "mode", and, a "marshalled" object that can contain object specific initialization data.
A descriptor registered with the activation system can be used to recreate/activate the object specified by the descriptor. The MarshalledObject in the object's descriptor is passed as the second argument to the remote object's constructor for object to use during reinitialization/activation.
An activation descriptor contains the information necessary to activate an object: the object's group identifier, the object's fully-qualified class name, the object's code location (the location of the class), a codebase URL path, the object's restart "mode", and, a "marshalled" object that can contain object specific initialization data. A descriptor registered with the activation system can be used to recreate/activate the object specified by the descriptor. The MarshalledObject in the object's descriptor is passed as the second argument to the remote object's constructor for object to use during reinitialization/activation.
General exception used by the activation interfaces.
As of release 1.4, this exception has been retrofitted to conform to the general purpose exception-chaining mechanism. The "detail exception" that may be provided at construction time and accessed via the public detail field is now known as the cause, and may be accessed via the Throwable.getCause() method, as well as the aforementioned "legacy field."
Invoking the method Throwable.initCause(Throwable) on an instance of ActivationException always throws IllegalStateException.
General exception used by the activation interfaces. As of release 1.4, this exception has been retrofitted to conform to the general purpose exception-chaining mechanism. The "detail exception" that may be provided at construction time and accessed via the public detail field is now known as the cause, and may be accessed via the Throwable.getCause() method, as well as the aforementioned "legacy field." Invoking the method Throwable.initCause(Throwable) on an instance of ActivationException always throws IllegalStateException.
An ActivationGroup is responsible for creating new instances of "activatable" objects in its group, informing its ActivationMonitor when either: its object's become active or inactive, or the group as a whole becomes inactive.
An ActivationGroup is initially created in one of several ways: as a side-effect of creating an ActivationDesc without an explicit ActivationGroupID for the first activatable object in the group, or via the ActivationGroup.createGroup method as a side-effect of activating the first object in a group whose ActivationGroupDesc was only registered.
Only the activator can recreate an ActivationGroup. The activator spawns, as needed, a separate VM (as a child process, for example) for each registered activation group and directs activation requests to the appropriate group. It is implementation specific how VMs are spawned. An activation group is created via the ActivationGroup.createGroup static method. The createGroup method has two requirements on the group to be created: 1) the group must be a concrete subclass of ActivationGroup, and 2) the group must have a constructor that takes two arguments:
the group's ActivationGroupID, and the group's initialization data (in a java.rmi.MarshalledObject)
When created, the default implementation of ActivationGroup will override the system properties with the properties requested when its ActivationGroupDesc was created, and will set a SecurityManager as the default system security manager. If your application requires specific properties to be set when objects are activated in the group, the application should create a special Properties object containing these properties, then create an ActivationGroupDesc with the Properties object, and use ActivationGroup.createGroup before creating any ActivationDescs (before the default ActivationGroupDesc is created). If your application requires the use of a security manager other than SecurityManager, in the ActivativationGroupDescriptor properties list you can set java.security.manager property to the name of the security manager you would like to install.
An ActivationGroup is responsible for creating new instances of "activatable" objects in its group, informing its ActivationMonitor when either: its object's become active or inactive, or the group as a whole becomes inactive. An ActivationGroup is initially created in one of several ways: as a side-effect of creating an ActivationDesc without an explicit ActivationGroupID for the first activatable object in the group, or via the ActivationGroup.createGroup method as a side-effect of activating the first object in a group whose ActivationGroupDesc was only registered. Only the activator can recreate an ActivationGroup. The activator spawns, as needed, a separate VM (as a child process, for example) for each registered activation group and directs activation requests to the appropriate group. It is implementation specific how VMs are spawned. An activation group is created via the ActivationGroup.createGroup static method. The createGroup method has two requirements on the group to be created: 1) the group must be a concrete subclass of ActivationGroup, and 2) the group must have a constructor that takes two arguments: the group's ActivationGroupID, and the group's initialization data (in a java.rmi.MarshalledObject) When created, the default implementation of ActivationGroup will override the system properties with the properties requested when its ActivationGroupDesc was created, and will set a SecurityManager as the default system security manager. If your application requires specific properties to be set when objects are activated in the group, the application should create a special Properties object containing these properties, then create an ActivationGroupDesc with the Properties object, and use ActivationGroup.createGroup before creating any ActivationDescs (before the default ActivationGroupDesc is created). If your application requires the use of a security manager other than SecurityManager, in the ActivativationGroupDescriptor properties list you can set java.security.manager property to the name of the security manager you would like to install.
ActivationGroup_Stub is a stub class for the subclasses of java.rmi.activation.ActivationGroup that are exported as a java.rmi.server.UnicastRemoteObject.
ActivationGroup_Stub is a stub class for the subclasses of java.rmi.activation.ActivationGroup that are exported as a java.rmi.server.UnicastRemoteObject.
An activation group descriptor contains the information necessary to create/recreate an activation group in which to activate objects. Such a descriptor contains: the group's class name, the group's code location (the location of the group's class), and a "marshalled" object that can contain group specific initialization data.
The group's class must be a concrete subclass of ActivationGroup. A subclass of ActivationGroup is created/recreated via the ActivationGroup.createGroup static method that invokes a special constructor that takes two arguments:
the group's ActivationGroupID, and the group's initialization data (in a java.rmi.MarshalledObject)
An activation group descriptor contains the information necessary to create/recreate an activation group in which to activate objects. Such a descriptor contains: the group's class name, the group's code location (the location of the group's class), and a "marshalled" object that can contain group specific initialization data. The group's class must be a concrete subclass of ActivationGroup. A subclass of ActivationGroup is created/recreated via the ActivationGroup.createGroup static method that invokes a special constructor that takes two arguments: the group's ActivationGroupID, and the group's initialization data (in a java.rmi.MarshalledObject)
Startup options for ActivationGroup implementations.
This class allows overriding default system properties and specifying implementation-defined options for ActivationGroups.
Startup options for ActivationGroup implementations. This class allows overriding default system properties and specifying implementation-defined options for ActivationGroups.
The identifier for a registered activation group serves several purposes: identifies the group uniquely within the activation system, and contains a reference to the group's activation system so that the group can contact its activation system when necessary.
The ActivationGroupID is returned from the call to ActivationSystem.registerGroup and is used to identify the group within the activation system. This group id is passed as one of the arguments to the activation group's special constructor when an activation group is created/recreated.
The identifier for a registered activation group serves several purposes: identifies the group uniquely within the activation system, and contains a reference to the group's activation system so that the group can contact its activation system when necessary. The ActivationGroupID is returned from the call to ActivationSystem.registerGroup and is used to identify the group within the activation system. This group id is passed as one of the arguments to the activation group's special constructor when an activation group is created/recreated.
Activation makes use of special identifiers to denote remote objects that can be activated over time. An activation identifier (an instance of the class ActivationID) contains several pieces of information needed for activating an object:
a remote reference to the object's activator (a RemoteRef instance), and a unique identifier (a UID instance) for the object.
An activation identifier for an object can be obtained by registering an object with the activation system. Registration is accomplished in a few ways: via the Activatable.register method via the first Activatable constructor (that takes three arguments and both registers and exports the object, and via the first Activatable.exportObject method that takes the activation descriptor, object and port as arguments; this method both registers and exports the object.
Activation makes use of special identifiers to denote remote objects that can be activated over time. An activation identifier (an instance of the class ActivationID) contains several pieces of information needed for activating an object: a remote reference to the object's activator (a RemoteRef instance), and a unique identifier (a UID instance) for the object. An activation identifier for an object can be obtained by registering an object with the activation system. Registration is accomplished in a few ways: via the Activatable.register method via the first Activatable constructor (that takes three arguments and both registers and exports the object, and via the first Activatable.exportObject method that takes the activation descriptor, object and port as arguments; this method both registers and exports the object.
An ActivationInstantiator is responsible for creating instances of "activatable" objects. A concrete subclass of ActivationGroup implements the newInstance method to handle creating objects within the group.
An ActivationInstantiator is responsible for creating instances of "activatable" objects. A concrete subclass of ActivationGroup implements the newInstance method to handle creating objects within the group.
An ActivationMonitor is specific to an ActivationGroup and is obtained when a group is reported active via a call to ActivationSystem.activeGroup (this is done internally). An activation group is responsible for informing its ActivationMonitor when either: its objects become active or inactive, or the group as a whole becomes inactive.
An ActivationMonitor is specific to an ActivationGroup and is obtained when a group is reported active via a call to ActivationSystem.activeGroup (this is done internally). An activation group is responsible for informing its ActivationMonitor when either: its objects become active or inactive, or the group as a whole becomes inactive.
The ActivationSystem provides a means for registering groups and "activatable" objects to be activated within those groups. The ActivationSystem works closely with the Activator, which activates objects registered via the ActivationSystem, and the ActivationMonitor, which obtains information about active and inactive objects, and inactive groups.
The ActivationSystem provides a means for registering groups and "activatable" objects to be activated within those groups. The ActivationSystem works closely with the Activator, which activates objects registered via the ActivationSystem, and the ActivationMonitor, which obtains information about active and inactive objects, and inactive groups.
The Activator facilitates remote object activation. A "faulting" remote reference calls the activator's activate method to obtain a "live" reference to a "activatable" remote object. Upon receiving a request for activation, the activator looks up the activation descriptor for the activation identifier, id, determines the group in which the object should be activated initiates object re-creation via the group's ActivationInstantiator (via a call to the newInstance method). The activator initiates the execution of activation groups as necessary. For example, if an activation group for a specific group identifier is not already executing, the activator initiates the execution of a VM for the group.
The Activator works closely with ActivationSystem, which provides a means for registering groups and objects within those groups, and ActivationMonitor, which recives information about active and inactive objects and inactive groups.
The activator is responsible for monitoring and detecting when activation groups fail so that it can remove stale remote references to groups and active object's within those groups.
The Activator facilitates remote object activation. A "faulting" remote reference calls the activator's activate method to obtain a "live" reference to a "activatable" remote object. Upon receiving a request for activation, the activator looks up the activation descriptor for the activation identifier, id, determines the group in which the object should be activated initiates object re-creation via the group's ActivationInstantiator (via a call to the newInstance method). The activator initiates the execution of activation groups as necessary. For example, if an activation group for a specific group identifier is not already executing, the activator initiates the execution of a VM for the group. The Activator works closely with ActivationSystem, which provides a means for registering groups and objects within those groups, and ActivationMonitor, which recives information about active and inactive objects and inactive groups. The activator is responsible for monitoring and detecting when activation groups fail so that it can remove stale remote references to groups and active object's within those groups.
No vars found in this namespace.
An UnknownGroupException is thrown by methods of classes and interfaces in the java.rmi.activation package when the ActivationGroupID parameter to the method is determined to be invalid, i.e., not known by the ActivationSystem. An UnknownGroupException is also thrown if the ActivationGroupID in an ActivationDesc refers to a group that is not registered with the ActivationSystem
An UnknownGroupException is thrown by methods of classes and interfaces in the java.rmi.activation package when the ActivationGroupID parameter to the method is determined to be invalid, i.e., not known by the ActivationSystem. An UnknownGroupException is also thrown if the ActivationGroupID in an ActivationDesc refers to a group that is not registered with the ActivationSystem
An UnknownObjectException is thrown by methods of classes and interfaces in the java.rmi.activation package when the ActivationID parameter to the method is determined to be invalid. An ActivationID is invalid if it is not currently known by the ActivationSystem. An ActivationID is obtained by the ActivationSystem.registerObject method. An ActivationID is also obtained during the Activatable.register call.
An UnknownObjectException is thrown by methods of classes and interfaces in the java.rmi.activation package when the ActivationID parameter to the method is determined to be invalid. An ActivationID is invalid if it is not currently known by the ActivationSystem. An ActivationID is obtained by the ActivationSystem.registerObject method. An ActivationID is also obtained during the Activatable.register call.
An AlreadyBoundException is thrown if an attempt is made to bind an object in the registry to a name that already has an associated binding.
An AlreadyBoundException is thrown if an attempt is made to bind an object in the registry to a name that already has an associated binding.
A ConnectException is thrown if a connection is refused to the remote host for a remote method call.
A ConnectException is thrown if a connection is refused to the remote host for a remote method call.
A ConnectIOException is thrown if an IOException occurs while making a connection to the remote host for a remote method call.
A ConnectIOException is thrown if an IOException occurs while making a connection to the remote host for a remote method call.
No vars found in this namespace.
No vars found in this namespace.
The DGC abstraction is used for the server side of the distributed garbage collection algorithm. This interface contains the two methods: dirty and clean. A dirty call is made when a remote reference is unmarshaled in a client (the client is indicated by its VMID). A corresponding clean call is made when no more references to the remote reference exist in the client. A failed dirty call must schedule a strong clean call so that the call's sequence number can be retained in order to detect future calls received out of order by the distributed garbage collector.
A reference to a remote object is leased for a period of time by the client holding the reference. The lease period starts when the dirty call is received. It is the client's responsibility to renew the leases, by making additional dirty calls, on the remote references it holds before such leases expire. If the client does not renew the lease before it expires, the distributed garbage collector assumes that the remote object is no longer referenced by that client.
The DGC abstraction is used for the server side of the distributed garbage collection algorithm. This interface contains the two methods: dirty and clean. A dirty call is made when a remote reference is unmarshaled in a client (the client is indicated by its VMID). A corresponding clean call is made when no more references to the remote reference exist in the client. A failed dirty call must schedule a strong clean call so that the call's sequence number can be retained in order to detect future calls received out of order by the distributed garbage collector. A reference to a remote object is leased for a period of time by the client holding the reference. The lease period starts when the dirty call is received. It is the client's responsibility to renew the leases, by making additional dirty calls, on the remote references it holds before such leases expire. If the client does not renew the lease before it expires, the distributed garbage collector assumes that the remote object is no longer referenced by that client.
A lease contains a unique VM identifier and a lease duration. A Lease object is used to request and grant leases to remote object references.
A lease contains a unique VM identifier and a lease duration. A Lease object is used to request and grant leases to remote object references.
A VMID is a identifier that is unique across all Java virtual machines. VMIDs are used by the distributed garbage collector to identify client VMs.
A VMID is a identifier that is unique across all Java virtual machines. VMIDs are used by the distributed garbage collector to identify client VMs.
A MarshalException is thrown if a java.io.IOException occurs while marshalling the remote call header, arguments or return value for a remote method call. A MarshalException is also thrown if the receiver does not support the protocol version of the sender.
If a MarshalException occurs during a remote method call, the call may or may not have reached the server. If the call did reach the server, parameters may have been deserialized. A call may not be retransmitted after a MarshalException and reliably preserve "at most once" call semantics.
A MarshalException is thrown if a java.io.IOException occurs while marshalling the remote call header, arguments or return value for a remote method call. A MarshalException is also thrown if the receiver does not support the protocol version of the sender. If a MarshalException occurs during a remote method call, the call may or may not have reached the server. If the call did reach the server, parameters may have been deserialized. A call may not be retransmitted after a MarshalException and reliably preserve "at most once" call semantics.
A MarshalledObject contains a byte stream with the serialized representation of an object given to its constructor. The get method returns a new copy of the original object, as deserialized from the contained byte stream. The contained object is serialized and deserialized with the same serialization semantics used for marshaling and unmarshaling parameters and return values of RMI calls: When the serialized form is created:
classes are annotated with a codebase URL from where the class can be loaded (if available), and any remote object in the MarshalledObject is represented by a serialized instance of its stub.
When copy of the object is retrieved (via the get method), if the class is not available locally, it will be loaded from the appropriate location (specified the URL annotated with the class descriptor when the class was serialized.
MarshalledObject facilitates passing objects in RMI calls that are not automatically deserialized immediately by the remote peer.
A MarshalledObject contains a byte stream with the serialized representation of an object given to its constructor. The get method returns a new copy of the original object, as deserialized from the contained byte stream. The contained object is serialized and deserialized with the same serialization semantics used for marshaling and unmarshaling parameters and return values of RMI calls: When the serialized form is created: classes are annotated with a codebase URL from where the class can be loaded (if available), and any remote object in the MarshalledObject is represented by a serialized instance of its stub. When copy of the object is retrieved (via the get method), if the class is not available locally, it will be loaded from the appropriate location (specified the URL annotated with the class descriptor when the class was serialized. MarshalledObject facilitates passing objects in RMI calls that are not automatically deserialized immediately by the remote peer.
The Naming class provides methods for storing and obtaining references to remote objects in a remote object registry. Each method of the Naming class takes as one of its arguments a name that is a java.lang.String in URL format (without the scheme component) of the form:
//host:port/name
where host is the host (remote or local) where the registry is located, port is the port number on which the registry accepts calls, and where name is a simple string uninterpreted by the registry. Both host and port are optional. If host is omitted, the host defaults to the local host. If port is omitted, then the port defaults to 1099, the "well-known" port that RMI's registry, rmiregistry, uses.
Binding a name for a remote object is associating or registering a name for a remote object that can be used at a later time to look up that remote object. A remote object can be associated with a name using the Naming class's bind or rebind methods.
Once a remote object is registered (bound) with the RMI registry on the local host, callers on a remote (or local) host can lookup the remote object by name, obtain its reference, and then invoke remote methods on the object. A registry may be shared by all servers running on a host or an individual server process may create and use its own registry if desired (see java.rmi.registry.LocateRegistry.createRegistry method for details).
The Naming class provides methods for storing and obtaining references to remote objects in a remote object registry. Each method of the Naming class takes as one of its arguments a name that is a java.lang.String in URL format (without the scheme component) of the form: //host:port/name where host is the host (remote or local) where the registry is located, port is the port number on which the registry accepts calls, and where name is a simple string uninterpreted by the registry. Both host and port are optional. If host is omitted, the host defaults to the local host. If port is omitted, then the port defaults to 1099, the "well-known" port that RMI's registry, rmiregistry, uses. Binding a name for a remote object is associating or registering a name for a remote object that can be used at a later time to look up that remote object. A remote object can be associated with a name using the Naming class's bind or rebind methods. Once a remote object is registered (bound) with the RMI registry on the local host, callers on a remote (or local) host can lookup the remote object by name, obtain its reference, and then invoke remote methods on the object. A registry may be shared by all servers running on a host or an individual server process may create and use its own registry if desired (see java.rmi.registry.LocateRegistry.createRegistry method for details).
A NoSuchObjectException is thrown if an attempt is made to invoke a method on an object that no longer exists in the remote virtual machine. If a NoSuchObjectException occurs attempting to invoke a method on a remote object, the call may be retransmitted and still preserve RMI's "at most once" call semantics.
A NoSuchObjectException is also thrown by the method java.rmi.server.RemoteObject.toStub and by the unexportObject methods of java.rmi.server.UnicastRemoteObject and java.rmi.activation.Activatable and
A NoSuchObjectException is thrown if an attempt is made to invoke a method on an object that no longer exists in the remote virtual machine. If a NoSuchObjectException occurs attempting to invoke a method on a remote object, the call may be retransmitted and still preserve RMI's "at most once" call semantics. A NoSuchObjectException is also thrown by the method java.rmi.server.RemoteObject.toStub and by the unexportObject methods of java.rmi.server.UnicastRemoteObject and java.rmi.activation.Activatable and
A NotBoundException is thrown if an attempt is made to lookup or unbind in the registry a name that has no associated binding.
A NotBoundException is thrown if an attempt is made to lookup or unbind in the registry a name that has no associated binding.
No vars found in this namespace.
LocateRegistry is used to obtain a reference to a bootstrap remote object registry on a particular host (including the local host), or to create a remote object registry that accepts calls on a specific port.
Note that a getRegistry call does not actually make a connection to the remote host. It simply creates a local reference to the remote registry and will succeed even if no registry is running on the remote host. Therefore, a subsequent method invocation to a remote registry returned as a result of this method may fail.
LocateRegistry is used to obtain a reference to a bootstrap remote object registry on a particular host (including the local host), or to create a remote object registry that accepts calls on a specific port. Note that a getRegistry call does not actually make a connection to the remote host. It simply creates a local reference to the remote registry and will succeed even if no registry is running on the remote host. Therefore, a subsequent method invocation to a remote registry returned as a result of this method may fail.
Registry is a remote interface to a simple remote object registry that provides methods for storing and retrieving remote object references bound with arbitrary string names. The bind, unbind, and rebind methods are used to alter the name bindings in the registry, and the lookup and list methods are used to query the current name bindings.
In its typical usage, a Registry enables RMI client bootstrapping: it provides a simple means for a client to obtain an initial reference to a remote object. Therefore, a registry's remote object implementation is typically exported with a well-known address, such as with a well-known ObjID and TCP port number (default is 1099).
The LocateRegistry class provides a programmatic API for constructing a bootstrap reference to a Registry at a remote address (see the static getRegistry methods) and for creating and exporting a Registry in the current VM on a particular local address (see the static createRegistry methods).
A Registry implementation may choose to restrict access to some or all of its methods (for example, methods that mutate the registry's bindings may be restricted to calls originating from the local host). If a Registry method chooses to deny access for a given invocation, its implementation may throw AccessException, which (because it extends RemoteException) will be wrapped in a ServerException when caught by a remote client.
The names used for bindings in a Registry are pure strings, not parsed. A service which stores its remote reference in a Registry may wish to use a package name as a prefix in the name binding to reduce the likelihood of name collisions in the registry.
Registry is a remote interface to a simple remote object registry that provides methods for storing and retrieving remote object references bound with arbitrary string names. The bind, unbind, and rebind methods are used to alter the name bindings in the registry, and the lookup and list methods are used to query the current name bindings. In its typical usage, a Registry enables RMI client bootstrapping: it provides a simple means for a client to obtain an initial reference to a remote object. Therefore, a registry's remote object implementation is typically exported with a well-known address, such as with a well-known ObjID and TCP port number (default is 1099). The LocateRegistry class provides a programmatic API for constructing a bootstrap reference to a Registry at a remote address (see the static getRegistry methods) and for creating and exporting a Registry in the current VM on a particular local address (see the static createRegistry methods). A Registry implementation may choose to restrict access to some or all of its methods (for example, methods that mutate the registry's bindings may be restricted to calls originating from the local host). If a Registry method chooses to deny access for a given invocation, its implementation may throw AccessException, which (because it extends RemoteException) will be wrapped in a ServerException when caught by a remote client. The names used for bindings in a Registry are pure strings, not parsed. A service which stores its remote reference in a Registry may wish to use a package name as a prefix in the name binding to reduce the likelihood of name collisions in the registry.
Deprecated. no replacement
Deprecated. no replacement
The Remote interface serves to identify interfaces whose methods may be invoked from a non-local virtual machine. Any object that is a remote object must directly or indirectly implement this interface. Only those methods specified in a "remote interface", an interface that extends java.rmi.Remote are available remotely.
Implementation classes can implement any number of remote interfaces and can extend other remote implementation classes. RMI provides some convenience classes that remote object implementations can extend which facilitate remote object creation. These classes are java.rmi.server.UnicastRemoteObject and java.rmi.activation.Activatable.
For complete details on RMI, see the RMI Specification which describes the RMI API and system.
The Remote interface serves to identify interfaces whose methods may be invoked from a non-local virtual machine. Any object that is a remote object must directly or indirectly implement this interface. Only those methods specified in a "remote interface", an interface that extends java.rmi.Remote are available remotely. Implementation classes can implement any number of remote interfaces and can extend other remote implementation classes. RMI provides some convenience classes that remote object implementations can extend which facilitate remote object creation. These classes are java.rmi.server.UnicastRemoteObject and java.rmi.activation.Activatable. For complete details on RMI, see the RMI Specification which describes the RMI API and system.
No vars found in this namespace.
A RemoteException is the common superclass for a number of communication-related exceptions that may occur during the execution of a remote method call. Each method of a remote interface, an interface that extends java.rmi.Remote, must list RemoteException in its throws clause.
As of release 1.4, this exception has been retrofitted to conform to the general purpose exception-chaining mechanism. The "wrapped remote exception" that may be provided at construction time and accessed via the public detail field is now known as the cause, and may be accessed via the Throwable.getCause() method, as well as the aforementioned "legacy field."
Invoking the method Throwable.initCause(Throwable) on an instance of RemoteException always throws IllegalStateException.
A RemoteException is the common superclass for a number of communication-related exceptions that may occur during the execution of a remote method call. Each method of a remote interface, an interface that extends java.rmi.Remote, must list RemoteException in its throws clause. As of release 1.4, this exception has been retrofitted to conform to the general purpose exception-chaining mechanism. The "wrapped remote exception" that may be provided at construction time and accessed via the public detail field is now known as the cause, and may be accessed via the Throwable.getCause() method, as well as the aforementioned "legacy field." Invoking the method Throwable.initCause(Throwable) on an instance of RemoteException always throws IllegalStateException.
Deprecated. Use SecurityException instead. Application code should never directly reference this class, and RMISecurityManager no longer throws this subclass of java.lang.SecurityException.
Deprecated. Use SecurityException instead. Application code should never directly reference this class, and RMISecurityManager no longer throws this subclass of java.lang.SecurityException.
Deprecated. Use SecurityManager instead.
Deprecated. Use SecurityManager instead.
No vars found in this namespace.
An ExportException is a RemoteException thrown if an attempt to export a remote object fails. A remote object is exported via the constructors and exportObject methods of java.rmi.server.UnicastRemoteObject and java.rmi.activation.Activatable.
An ExportException is a RemoteException thrown if an attempt to export a remote object fails. A remote object is exported via the constructors and exportObject methods of java.rmi.server.UnicastRemoteObject and java.rmi.activation.Activatable.
Deprecated. no replacement
Deprecated. no replacement
Deprecated. no replacement
Deprecated. no replacement
An ObjID is used to identify a remote object exported to an RMI runtime. When a remote object is exported, it is assigned an object identifier either implicitly or explicitly, depending on the API used to export.
The ObjID() constructor can be used to generate a unique object identifier. Such an ObjID is unique over time with respect to the host it is generated on.
The ObjID(int) constructor can be used to create a "well-known" object identifier. The scope of a well-known ObjID depends on the RMI runtime it is exported to.
An ObjID instance contains an object number (of type long) and an address space identifier (of type UID). In a unique ObjID, the address space identifier is unique with respect to a given host over time. In a well-known ObjID, the address space identifier is equivalent to one returned by invoking the UID.UID(short) constructor with the value zero.
If the system property java.rmi.server.randomIDs is defined to equal the string "true" (case insensitive), then the ObjID() constructor will use a cryptographically strong random number generator to choose the object number of the returned ObjID.
An ObjID is used to identify a remote object exported to an RMI runtime. When a remote object is exported, it is assigned an object identifier either implicitly or explicitly, depending on the API used to export. The ObjID() constructor can be used to generate a unique object identifier. Such an ObjID is unique over time with respect to the host it is generated on. The ObjID(int) constructor can be used to create a "well-known" object identifier. The scope of a well-known ObjID depends on the RMI runtime it is exported to. An ObjID instance contains an object number (of type long) and an address space identifier (of type UID). In a unique ObjID, the address space identifier is unique with respect to a given host over time. In a well-known ObjID, the address space identifier is equivalent to one returned by invoking the UID.UID(short) constructor with the value zero. If the system property java.rmi.server.randomIDs is defined to equal the string "true" (case insensitive), then the ObjID() constructor will use a cryptographically strong random number generator to choose the object number of the returned ObjID.
Deprecated. no replacement
Deprecated. no replacement
Deprecated. no replacement.
Deprecated. no replacement.
The RemoteObject class implements the java.lang.Object behavior for remote objects. RemoteObject provides the remote semantics of Object by implementing methods for hashCode, equals, and toString.
The RemoteObject class implements the java.lang.Object behavior for remote objects. RemoteObject provides the remote semantics of Object by implementing methods for hashCode, equals, and toString.
An implementation of the InvocationHandler interface for use with Java Remote Method Invocation (Java RMI). This invocation handler can be used in conjunction with a dynamic proxy instance as a replacement for a pregenerated stub class.
Applications are not expected to use this class directly. A remote object exported to use a dynamic proxy with UnicastRemoteObject or Activatable has an instance of this class as that proxy's invocation handler.
An implementation of the InvocationHandler interface for use with Java Remote Method Invocation (Java RMI). This invocation handler can be used in conjunction with a dynamic proxy instance as a replacement for a pregenerated stub class. Applications are not expected to use this class directly. A remote object exported to use a dynamic proxy with UnicastRemoteObject or Activatable has an instance of this class as that proxy's invocation handler.
RemoteRef represents the handle for a remote object. A RemoteStub uses a remote reference to carry out a remote method invocation to a remote object.
RemoteRef represents the handle for a remote object. A RemoteStub uses a remote reference to carry out a remote method invocation to a remote object.
The RemoteServer class is the common superclass to server implementations and provides the framework to support a wide range of remote reference semantics. Specifically, the functions needed to create and export remote objects (i.e. to make them remotely available) are provided abstractly by RemoteServer and concretely by its subclass(es).
The RemoteServer class is the common superclass to server implementations and provides the framework to support a wide range of remote reference semantics. Specifically, the functions needed to create and export remote objects (i.e. to make them remotely available) are provided abstractly by RemoteServer and concretely by its subclass(es).
Deprecated. Statically generated stubs are deprecated, since stubs are generated dynamically. See UnicastRemoteObject for information about dynamic stub generation.
Deprecated. Statically generated stubs are deprecated, since stubs are generated dynamically. See UnicastRemoteObject for information about dynamic stub generation.
No vars found in this namespace.
RMIClassLoader comprises static methods to support dynamic class loading with RMI. Included are methods for loading classes from a network location (one or more URLs) and obtaining the location from which an existing class should be loaded by remote parties. These methods are used by the RMI runtime when marshalling and unmarshalling classes contained in the arguments and return values of remote method calls, and they also may be invoked directly by applications in order to mimic RMI's dynamic class loading behavior.
The implementation of the following static methods
loadClass(URL,String) loadClass(String,String) loadClass(String,String,ClassLoader) loadProxyClass(String,String[],ClassLoader) getClassLoader(String) getClassAnnotation(Class)
is provided by an instance of RMIClassLoaderSpi, the service provider interface for those methods. When one of the methods is invoked, its behavior is to delegate to a corresponding method on the service provider instance. The details of how each method delegates to the provider instance is described in the documentation for each particular method.
The service provider instance is chosen as follows:
If the system property java.rmi.server.RMIClassLoaderSpi is defined, then if its value equals the string "default", the provider instance will be the value returned by an invocation of the getDefaultProviderInstance() method, and for any other value, if a class named with the value of the property can be loaded by the system class loader (see ClassLoader.getSystemClassLoader()) and that class is assignable to RMIClassLoaderSpi and has a public no-argument constructor, then that constructor will be invoked to create the provider instance. If the property is defined but any other of those conditions are not true, then an unspecified Error will be thrown to code that attempts to use RMIClassLoader, indicating the failure to obtain a provider instance.
If a resource named META-INF/services/java.rmi.server.RMIClassLoaderSpi is visible to the system class loader, then the contents of that resource are interpreted as a provider-configuration file, and the first class name specified in that file is used as the provider class name. If a class with that name can be loaded by the system class loader and that class is assignable to RMIClassLoaderSpi and has a public no-argument constructor, then that constructor will be invoked to create the provider instance. If the resource is found but a provider cannot be instantiated as described, then an unspecified Error will be thrown to code that attempts to use RMIClassLoader, indicating the failure to obtain a provider instance.
Otherwise, the provider instance will be the value returned by an invocation of the getDefaultProviderInstance() method.
RMIClassLoader comprises static methods to support dynamic class loading with RMI. Included are methods for loading classes from a network location (one or more URLs) and obtaining the location from which an existing class should be loaded by remote parties. These methods are used by the RMI runtime when marshalling and unmarshalling classes contained in the arguments and return values of remote method calls, and they also may be invoked directly by applications in order to mimic RMI's dynamic class loading behavior. The implementation of the following static methods loadClass(URL,String) loadClass(String,String) loadClass(String,String,ClassLoader) loadProxyClass(String,String[],ClassLoader) getClassLoader(String) getClassAnnotation(Class) is provided by an instance of RMIClassLoaderSpi, the service provider interface for those methods. When one of the methods is invoked, its behavior is to delegate to a corresponding method on the service provider instance. The details of how each method delegates to the provider instance is described in the documentation for each particular method. The service provider instance is chosen as follows: If the system property java.rmi.server.RMIClassLoaderSpi is defined, then if its value equals the string "default", the provider instance will be the value returned by an invocation of the getDefaultProviderInstance() method, and for any other value, if a class named with the value of the property can be loaded by the system class loader (see ClassLoader.getSystemClassLoader()) and that class is assignable to RMIClassLoaderSpi and has a public no-argument constructor, then that constructor will be invoked to create the provider instance. If the property is defined but any other of those conditions are not true, then an unspecified Error will be thrown to code that attempts to use RMIClassLoader, indicating the failure to obtain a provider instance. If a resource named META-INF/services/java.rmi.server.RMIClassLoaderSpi is visible to the system class loader, then the contents of that resource are interpreted as a provider-configuration file, and the first class name specified in that file is used as the provider class name. If a class with that name can be loaded by the system class loader and that class is assignable to RMIClassLoaderSpi and has a public no-argument constructor, then that constructor will be invoked to create the provider instance. If the resource is found but a provider cannot be instantiated as described, then an unspecified Error will be thrown to code that attempts to use RMIClassLoader, indicating the failure to obtain a provider instance. Otherwise, the provider instance will be the value returned by an invocation of the getDefaultProviderInstance() method.
RMIClassLoaderSpi is the service provider interface for RMIClassLoader.
In particular, an RMIClassLoaderSpi instance provides an implementation of the following static methods of RMIClassLoader:
RMIClassLoader.loadClass(URL,String) RMIClassLoader.loadClass(String,String) RMIClassLoader.loadClass(String,String,ClassLoader) RMIClassLoader.loadProxyClass(String,String[],ClassLoader) RMIClassLoader.getClassLoader(String) RMIClassLoader.getClassAnnotation(Class)
When one of those methods is invoked, its behavior is to delegate to a corresponding method on an instance of this class. The details of how each method delegates to the provider instance is described in the documentation for each particular method. See the documentation for RMIClassLoader for a description of how a provider instance is chosen.
RMIClassLoaderSpi is the service provider interface for RMIClassLoader. In particular, an RMIClassLoaderSpi instance provides an implementation of the following static methods of RMIClassLoader: RMIClassLoader.loadClass(URL,String) RMIClassLoader.loadClass(String,String) RMIClassLoader.loadClass(String,String,ClassLoader) RMIClassLoader.loadProxyClass(String,String[],ClassLoader) RMIClassLoader.getClassLoader(String) RMIClassLoader.getClassAnnotation(Class) When one of those methods is invoked, its behavior is to delegate to a corresponding method on an instance of this class. The details of how each method delegates to the provider instance is described in the documentation for each particular method. See the documentation for RMIClassLoader for a description of how a provider instance is chosen.
An RMIClientSocketFactory instance is used by the RMI runtime in order to obtain client sockets for RMI calls. A remote object can be associated with an RMIClientSocketFactory when it is created/exported via the constructors or exportObject methods of java.rmi.server.UnicastRemoteObject and java.rmi.activation.Activatable .
An RMIClientSocketFactory instance associated with a remote object will be downloaded to clients when the remote object's reference is transmitted in an RMI call. This RMIClientSocketFactory will be used to create connections to the remote object for remote method calls.
An RMIClientSocketFactory instance can also be associated with a remote object registry so that clients can use custom socket communication with a remote object registry.
An implementation of this interface should be serializable and should implement Object.equals(java.lang.Object) to return true when passed an instance that represents the same (functionally equivalent) client socket factory, and false otherwise (and it should also implement Object.hashCode() consistently with its Object.equals implementation).
An RMIClientSocketFactory instance is used by the RMI runtime in order to obtain client sockets for RMI calls. A remote object can be associated with an RMIClientSocketFactory when it is created/exported via the constructors or exportObject methods of java.rmi.server.UnicastRemoteObject and java.rmi.activation.Activatable . An RMIClientSocketFactory instance associated with a remote object will be downloaded to clients when the remote object's reference is transmitted in an RMI call. This RMIClientSocketFactory will be used to create connections to the remote object for remote method calls. An RMIClientSocketFactory instance can also be associated with a remote object registry so that clients can use custom socket communication with a remote object registry. An implementation of this interface should be serializable and should implement Object.equals(java.lang.Object) to return true when passed an instance that represents the same (functionally equivalent) client socket factory, and false otherwise (and it should also implement Object.hashCode() consistently with its Object.equals implementation).
An RMIFailureHandler can be registered via the RMISocketFactory.setFailureHandler call. The failure method of the handler is invoked when the RMI runtime is unable to create a ServerSocket to listen for incoming calls. The failure method returns a boolean indicating whether the runtime should attempt to re-create the ServerSocket.
An RMIFailureHandler can be registered via the RMISocketFactory.setFailureHandler call. The failure method of the handler is invoked when the RMI runtime is unable to create a ServerSocket to listen for incoming calls. The failure method returns a boolean indicating whether the runtime should attempt to re-create the ServerSocket.
An RMIServerSocketFactory instance is used by the RMI runtime in order to obtain server sockets for RMI calls. A remote object can be associated with an RMIServerSocketFactory when it is created/exported via the constructors or exportObject methods of java.rmi.server.UnicastRemoteObject and java.rmi.activation.Activatable .
An RMIServerSocketFactory instance associated with a remote object is used to obtain the ServerSocket used to accept incoming calls from clients.
An RMIServerSocketFactory instance can also be associated with a remote object registry so that clients can use custom socket communication with a remote object registry.
An implementation of this interface should implement Object.equals(java.lang.Object) to return true when passed an instance that represents the same (functionally equivalent) server socket factory, and false otherwise (and it should also implement Object.hashCode() consistently with its Object.equals implementation).
An RMIServerSocketFactory instance is used by the RMI runtime in order to obtain server sockets for RMI calls. A remote object can be associated with an RMIServerSocketFactory when it is created/exported via the constructors or exportObject methods of java.rmi.server.UnicastRemoteObject and java.rmi.activation.Activatable . An RMIServerSocketFactory instance associated with a remote object is used to obtain the ServerSocket used to accept incoming calls from clients. An RMIServerSocketFactory instance can also be associated with a remote object registry so that clients can use custom socket communication with a remote object registry. An implementation of this interface should implement Object.equals(java.lang.Object) to return true when passed an instance that represents the same (functionally equivalent) server socket factory, and false otherwise (and it should also implement Object.hashCode() consistently with its Object.equals implementation).
An RMISocketFactory instance is used by the RMI runtime in order to obtain client and server sockets for RMI calls. An application may use the setSocketFactory method to request that the RMI runtime use its socket factory instance instead of the default implementation.
The default socket factory implementation performs a three-tiered approach to creating client sockets. First, a direct socket connection to the remote VM is attempted. If that fails (due to a firewall), the runtime uses HTTP with the explicit port number of the server. If the firewall does not allow this type of communication, then HTTP to a cgi-bin script on the server is used to POST the RMI call. The HTTP tunneling mechanisms are disabled by default. This behavior is controlled by the java.rmi.server.disableHttp property, whose default value is true. Setting this property's value to false will enable the HTTP tunneling mechanisms.
Deprecated: HTTP Tunneling. The HTTP tunneling mechanisms described above, specifically HTTP with an explicit port and HTTP to a cgi-bin script, are deprecated. These HTTP tunneling mechanisms are subject to removal in a future release of the platform.
The default socket factory implementation creates server sockets that are bound to the wildcard address, which accepts requests from all network interfaces.
An RMISocketFactory instance is used by the RMI runtime in order to obtain client and server sockets for RMI calls. An application may use the setSocketFactory method to request that the RMI runtime use its socket factory instance instead of the default implementation. The default socket factory implementation performs a three-tiered approach to creating client sockets. First, a direct socket connection to the remote VM is attempted. If that fails (due to a firewall), the runtime uses HTTP with the explicit port number of the server. If the firewall does not allow this type of communication, then HTTP to a cgi-bin script on the server is used to POST the RMI call. The HTTP tunneling mechanisms are disabled by default. This behavior is controlled by the java.rmi.server.disableHttp property, whose default value is true. Setting this property's value to false will enable the HTTP tunneling mechanisms. Deprecated: HTTP Tunneling. The HTTP tunneling mechanisms described above, specifically HTTP with an explicit port and HTTP to a cgi-bin script, are deprecated. These HTTP tunneling mechanisms are subject to removal in a future release of the platform. The default socket factory implementation creates server sockets that are bound to the wildcard address, which accepts requests from all network interfaces.
A ServerCloneException is thrown if a remote exception occurs during the cloning of a UnicastRemoteObject.
As of release 1.4, this exception has been retrofitted to conform to the general purpose exception-chaining mechanism. The "nested exception" that may be provided at construction time and accessed via the public detail field is now known as the cause, and may be accessed via the Throwable.getCause() method, as well as the aforementioned "legacy field."
Invoking the method Throwable.initCause(Throwable) on an instance of ServerCloneException always throws IllegalStateException.
A ServerCloneException is thrown if a remote exception occurs during the cloning of a UnicastRemoteObject. As of release 1.4, this exception has been retrofitted to conform to the general purpose exception-chaining mechanism. The "nested exception" that may be provided at construction time and accessed via the public detail field is now known as the cause, and may be accessed via the Throwable.getCause() method, as well as the aforementioned "legacy field." Invoking the method Throwable.initCause(Throwable) on an instance of ServerCloneException always throws IllegalStateException.
An ServerNotActiveException is an Exception thrown during a call to RemoteServer.getClientHost if the getClientHost method is called outside of servicing a remote method call.
An ServerNotActiveException is an Exception thrown during a call to RemoteServer.getClientHost if the getClientHost method is called outside of servicing a remote method call.
Deprecated. No replacement. This interface is unused and is obsolete.
Deprecated. No replacement. This interface is unused and is obsolete.
Deprecated. no replacement. Skeletons are no longer required for remote method calls in the Java 2 platform v1.2 and greater.
Deprecated. no replacement. Skeletons are no longer required for remote method calls in the Java 2 platform v1.2 and greater.
Deprecated. no replacement. Skeletons are no longer required for remote method calls in the Java 2 platform v1.2 and greater.
Deprecated. no replacement. Skeletons are no longer required for remote method calls in the Java 2 platform v1.2 and greater.
Deprecated. no replacement. Skeletons are no longer required for remote method calls in the Java 2 platform v1.2 and greater.
Deprecated. no replacement. Skeletons are no longer required for remote method calls in the Java 2 platform v1.2 and greater.
Deprecated. This class is obsolete. Use ExportException instead.
Deprecated. This class is obsolete. Use ExportException instead.
A UID represents an identifier that is unique over time with respect to the host it is generated on, or one of 216 "well-known" identifiers.
The UID() constructor can be used to generate an identifier that is unique over time with respect to the host it is generated on. The UID(short) constructor can be used to create one of 216 well-known identifiers.
A UID instance contains three primitive values:
unique, an int that uniquely identifies the VM that this UID was generated in, with respect to its host and at the time represented by the time value (an example implementation of the unique value would be a process identifier), or zero for a well-known UID time, a long equal to a time (as returned by System.currentTimeMillis()) at which the VM that this UID was generated in was alive, or zero for a well-known UID count, a short to distinguish UIDs generated in the same VM with the same time value
An independently generated UID instance is unique over time with respect to the host it is generated on as long as the host requires more than one millisecond to reboot and its system clock is never set backward. A globally unique identifier can be constructed by pairing a UID instance with a unique host identifier, such as an IP address.
A UID represents an identifier that is unique over time with respect to the host it is generated on, or one of 216 "well-known" identifiers. The UID() constructor can be used to generate an identifier that is unique over time with respect to the host it is generated on. The UID(short) constructor can be used to create one of 216 well-known identifiers. A UID instance contains three primitive values: unique, an int that uniquely identifies the VM that this UID was generated in, with respect to its host and at the time represented by the time value (an example implementation of the unique value would be a process identifier), or zero for a well-known UID time, a long equal to a time (as returned by System.currentTimeMillis()) at which the VM that this UID was generated in was alive, or zero for a well-known UID count, a short to distinguish UIDs generated in the same VM with the same time value An independently generated UID instance is unique over time with respect to the host it is generated on as long as the host requires more than one millisecond to reboot and its system clock is never set backward. A globally unique identifier can be constructed by pairing a UID instance with a unique host identifier, such as an IP address.
Used for exporting a remote object with JRMP and obtaining a stub that communicates to the remote object. Stubs are either generated at runtime using dynamic proxy objects, or they are generated statically at build time, typically using the rmic tool.
Deprecated: Static Stubs. Support for statically generated stubs is deprecated. This includes the API in this class that requires the use of static stubs, as well as the runtime support for loading static stubs. Generating stubs dynamically is preferred, using one of the five non-deprecated ways of exporting objects as listed below. Do not run rmic to generate static stub classes. It is unnecessary, and it is also deprecated.
There are six ways to export remote objects:
Subclassing UnicastRemoteObject and calling the UnicastRemoteObject() constructor.
Subclassing UnicastRemoteObject and calling the UnicastRemoteObject(port) constructor.
Subclassing UnicastRemoteObject and calling the UnicastRemoteObject(port, csf, ssf) constructor.
Calling the exportObject(Remote) method. Deprecated.
Calling the exportObject(Remote, port) method.
Calling the exportObject(Remote, port, csf, ssf) method.
The fourth technique, exportObject(Remote), always uses statically generated stubs and is deprecated.
The other five techniques all use the following approach: if the java.rmi.server.ignoreStubClasses property is true (case insensitive) or if a static stub cannot be found, stubs are generated dynamically using Proxy objects. Otherwise, static stubs are used.
The default value of the java.rmi.server.ignoreStubClasses property is false.
Statically generated stubs are typically pregenerated from the remote object's class using the rmic tool. A static stub is loaded and an instance of that stub class is constructed as described below.
A "root class" is determined as follows: if the remote object's class directly implements an interface that extends Remote, then the remote object's class is the root class; otherwise, the root class is the most derived superclass of the remote object's class that directly implements an interface that extends Remote.
The name of the stub class to load is determined by concatenating the binary name of the root class with the suffix _Stub.
The stub class is loaded by name using the class loader of the root class. The stub class must extend RemoteStub and must have a public constructor that has one parameter of type RemoteRef.
Finally, an instance of the stub class is constructed with a RemoteRef.
If the appropriate stub class could not be found, or if the stub class could not be loaded, or if a problem occurs creating the stub instance, a StubNotFoundException is thrown.
Stubs are dynamically generated by constructing an instance of a Proxy with the following characteristics:
The proxy's class is defined by the class loader of the remote object's class.
The proxy implements all the remote interfaces implemented by the remote object's class.
The proxy's invocation handler is a RemoteObjectInvocationHandler instance constructed with a RemoteRef.
If the proxy could not be created, a StubNotFoundException will be thrown.
Used for exporting a remote object with JRMP and obtaining a stub that communicates to the remote object. Stubs are either generated at runtime using dynamic proxy objects, or they are generated statically at build time, typically using the rmic tool. Deprecated: Static Stubs. Support for statically generated stubs is deprecated. This includes the API in this class that requires the use of static stubs, as well as the runtime support for loading static stubs. Generating stubs dynamically is preferred, using one of the five non-deprecated ways of exporting objects as listed below. Do not run rmic to generate static stub classes. It is unnecessary, and it is also deprecated. There are six ways to export remote objects: Subclassing UnicastRemoteObject and calling the UnicastRemoteObject() constructor. Subclassing UnicastRemoteObject and calling the UnicastRemoteObject(port) constructor. Subclassing UnicastRemoteObject and calling the UnicastRemoteObject(port, csf, ssf) constructor. Calling the exportObject(Remote) method. Deprecated. Calling the exportObject(Remote, port) method. Calling the exportObject(Remote, port, csf, ssf) method. The fourth technique, exportObject(Remote), always uses statically generated stubs and is deprecated. The other five techniques all use the following approach: if the java.rmi.server.ignoreStubClasses property is true (case insensitive) or if a static stub cannot be found, stubs are generated dynamically using Proxy objects. Otherwise, static stubs are used. The default value of the java.rmi.server.ignoreStubClasses property is false. Statically generated stubs are typically pregenerated from the remote object's class using the rmic tool. A static stub is loaded and an instance of that stub class is constructed as described below. A "root class" is determined as follows: if the remote object's class directly implements an interface that extends Remote, then the remote object's class is the root class; otherwise, the root class is the most derived superclass of the remote object's class that directly implements an interface that extends Remote. The name of the stub class to load is determined by concatenating the binary name of the root class with the suffix _Stub. The stub class is loaded by name using the class loader of the root class. The stub class must extend RemoteStub and must have a public constructor that has one parameter of type RemoteRef. Finally, an instance of the stub class is constructed with a RemoteRef. If the appropriate stub class could not be found, or if the stub class could not be loaded, or if a problem occurs creating the stub instance, a StubNotFoundException is thrown. Stubs are dynamically generated by constructing an instance of a Proxy with the following characteristics: The proxy's class is defined by the class loader of the remote object's class. The proxy implements all the remote interfaces implemented by the remote object's class. The proxy's invocation handler is a RemoteObjectInvocationHandler instance constructed with a RemoteRef. If the proxy could not be created, a StubNotFoundException will be thrown.
A remote object implementation should implement the Unreferenced interface to receive notification when there are no more clients that reference that remote object.
A remote object implementation should implement the Unreferenced interface to receive notification when there are no more clients that reference that remote object.
A ServerError is thrown as a result of a remote method invocation when an Error is thrown while processing the invocation on the server, either while unmarshalling the arguments, executing the remote method itself, or marshalling the return value.
A ServerError instance contains the original Error that occurred as its cause.
A ServerError is thrown as a result of a remote method invocation when an Error is thrown while processing the invocation on the server, either while unmarshalling the arguments, executing the remote method itself, or marshalling the return value. A ServerError instance contains the original Error that occurred as its cause.
A ServerException is thrown as a result of a remote method invocation when a RemoteException is thrown while processing the invocation on the server, either while unmarshalling the arguments or executing the remote method itself.
A ServerException instance contains the original RemoteException that occurred as its cause.
A ServerException is thrown as a result of a remote method invocation when a RemoteException is thrown while processing the invocation on the server, either while unmarshalling the arguments or executing the remote method itself. A ServerException instance contains the original RemoteException that occurred as its cause.
Deprecated. no replacement
Deprecated. no replacement
A StubNotFoundException is thrown if a valid stub class could not be found for a remote object when it is exported. A StubNotFoundException may also be thrown when an activatable object is registered via the java.rmi.activation.Activatable.register method.
A StubNotFoundException is thrown if a valid stub class could not be found for a remote object when it is exported. A StubNotFoundException may also be thrown when an activatable object is registered via the java.rmi.activation.Activatable.register method.
An UnexpectedException is thrown if the client of a remote method call receives, as a result of the call, a checked exception that is not among the checked exception types declared in the throws clause of the method in the remote interface.
An UnexpectedException is thrown if the client of a remote method call receives, as a result of the call, a checked exception that is not among the checked exception types declared in the throws clause of the method in the remote interface.
An UnknownHostException is thrown if a java.net.UnknownHostException occurs while creating a connection to the remote host for a remote method call.
An UnknownHostException is thrown if a java.net.UnknownHostException occurs while creating a connection to the remote host for a remote method call.
An UnmarshalException can be thrown while unmarshalling the parameters or results of a remote method call if any of the following conditions occur:
if an exception occurs while unmarshalling the call header if the protocol for the return value is invalid if a java.io.IOException occurs unmarshalling parameters (on the server side) or the return value (on the client side). if a java.lang.ClassNotFoundException occurs during unmarshalling parameters or return values if no skeleton can be loaded on the server-side; note that skeletons are required in the 1.1 stub protocol, but not in the 1.2 stub protocol. if the method hash is invalid (i.e., missing method). if there is a failure to create a remote reference object for a remote object's stub when it is unmarshalled.
An UnmarshalException can be thrown while unmarshalling the parameters or results of a remote method call if any of the following conditions occur: if an exception occurs while unmarshalling the call header if the protocol for the return value is invalid if a java.io.IOException occurs unmarshalling parameters (on the server side) or the return value (on the client side). if a java.lang.ClassNotFoundException occurs during unmarshalling parameters or return values if no skeleton can be loaded on the server-side; note that skeletons are required in the 1.1 stub protocol, but not in the 1.2 stub protocol. if the method hash is invalid (i.e., missing method). if there is a failure to create a remote reference object for a remote object's stub when it is unmarshalled.
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close