org.omg.PortableServer
Interface ServantLocator

All Superinterfaces:

IDLEntity, LocalInterface, Object, java.io.Serializable, ServantLocatorOperations, ServantManager, ServantManagerOperations

All Known Implementing Classes:

_ServantLocatorStub

public interface ServantLocator
extends LocalInterface, ServantLocatorOperations, ServantManager, IDLEntity

     When the POA has the NON_RETAIN policy it uses servant managers
     that are ServantLocators. Because the POA knows that the servant
     returned by this servant manager will be used only for a single
     request, it can supply extra information to the servant manager's
     operations and the servant manager's pair of operations may be
     able to cooperate to do something different than a
     ServantActivator.  When the POA uses the ServantLocator interface,
     immediately after performing the operation invocation on the
     servant returned by preinvoke, the POA will invoke postinvoke on
     the servant manager, passing the ObjectId value and the Servant
     value as parameters (among others). The next request with this
     ObjectId value will then cause preinvoke to be invoked again. This
     feature may be used to force every request for objects associated
     with a POA to be mediated by the servant manager.  When using such
     a ServantLocator, the following statements apply for a given
     ObjectId used in the preinvoke and postinvoke operations:  The
     servant returned by preinvoke is used only to process the single
     request that caused preinvoke to be invoked.  No servant
     incarnated by the servant manager will be placed in the Active
     Object Map.

     When the invocation of the request on the servant is complete,
     postinvoke will be invoked for the object.  No serialization of
     invocations of preinvoke or postinvoke may be assumed; there may
     be multiple concurrent invocations of preinvoke for the same
     ObjectId.  (However, if the SINGLE_THREAD_MODEL policy is being
     used, that policy will serialize these calls.) The same thread
     will be used to preinvoke the object, process the request, and
     postinvoke the object.  he preinvoke and postinvoke operations are
     always called in pairs in response to any ORB activity. In
     particular, for a response to a GIOP Locate message a
     GIOP-conforming ORB may (or may not) call preinvoke to determine
     whether the object could be served at this location. If the ORB
     makes such a call, whatever the result, the ORB does not invoke a
     method, but does call postinvoke before responding to the Locate
     message. (Note that the ServantActivator interface does not behave
     similarly with respect to a GIOP Locate message since the
     etherealize operation is not associated with request processing.)
     

Method Summary

Methods inherited from interface org.omg.PortableServer.ServantLocatorOperations

postinvoke, preinvoke

Methods inherited from interface org.omg.CORBA.Object

_create_request, _create_request, _duplicate, _get_domain_managers, _get_interface_def, _get_policy, _hash, _is_a, _is_equivalent, _non_existent, _release, _request, _set_policy_override