Interceptors are installed and managed via interceptor managers. The InterceptorManager interface is the generic interceptor manager from which all interceptor-specific managers inherit. An
InterceptorManager type is associated with each interceptor type. An
InterceptorManager holds a list or chain of a particular kind of interceptors, all of which have the same scope and need to start at the same time. Therefore, global interceptors, such as
POALifeCycle and
Bind have global
InterceptorManagers while scoped interceptors, per-POA and per-object, have an
InterceptorManager for each scope. Each scope, either global, POAs, or objects, may hold multiple types of interceptors. You get the right kind of manager for a particular interceptor from an
InterceptorManagerControl.
To obtain an instance of the global interceptor manager, InterceptorManager, call
ORB.resolve_initial_references and pass the
String InterceptorManager as an argument. This value is only available when the ORB is in administrative mode, that is, during ORB initialization. It can only be used to install global interceptors such as,
POALifeCycle interceptors or
Bind interceptors.
The POA interceptor manager is a per-POA manager and is only available to POALifeCycleInterceptors during their create call.
POALifeCycleInterceptors may set up all other server side interceptors during the call to create. The
Bind Interceptor Manager is a per-object manager and is only available to
Bind interceptors during their
bind_succeeded( ) call. Bind interceptors may set up
ClientRequest interceptors during the
bind_succeeded call.
In addition to the interceptor, the Interoperable Object Reference (IOR) template may be modified directly on the POAIntercptorManager interface during the call to
POALifeCycleInterceptor::create( ). The IOR template is a full IOR value with the
type_id not set, and all
GIOP::ProfileBodyValueshave incomplete object keys. The POA sets the
type_id and fills in the object keys of the template before calling the
IORCreationInterceptors.
Include the interceptor_c.hh file when you use this class.
This method returns an instance of the InterceptorManager which returns a string identifying the manager.
You should include the interceptor_c.hh file when you use this class.
virtual void bind_succeeded(IOP::IORValue_ptr
ior, CORBA::Object_ptr
obj, CORBA::Long
profileIndex, InterceptorManagerControl_ptr
interceptorControl, VISClosure&
closure);
The BindInterceptorManager must always be used at
ORB_init( ). It has no effect after the orb is initialized. Therefore, it only needs to be used in the context of a loader class that inherits from
VISinit.
To obtain a BindInterceptorManager from the
InterceptorManagerControl, use
InterceptorManagerControl::get_manager( ) with the identification string
Bind.
You should include the interceptor_c.hh file when you use this class.
void add (BindInterceptor _ptr interceptor)
This method is used to add a BindInterceptor to the list of interceptors to be started at bind time.
You use this class to derive your own client side interceptor. The Client Request interceptors may be installed during the bind_succeeded call of a bind interceptor and remain active for the duration of the connection. The methods defined in your derived class will be invoked by the ORB during the preparation or sending of an operation request, during the receipt of a reply message, or if an exception is raised.
Include the interceptor_c.hh file when you use this class.
virtual void preinvoke_premarshal (CORBA::Object_ptr
target, const char*
operation, IOP::ServiceContextList&
service_contexts, VisClosure&
closure);
virtual void preinvoke_postmarshal(CORBA::Object_ptr
target, CORBA_MarshallOutBuffet&
payload, VISClosure&
closure);
virtual void postinvoke(CORBA::Object_ptr
target,
const IOP::ServiceContextList&
Service_contexts,
CORBA_MarshallInBuffet&
payload,
CORBA::Environment_ptr
env, VISClosure& closure);
This method is invoked after a request completes correctly or by throwing an exception. It is called after the ServantLocator has been invoked. Should an interceptor in the chain throw an exception, that interceptor also calls
exceptionoccurred()and all remaining interceptors in the chain call
exception()instead of calling
postinvoke().
The CORBA::Environment parameter is changed to reflect this exception, even when a two-way call had already written an exception in that argument.
virtual void exception_occurred(CORBA::Object_ptr
target, CORBA::Environment_ptr
env, VISClosure&
closure);
class Interceptor::ClientRequestInterceptorManager : public InterceptorManager, public VISPseudoInterface
This is the class that holds the chain of ClientRequestInterceptors for the current object.
A ClientRequestInterceptorManager should be used inside of the
BindInterceptor::bind_succeeded( ) method within the scope set by the
InteceptorManagerControl passed as an argument to
bind_succeeded( ).
Include the interceptor_c.hh when you use this class.
virtual void add (ClientRequestInterceptor_ptr
interceptor);
This method may be invoked to add a ClientRequestInterceptor to the local chain.
virtual void remove (ClientRequestInterceptor_ptr
interceptor);
This method removes a ClientRequestInterceptorManager.
The POALifeCycleInterceptor is a global interceptor which is invoked every time a POA is created or destroyed. All other server side interceptors may be installed either as global interceptors or for specific POAs. You install the
POALifeCycleInterceptor through the
POALifeCycleInterceptorManager interface. Go to
“POALifeCycleInterceptorManager” on page 244 for more information. The
POALifeCycleInterceptor is called during POA creation and destruction.
Include the PortableServerExt_c.hh file when you use this class.
virtual void create(PortableServer::POA_ptr
poa, CORBA::PolicyList&
policies IOP::IORValue*&
iorTemplate, interceptor::InterceptorManagerControl_ptr
poaAdmin);
This method is invoked when a new POA is created either explicitly through a call to create_POA or via
AdapterActivator. With
AdapterActivator, the interceptor is called only after the
unknown_adapter method successfully returns from the
AdapterActivator. The create method is passed as a reference to the recently created POA and as a reference to that POA instance's
POAInterceptorManager.
virtual void destroy(PortalServer::POA_ptr poa);
This method is called before a POA is destroyed and all of its objects have been etherealized. It guarantees that destroy will be called on all interceptors before
create will be called again for a POA with the same name. If the destroy operation throws a system exception, the exception is ignored, and the remaining interceptors are called.
class InterceptorExt::POALifeCycleInterceptorManager public interceptor::InterceptorManager, public VISPseudoInterface
This class manages all POALifeCycle global interceptors. There is a single instance of the
POALifeCycleInterceptorManager defined in an ORB.
Include the PortalServerExt_c.hh file when you use this class.
virtual void add(POALifeCycleInterceptor_ptr interceptor);
This method may be invoked to add a POALifeCycleInterceptor to the global chain of
POALifeCycle interceptors.
The ActiveObjectLifeCycleInterceptor interceptor is called when objects are added and removed from the active object map. Only used when POA has RETAIN policy. This class is a POA-scoped interceptor which may be installed by a
POALifeCycleInterceptor when the POA is created.
Include the PortableServerExt_c.hh file when you use this class.
virtual void create(const PortableServer::ObjectId&
oid, PortableServer::ServantBase*
servant, PortableServer::POA_ptr
adapter);
virtual void destroy(const PortableServer::ObjectId&
oid, PortableServer::ServantBase*
servant, PortableServer::POA_ptr
adapter);
class PortableServerExt::ActiveObjectLifeCycleInterceptorManager public interceptor::InterceptorManager, public VISPseudoInterface
This is the class that manages all ActiveObjectLifeCycleInterceptors registered in its scope. Each POA has one single
ActiveObjectLifeCycleInterceptorManager.
Include the PortableServerExt_c.hh file when you use this class.
virtual void add(ActiveObjectLifeCycleInterceptor interceptor_ptr
interceptor);
This method may be invoked to add an ActiveObjectLifeCycleInterceptor to the chain.
The ServerRequestInterceptor class is a POA-scoped interceptor which may be installed by a
POALifeCycleInterceptor at POA creation time. This class may be used to perform access control, to examine and insert service contexts, and to change the reply status of a request.
Include the interceptor_c.hh file when you use this class.
virtual void preinvoke(CORBA::Object_ptr
_target, const char*
operation,
const IOP::ServiceContextList&
service_contexts,
CORBA::MarshalInBuffer&
payload, VISClosure&
closure) raises(ForwardRequestException);
virtual void postinvoke_premarshal(CORBA::Object_ptr
target,IOP::ServiceContextList&
ServiceContextList,CORBA::Environment_ptr
env, VISClosure&
closure);
virtual void postinvoke_postmarshal(CORBA::Object_ptr
_target,CORBA::MarshalOutBuffer&
_payload, VISClosure&
_closure);
virtual void exception_occurred(CORBA::Object_ptr
_target,CORBA::Environment_ptr
_env, VISClosure&
_closure);
This method is invoked by the ORB when an exceptionoccurred interceptor is called on all remaining interceptors in the chain after an exception occurred in one of the
prepare_reply interceptors. An exception thrown during this call replaces the existing exception in the environment
class Interceptor::ServerRequestInterceptorManager public InterceptorManager, public VISPseudoInterface
This is the class that manages all ServerRequestInterceptors registered in its scope. Each POA has one single
ServerRequestInterceptorManager.
Include the interceptor_c.hh file when you use this class.
virtual void add(ServerRequestInterceptor_ptr
interceptor);
Invoke this method to add a ServerRequestInterceptor to the chain.
The IORCreationInterceptor is a per-POA interceptor which may be installed by a
POALifeCycleInterceptor at POA creation time. The interceptor may be used to modify IORs by adding additional profiles or components. This class is typically used to support services such as transactions or firewall.
Include the PortableServerExt_c.hh file when you use this class.
virtual void create(PortableServer::POA
poa, IOP::IORValue*&
ior);
Include the PortableServerExt_c.hh file when you use this class.
virtual void add(IORCreationInterceptor_ptr _interceptor);
Include the vclosure.h file when you use this class.
This data member points to the VISClosureData class that represents the actual data. You may cast your managed data to this type.
This interface is a derived class of VISClosure and contains a
RequestInfo for read only attribute.
You can cast the VISClosure object passed to the
ServerRequestInterceptor and
ClientRequestInterceptor to its subclass,
VISExtendedClosure.
VISExtendedClosure can be used to extract the
RequestInfo, from which you can extract the
request_id and
response_expected. The
request_id is the unique id assigned to the request. The
response_expected flag indicates whether the request is a one-way call.
This interface is used by a client or server application to add or remove an UntypedObjectWrapperFactory object. An
UntypedObjectWrapperFactory is used to create an
UntypedObjectWrapper for each object a client application binds to or for each object implementation created by a server application.
See “Using object wrappers” in the VisiBroker C++ Developer's Guide for more information about how to use the object wrappers.
Include the vobjwrap.h file when you use this class.
void add(UntypedObjectWrapperFactory_ptr
factory,Location
loc);
void remove(UntypedObjectWrapperFactory_ptr
factory, Location
loc);
You use this class to derive and implement an un-typed object wrapper for a client application, a server application, or collocated application. When you derive an un-typed object wrapper from this class, you define a pre_method method that is invoked before a request is issued by a client application or before it is processed by an object implementation on the server side. You also define a
post_method method that will be invoked after an operation request is processed by an object implementation on the server side or after a reply has been received by a client application.
Refer to the VisiBroker C++ Developer's Guide for more information about how to use the object wrappers.