Although the Registry implementation uses rmi underneath, the rmi registry is fully encapsulated inside the Registry and RegistryLocator to avoid any confusion in the agent programs and other programs accessing the registry. @author Shanti Subrmanyam
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 {@link java.rmi.server.ObjID#REGISTRY_ID ObjID} and TCP port number(default is {@link #REGISTRY_PORT 1099}).
The {@link LocateRegistry} class provides a programmatic API forconstructing 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 {@link java.rmi.AccessException}, which (because it extends {@link java.rmi.RemoteException}) will be wrapped in a {@link java.rmi.ServerException} when caught by aremote 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.
@author Ann Wollrath
@author Peter Jones
@since JDK1.1
@see LocateRegistry
Multiple content handlers can be registered for each type, suffix, and action. The types, suffixes, and actions registered for a handler can be used to select a handler. The content handler ID is set during registration and is used to uniquely identify the content handler and to enforce access controls.
A content handler is any application that is registered to handle some content. It responds to requests and displays or acts on the content. Registration can occur dynamically or statically. Static registration occurs during the installation of the application package, while dynamic registration occurs via this API. A content handler may be a Java or a non-Java application. For example, MIDlet suites and Personal Basis Profile applications using the Xlet application model can be content handlers. Refer to the {@link ContentHandler ContentHandler}class for information on registering Java platform content handlers.
When a content handler is processing an invocation, it may be necessary to invoke another content handler before it is able to satisfy the first request. The invocation and chaining of content handlers is managed to maintain the context and sequence across application executions.
The term application is used more generally than the term content handler. The term application is used to refer to the common handling for making requests, handling responses, and querying the content handler registrations. The term content handler is used for an application that registers for types, suffixes, actions, etc. and processes the requests queued to it.
A content handler can register a set of types that it can handle. Content types are simple opaque strings that are NOT case sensitive. Type strings are not case sensitive, types that differ only by case are treated as a single type.
A content handler can register a set of suffixes that identify from the syntax of a URL the content it can handle. Suffixes are NOT case sensitive.
Each content handler may register a set of actions it supports. The set of actions is extensible but applications should choose from the actions defined in the {@link ContentHandler} class when they are appropriate. The predefined actions are: {@link ContentHandler#ACTION_OPEN open}, {@link ContentHandler#ACTION_EDIT edit}, {@link ContentHandler#ACTION_NEW new}, {@link ContentHandler#ACTION_SEND send}, {@link ContentHandler#ACTION_SAVE save}, {@link ContentHandler#ACTION_EXECUTE execute}, {@link ContentHandler#ACTION_SELECT select}, {@link ContentHandler#ACTION_INSTALL install}, {@link ContentHandler#ACTION_PRINT print}, and {@link ContentHandler#ACTION_STOP stop}.
The content handler ID is a string chosen by the application vendor to identify the content handler. The ID registered by a content handler MUST be unique and MUST NOT match the prefix of any other registered content handler. IDs are case sensitive and are treated as opaque strings. They are compared for equality or as prefixes of IDs when used to locate an appropriate content handler.
Content handler IDs should follow the form of fully qualified Java class names or any naming syntax that provides a natural way to disambiguate between vendors. For example, IDs may be URLs including scheme, authority (server), and path information.
For example, if registered in the order below, the following content handler IDs would be valid or invalid as indicated because there is an ambiguity due to prefix comparisons.
com.sun.applications.calc - validcom.sun.applications.trig - validcom.sun.application - invalid, this is the prefix of the calc IDcom.sun.applications.calc.decimal - invalid, the calc ID is prefix of decimalThe content handler to be launched is identified by the application class. The class MUST contain entry point(s) and be packaged according to the Java runtime environment. For MIDP, the application class MUST extend javax.microedition.midlet.MIDlet. The application class uniquely identifies a content handler within the application package, which is usually a JAR file. Each application class can only be registered to a single content handler. Registering a content handler for a class will replace any content handler previously registered to that class.
While processing an invocation request the content handler can use the {@link Invocation#getInvokingAuthority Invocation.getInvokingAuthority} method to verify the authenticity of the invoking application.
java.lang.string.startsWith method was used. The access controls are only visible to the content handler itself using the method {@link ContentHandlerServer#getAccessAllowed ContentHandlerServer.getAccessAllowed}. By default, access is allowed to all applications and content handlers. Access restrictions are established when the content handler is registered with the {@link #register register} method.Dynamic registration is performed by initializing the classname, types, suffixes, actions, action names, ID, and access restrictions, and passing them to the {@link #register register} method.The {@link #unregister unregister} method removesa registered content handler.
The current registrations can be examined by using various methods to get the {@link #getTypes types}, {@link #getIDs IDs}, {@link #getSuffixes suffixes}, {@link #getActions actions}, or to find a content handler by content handler {@link #getServer classname}, or to get all of the matching content handlers by {@link #forID ID}, by {@link #forType content type}, by {@link #forSuffix suffix}, or by {@link #forAction action}. Only content handlers that are accessible and visible to the application will be returned.
To invoke a content handler, an application initializes an Invocation instance with the information needed to identify the content and/or the content handler. Typically this could include the URL, type, action, and content handler ID. The application may also supply arguments and data, and set whether a response is required. The application may request information about the content and the content handler that will process it before invocation. Calling the {@link Registry#invoke Registry.invoke} methodstarts the request.
When invoked, the ID, type, URL, and action are used to identify a target content handler. If multiple content handlers are registered for the ID, type, suffixes or action, the implementation can decide which to use to satisfy the request. If the application needs to select which handler to use, the {@link Registry#findHandler findHandler} method willreturn the set of matching ContentHandlers. The application can choose from the content handlers returned and use {@link Invocation#setID Invocation.setID}to select a specific handler.
In a runtime environment in which only a single application can run at a time, the invoking application must exit before the content handler can be started to handle the request. Invocation requests are queued so that the invoking application and the content handler can be run sequentially in resource-constrained environments. The return value of {@link Registry#invoke invoke}is true to indicate that the application must exit. This allows the invoking application to save the users context and leave the user interface, if any, with some visual that the user will see until the content handler is ready.
Invocation processing involves the invoking application, the invoked content handler, and the application management software (AMS). The implementation of the API and the AMS MUST implement the queuing of invocations to the appropriate content handler and the necessary interactions with the lifecycle to start and restart applications and content handlers.
The {@link Registry#invoke invoke} methods initiate the request.The URL, type, action, and ID, as described above, are used to dispatch the request to an appropriate content handler. If the content handler is not running, it MUST be started to process the request. If the content handler is already running, then the new request MUST be queued to the content handler. Only a single instance of each content handler application can be active at a time. The {@link ContentHandlerServer} class is used to dequeue and processrequests.
@author Howard Lewis Ship
Registry provides a simple interface for binding and retrieving remote object references by name.
@author Tim Anderson
@version $Revision: 1.1 $ $Date: 2004/11/26 01:51:05 $
For example the PDF key and URI might be put in this registry. Also queue length perhaps.
The collection of schemas.
@author John JenkinsRegistries are primarily used for inter {@link ratpack.handling.Handler} communication in request processing.The {@link ratpack.handling.Context} object that handlers operate on implements the {@link ratpack.registry.Registry} interface.
import ratpack.handling.Handler; import ratpack.handling.Context; import ratpack.registry.Registry; import static ratpack.registry.Registries.just; public class Thing { private final String name public Thing(String name) { this.name = name; } public String getName() { return name; } } public class UpstreamHandler implements Handler { public void handle(Context context) { context.next(just(new Thing("foo"))); } } public class DownstreamHandler implements Handler { public void handle(Context context) { assert context instanceof Registry; Thing thing = context.get(Thing.class); context.render(thing.getName()); } } import ratpack.test.handling.HandlingResult; import ratpack.test.handling.RequestFixture; import static ratpack.test.UnitTest.handle; import static ratpack.handling.Handlers.chain; import static ratpack.func.Action.noop; Handler chain = chain(new UpstreamHandler(), new DownstreamHandler()); HandlingResult result = handle(chain, noop()); assert result.rendered(String.class).equals("foo"); Registry objects are assumed to be thread safe. No external synchronization is performed around registry access. As registry objects may be used across multiple requests, they should be thread safe.
Registries that are created per request however do not need to be thread safe.
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |