Previous | Table of Contents | Next |
local interface ClientRequestInfo : RequestInfo { readonly attribute Object target; readonly attribute Object effective_target;
readonly attribute IOP::TaggedProfile effective_profile; readonly attribute any received_exception; readonly attribute CORBA::RepositoryId
received_exception_id; IOR::TaggedComponent get_effective_component (
in IOP::ComponentId id); IOP::TaggedComponentSeq get_effective_components (
in IOP::ComponentId id); CORBA::Policy get_request_policy (in CORBA::PolicyType type); void add_request_service_context (
in IOP::ServiceContext service_context, in boolean replace); };
Some attributes and operations on ClientRequestInfo are not valid at all interception points.
Table 21-1 shows the validity of each attribute or operation. If it is not valid,
attempting to access it will result in a BAD_INV_ORDER being raised with a standard minor code of 14.
Table 21-1 ClientRequestInfo Validity
send_ request |
send_poll |
receive_ reply |
receive_ exception |
receive_ other |
|
request_id | yes | yes | yes | yes | yes |
operation | yes | yes | yes | yes | yes |
arguments | yes1 | no | yes | no | no |
exceptions | yes | no | yes | yes | yes |
contexts | yes | no | yes | yes | yes |
operation_context | yes | no | yes | yes | yes |
result | no | no | yes | no | no |
response_expected | yes | yes | yes | yes | yes |
sync_scope | yes | no | yes | yes | yes |
reply_status | no | no | yes | yes | yes |
forward_reference | no | no | no | no | yes2 |
get_slot | yes | yes | yes | yes | yes |
get_request_service_context | yes | no | yes | yes | yes |
get_reply_service_context | no | no | yes | yes | yes |
target | yes | yes | yes | yes | yes |
effective_target | yes | yes | yes | yes | yes |
effective_profile | yes | yes | yes | yes | yes |
received_exception | no | no | no | yes | no |
received_exception_id | no | no | no | yes | no |
get_effective_component | yes | no | yes | yes | yes |
get_effective_components | yes | no | yes | yes | yes |
get_request_policy | yes | no | yes | yes | yes |
add_request_service_context | yes | no | no | no | no |
1When ClientRequestInfo is passed to send_request, there is an entry in the list for every argument, whether in, inout, or
out. But only the in and inout arguments will be available.
2 If the reply_status attribute is not LOCATION_FORWARD, accessing this attribute will raise BAD_INV_ORDER with a standard
minor code of 14.
21.3.13.1 target
This attribute is the object which the client called to perform the operation. See
Section 21.3.13.2, “effective_target,? on page 21-27.
21.3.13.2 effective_target
This attribute is the actual object on which the operation will be invoked. If the reply_status is LOCATION_FORWARD, then
on subsequent requests, effective_target will contain the forwarded IOR while target will remain unchanged.
21.3.13.3 effective_profile
This attribute is the profile that will be used to send the request. If a location forward has occurred for this operation’s
object and that object’s profile changed accordingly, then this profile will be that located profile.
21.3.13.4 received_exception
This attribute is an any that contains the exception to be returned to the client.
If the exception is a user exception that cannot be inserted into an any (for example, it is unknown or the bindings don’t
provide the TypeCode), then this attribute will be an any containing the system exception UNKNOWN with a standard minor code
of 1. However, the RepositoryId of the exception is available in the received_exception_id attribute.
21.3.13.5 received_exception_id
This attribute is the CORBA::RepositoryId of the exception to be returned to the client.
21.3.13.6 get_effective_component
This operation returns the IOP::TaggedComponent with the given ID from the profile selected for this request.
If there is more than one component for a given component ID, it is undefined which component this operation returns. If there
is more than one component for a given component ID, get_effective_components should be called instead.
If no component exists for the given component ID, this operation will raise BAD_PARAM with a standard minor code of 28..
Parametersid |
|||||
The IOP::ComponentId of the component that is to be | |||||
returned. |
Return Value The IOP::TaggedComponent obtained with the given identifier.
21.3.13.7 get_effective_components
This operation returns all the tagged components with the given ID from the profile selected for this request. This sequence
is in the form of an IOP::TaggedComponentSeq.
If no component exists for the given component ID, this operation will raise BAD_PARAM with a standard minor code of 28.
Parameters
id The IOP::ComponentId of the components that are to be returned.
Return Value The IOP::TaggedComponentSeq, each component of which contains the given identifier.
21.3.13.8 get_request_policy
This operation returns the given policy in effect for this operation.
If the policy type is not valid either because the specified type is not supported by this ORB or because a policy object
of that type is not associated with this Object, INV_POLICY with a standard minor code of 2 is raised.
Parameters
id The CORBA::PolicyType that specifies the policy to be returned.
Return Value The CORBA::Policy obtained with the given type.
21.3.13.9 add_request_service_context
This operation allows Interceptors to add service contexts to the request.
There is no declaration of the order of the service contexts. They may or may not appear in the order that they are added.
Parametersservice_contextreplace |
|||||
The IOP::ServiceContext to be added to the request. | |||||
Indicates the behavior of this operation when a service context already exists with the given ID. If false, then BAD_INV_ORDER with a standard minor code of 15 is raised. If true, then the existing service context is replaced by the new one. |