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.
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close