From 554fd8c5195424bdbcabf5de30fdc183aba391bd Mon Sep 17 00:00:00 2001 From: upstream source tree Date: Sun, 15 Mar 2015 20:14:05 -0400 Subject: obtained gcc-4.6.4.tar.bz2 from upstream website; verified gcc-4.6.4.tar.bz2.sig; imported gcc-4.6.4 source tree from verified upstream tarball. downloading a git-generated archive based on the 'upstream' tag should provide you with a source tree that is binary identical to the one extracted from the above tarball. if you have obtained the source via the command 'git clone', however, do note that line-endings of files in your working directory might differ from line-endings of the respective files in the upstream repository. --- .../classpath/org/omg/PortableServer/package.html | 231 +++++++++++++++++++++ 1 file changed, 231 insertions(+) create mode 100644 libjava/classpath/org/omg/PortableServer/package.html (limited to 'libjava/classpath/org/omg/PortableServer/package.html') diff --git a/libjava/classpath/org/omg/PortableServer/package.html b/libjava/classpath/org/omg/PortableServer/package.html new file mode 100644 index 000000000..e4a74ef1a --- /dev/null +++ b/libjava/classpath/org/omg/PortableServer/package.html @@ -0,0 +1,231 @@ + + + + +GNU Classpath - The Portable Object Adapter package + +

+The Portable Object Adapter (POA) provides more control on the request +processing than it is possible when connecting objects directly to the +ORB. The POA model defines a tree structure of POAs, the root POA being +connected directly to the ORB. Any branch of this tree can be temporary or +permanently inactivated using {@link org.omg.PortableServer.POAManager}. +The same manager can control several branches in the POA tree. Also, +any branch in this tree can have different processing options (policies). +

+The newly created POA is in holding state, just queuing requests. To start +processing requests, it must be turned into the active state by its +{@link org.omg.PortableServer.POAManagerOperations#activate}. +

+The previously monolite object implementation is now divided into object +(that implements {@link org.omg.CORBA.Object}) +and servant (that implements either {@link org.omg.CORBA.portable.InvokeHandler} +or {@link org.omg.PortableServer.DynamicImplementation}). +Frequently each object has its own servant, but it can also be a single servant +per multiple objects and also default servant for POA +(see {@link org.omg.PortableServer.POAOperations#set_servant}). Each object +has its own Object Id, unique in the scope of the POA, where the object is +connected. These Ids need not be different for objects belonging +to different POAs, even if these POAs are connected to the same ORB. +Under the USER_ID is assignment policy this Id can be a specified by user in +{@link org.omg.PortableServer.POAOperations#activate_object_with_id}, +encapsulating some meaningful information about the object. The Id of the +object being currently served can be identified with +{@link org.omg.PortableServer.Servant#_object_id}. This approach is used in cases +when it is possible to encapsulate all object-related data into the +Object Id. Such system only needs one servant, one server socket and one +socket port per POA that can handle thounsands of objects. +

+Instead of being connected directly to the ORB, objects are now connected +to one of the ORBs POAs. Since JDK 1.4 the application specific implementation +base is derived from the {@link org.omg.PortableServer.Servant}, having a +different name pattern (*POA.java instead of the previous +_*ImplBase.java). This *POA suffix does not +mean that these servants implement or are derived from POA. They are different +classes that can be connected to one of the POAs, by instance, using +{@link org.omg.PortableServer.POAOperations#servant_to_reference}. +The implementation base also inherits an *Operations interface, containing +definitions of the application specific methods. The application programmer +writes a descendent of the implementation base, implementing these methods +for the application - specific functionality. +

+The POA objects support the method invocation by name, using +{@link org.omg.CORBA.Request}. This alternative method works without the +service-specific classes that may not be available at run time. +

+The objects in POA can also be activated and inactivated independently. It +is possible to set a listener ({@link org.omg.PortableServer.ServantActivator}) +that would register the object activations ("incarnations") and deactivations +("etherializations"). The servant need not be specifyed when creating an +object. Under the IMPLICIT_ACTIVATION +{@link org.omg.PortableServer.ImplicitActivationPolicy} +the {@link org.omg.PortableServer.ServantActivator} can provide the servant +in response to the first (local or remote) call of any method on the +previously incative object. +

+The root POA is obtained by resolving the initial reference "RootPOA" +for the orb. In the simpliest case the objects can be connected directly +to that root POA without creating the POA tree. The policies, used by +the root POA, are defined by OMG as following: + + + + + + + + + +
Policy typeAccepted policy
{@link org.omg.PortableServer.IdAssignmentPolicy} SYSTEM_ID +(Ids are created by POA)
{@link org.omg.PortableServer.IdUniquenessPolicy}UNIQUE_ID + (single object (and Id) per servant) +
{@link org.omg.PortableServer.ImplicitActivationPolicy} +IMPLICIT_ACTIVATION (if inactive, activate)
{@link org.omg.PortableServer.LifespanPolicy} TRANSIENT +(the POA objects cannot outlive POA)
{@link org.omg.PortableServer.RequestProcessingPolicy} +USE_ACTIVE_OBJECT_MAP_ONLY (the servant is provided during activation)
{@link org.omg.PortableServer.ServantRetentionPolicy} +RETAIN (retain servants for subsequent invocations)
{@link org.omg.PortableServer.ThreadPolicy} ORB_CTRL_MODEL +(single thread per request and single server socket per object)
+These values are also default for the child POAs The policies are +never inherited from the parent POA. +

+This set of policies means that each object will have a separate serving +thread, separate network socket port and usually a separate servant. It +is appropriate when the expected number of objects is not too large. +If the expected number of objects is larger than the supportable number +of threads and socket ports, the SINGLE_THREAD_MODEL +{@link org.omg.PortableServer.ThreadPolicy} is +used. Then all objects in POA with this policy are served in a single +thread, using the same server socket, connected to a single port. If the +request processing policy is additionally set to USE_DEFAULT_SERVANT, +all objects of this POA share the same (default) servant. +

+The operations, supported by POA are defined +separately in {@link org.omg.PortableServer.POAOperations}. +

+

The typical POA usage scenarios

+

POA converts servant to the object reference

+In the simpliest case, the servant implementation is connected to POA by +{@link org.omg.PortableServer.POAOperations#servant_to_reference}, the +returned object being a target of remote and local invocations. +It may be converted into the stringified reference, registered with +the naming service, used locally or, when serving or invoking local or remote +method, passed as a parameter or return value having the CORBA Object type. +The object obtains Id from POA and is activated due default implicit +activation policy. This scenario is supported by the default policy set +and is used in the most of the "hello world" examples. +

Servant provides to the object reference

+The servant can be connected to an ORB by +{@link org.omg.PortableServer.Servant#_this_object(org.omg.CORBA.ORB)}, +obtaining the object reference. The overridable +{@link org.omg.PortableServer.Servant#_default_POA()} +specifies POA to that the servant will be connected. The default method +connects to the root poa. IDL compilers frequently generate the +_this(ORB) metod for servants for getting the object reference +that is already narrowed to the exact object type. +

Explicit activation with POA assigned ids

+The objects are activated by calling the +{@link org.omg.PortableServer.POAOperations#activate_object} on the +POA with the object in question. The POA allocates, assigns, and +returns a unique identity value for the object. This scenario requires the +SYSTEM_ID {@link org.omg.PortableServer.IdAssignmentPolicy}. +

Explicit Activation with User-assigned Ids

+The POA supports an explicit activation operation, +{@link org.omg.PortableServer.POAOperations#activate_object_with_id}, +that associates a servant with the user-defined Object Id. +This scenario requires the USER_ID +{@link org.omg.PortableServer.IdAssignmentPolicy}. The servant manager +may be or may not be used. +

References before activation

+It may be useful to create references for objects before activating them. +Such reference can be created using +{@link org.omg.PortableServer.POAOperations#create_reference} or +{@link org.omg.PortableServer.POAOperations#create_reference_with_id}, both +methods also requiring to give the object repository id. Such object may +be later activated either by +{@link org.omg.PortableServer.POAOperations#activate_object_with_id} or +automatically, if the IMPLICIT_ACTIVATION policy applies. +

Multiple Ids per servant

+If the MULTIPLE_ID policy applies, the servant may be activated many times. +Under this policy, +{@link org.omg.PortableServer.POAOperations#servant_to_reference} +and {@link org.omg.PortableServer.POAOperations#servant_to_id} +during each call create a new object and object reference for the +used servant. +

One servant for all objects

+If the USE_DEFAULT_SERVANT policy applies, that default servant serves all +objects, belonging this POA. This approach is used when there is +very little data associated with each object, so little that the data can be +encoded in the Object Id. Also, it may be needed when a very large +number of objects is expected. If the RETAIN applies, it is possible to +activate an object explicitly setting the servant other than default. +If NO_RETAIN applies, the default servant will serve all known an +unknown objects for that POA. +

Single Servant, Many Objects and Types

+Combining USER_ID, USE_DEFAULT_SERVANT and RETAIN, it is possible to +create and serve objects "on the fly". The servant must determine the +object type (for instance, from the value of the agreed attribute, +shared by all supported types, or from the Object Id) and be able to +handle the method, named in request. If the names and parameter lists +of the object methods are also created "on the fly", the requests +to such object can still be submitted using {@link org.omg.CORBA.Request}. +This method is used when the created object represents some +entity in the complex database. +

The ServantLocator finds a servant for each call

+The {@link org.omg.PortableServer.ServantLocator} is used by POAs that +combinine NON_RETAIN and USE_SERVANT_MANAGER policies. It provides +a new or reused servant every time the invocation is made. The servant +locator must provide a servant in response of calling +{@link org.omg.PortableServer.ServantLocatorOperations#preinvoke}. +This method has access the the Id of the object being served and +the name of the method being called. It must return the appropriate +instance of the servant or throw an exception, forwarding the request +to another object (usually in another server). After the invocation, +a {@link org.omg.PortableServer.ServantLocatorOperations#postinvoke} +is called. It should be not assumed that the call of preinvoke +will be followed by the call of the postinvoke; in +multithreaded environment these calls are not serialized in this way. If +the preinvoke has to tell something this-call-specific to +the postinvoke, it must use the provided cookie holder. +The preinvoke/postinoke are also called to provide a servant +during each local invocation on the objects, belonging to the described POA. +

+All these scenarios must work with the current GNU Classpath release. + +@author Audrius Meskauskas, Lithuania (AudriusA@Bioinformatics.org) + + -- cgit v1.2.3