| Member | Organization | Status | V1 | V2 | V3 | V4 | V5 | V6 | V7 | V8 |
| Blake Biesecker | Gemstone | added | V | V | NV | V | V | V | NV | V |
| Jishnu Mukerji | Hewlett-Packard | charter | V | V | V | V | V | V | V | V |
| Russell Butek | IBM | charter | V | V | V | V | V | V | V | V |
| Ioana Pirvulescu | Inprise | charter | V | V | V | V | V | V | V | V |
| Bob Kukura | Iona | charter | V | V | V | V | V | V | V | V |
| Dock Allen | Mitre | added | NV | V | V | V | NV | NV/X | X | X |
| Bill Beckwith | OIS | charter | NV | V | V | V | V | NV | V | V |
| Matthew Newhook | OOC | charter | V | V | V | V | V | V | V | V |
| Nick Sharman | PeerLogic | added | V | V | V | V | V | NV | NV/X | X |
| Jeff Mischkinsky | persistence | charter | V | V | V | V | V | V | V | V |
| Paul Kyzivat | Rogue Wave | added | V | V | V | V | V | V | V | V |
| Harold Carr | Sun Microsystems | charter | V | V | V | V | V | V | V | V |
| Polar Humenn | Syracuse University | added | V | V | NV | V | V | V | V | V |
| Shahzad Aslam-Mir | Vertel | charter | NV | V | NV | V | NV | NV/X | X | X |
| Disposition | Number of Occurrences | Meaning of Disposition |
| Unresolved/Deferred | 12 | FTF could not agree on a resolution |
| Transferred | 1 | Transferred to another TF |
| Accepted (Changed and Closed) | 16 | Change made as requested |
| Rejected (Close, No Change) | 13 | RTF / FTF agreed NOT to do what was requested, or anything like it |
| Duplicate | 3 | Duplicate to another issue |
Calling the post_init operations is not the final task of ORB initialization. The final task, following the post_init calls, is attaching the lists of registered interceptors to the ORB. Therefore, the ORB does not contain the interceptors during calls to post_init. If an ORB-mediated call is made from within post_init, no request interceptors will be invoked on that call. Likewise, if an operation is performed which causes an IOR to be created, no IOR interceptors will be invoked.
Actions taken: Incorporate change and close issue.
January 17, 2000: received issue
1. Define the ORB as "native ORB;"
This puts the ORB into the IDL namespace. However, the ORB is still described in PIDL. This doesn't really help us to remove PIDL, some folks feel this is a misuse of native, but it would be sufficient for the requirements of PI.
2. Define an IDL wrapper for the ORB, call it proxyORB for now.
proxyORB would contain exactly the same items that the PIDL ORB does, only defined in pure IDL. Advantages: this is a migration step toward getting rid of ORB PIDL if we encourage folks to use proxyORB rather than ORB. Disadvantages: dual maintenance; lots of work - too much for this FTF?; I don't think we know all the ramifications; where do you get a proxyORB? from the ORB?
3. Make the leap and redefine ORB in IDL now.
This option is similar to option 2, but the IDL is not a wrapper, it's the real ORB. Advantages: no dual maintenance; we get rid of ORB PIDL right now. Disadvantages: BIG step - too big for this FTF?; lots of work; I don't think we know all the ramifications.
4. Make the ORB a primitive type like TypeCode.
This seems to be generally undesired. It requires all compilers to change. Unless someone really likes this approach, I don't think we should even consider it.
Note: No proposals for 1, 2, 3 or 4 were received. A alternate proposal, the one to be voted on here, was submitted by Matthew Newhook.
Also note: If this issue passes, adequate justification should be provided in the FTF report. Ideally, the alternatives that were considered and rejected should be summarized with reasons for rejection.
Resolution: Vote No, Proposal A, or Proposal B.
Revised Text:
In section 21.7.2: Delete the following methods, exceptions and
types.
register_initial_reference
resolve_initial_references
codec_factory
InvalidName
ObjectId
Add:
readonly attribute CORBA::ORB orb;
Add a new section to describe this attribute:
This attribute is the ORB being initialized.
In addition I propose two additions to the section: Proposal A:
The ORB shall be considered partially constructed in that any method invocations on objects created by this ORB will not have request interceptors called. Calling work_pending()/perform_work()/run()/shutdown() or destroy() on the ORB is not permitted and shall have undefined results.
Proposal B:
The ORB shall be considered partially constructed in that no method invocations on objects created by this ORB are permitted. Calling work_pending()/perform_work()/run()/shutdown() or destroy() on the ORB is not permitted and shall have undefined results.
I prefer Proposal A since not being able to make method invocations implies that things that narrowing of object references is not permitted. What this essentially means is that interceptors probably cannot be fully initialized in the ORB initializer.
PIDL Mapping for C++:
[I'm not sure exactly how this should look -- this is essentially
trimmed output from out IDL translator]
namespace PortableInterceptor
{
class ORBInitInfo : virtual public CORBA::Object
{
public:
static inline ORBInitInfo_ptr
_duplicate(ORBInitInfo_ptr p)
{
if(p)
p -> _OB_incRef();
return p;
}
static inline ORBInitInfo_ptr
_nil()
{
return 0;
}
static ORBInitInfo_ptr _narrow(CORBA::Object_ptr);
static ORBInitInfo_ptr _narrow(CORBA::AbstractBase_ptr);
struct DuplicateName : public CORBA::UserException
{
DuplicateName() { }
DuplicateName(const DuplicateName&);
DuplicateName& operator=(const DuplicateName&);
static DuplicateName* _downcast(CORBA::Exception*);
static const DuplicateName* _downcast(const CORBA::Exception*);
virtual void _raise() const { throw *this; }
virtual const char* _name() const;
virtual const char* _rep_id() const;
virtual char* _to_string() const;
DuplicateName(const char*);
};
virtual CORBA::StringSeq* arguments() = 0;
virtual char* orb_id() = 0;
virtual CORBA::ORB_ptr orb() = 0;
virtual void add_client_request_interceptor(ClientRequestInterceptor_ptr interceptor) = 0;
virtual void add_server_request_interceptor(ServerRequestInterceptor_ptr interceptor) = 0;
virtual void add_ior_interceptor(IORInterceptor_ptr interceptor) = 0;
virtual SlotId allocate_state_slot() = 0;
virtual void register_policy_factory(CORBA::PolicyType type,
PolicyFactory_ptr policy_factory) = 0;
};
class ORBInitializer : virtual public CORBA::Object
{
public:
static inline ORBInitializer_ptr
_duplicate(ORBInitializer_ptr p)
{
if(p)
p -> _OB_incRef();
return p;
}
static inline ORBInitializer_ptr
_nil()
{
return 0;
}
static ORBInitializer_ptr _narrow(CORBA::Object_ptr);
static ORBInitializer_ptr _narrow(CORBA::AbstractBase_ptr);
virtual void pre_init(ORBInitInfo_ptr info) = 0;
virtual void post_init(ORBInitInfo_ptr info) = 0;
};
} // End of namespace PortableInterceptor
namespace CORBA
{
inline void
release(PortableInterceptor::ORBInitInfo_ptr p)
{
if(p)
p -> _OB_decRef();
}
inline Boolean
is_nil(PortableInterceptor::ORBInitInfo_ptr p)
{
return p == 0;
}
} // End of namespace CORBA
//
// IDL:omg.org/PortableInterceptor/ORBInitializer:1.0
//
namespace CORBA
{
inline void
release(PortableInterceptor::ORBInitializer_ptr p)
{
if(p)
p -> _OB_decRef();
}
inline Boolean
is_nil(PortableInterceptor::ORBInitializer_ptr p)
{
return p == 0;
}
} // End of namespace CORBA
PIDL mapping for Java (still to be supplied...)
Actions taken: Close no change.
March 16, 2000: received issue
It appears that PI needs to add a finalization call and define when exactly that call runs for client- and server-side interceptors.
Resolution: Incorporate change and close issue.
Revised Text:
Add to 21.2:
module PortableInterceptor {
local interface Interceptor {
readonly attribute string name;
void destroy();
};
};
Add a description of the destroy() operation.
This method is called during ORB::destroy(). When an application
calls ORB::destroy, the ORB
1) waits for all requests in progress to complete
2) calls the Interceptor::destroy() operation for each interceptor
3) completes destruction of the ORB
Method invocations from within Interceptor::destroy() on
object references for objects implemented on the ORB being destroyed
result in undefined behavior. However, method invocations on objects
implemented on an ORB other than the one being destroyed are permitted.
(This means that the ORB being destroyed is still capable of acting
as a client, but not as a server.)
In section to 4.2.3.5: After paragraph:
If destroy is called on an ORB that has not been shut down, it will start the shut down process and block until the ORB has shut down before it destroys the ORB. If an application calls destroy in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock.Add:
If interceptors are registered with the ORB being destroyed, the Interceptor::destroy() operation is invoked on each interceptor (see section 21.2).
Actions taken: Incorporate change and close issue.
March 22, 2000: received issue
Resolution: Retry behavior only occurs from an ORB call to an interceptor. Make the following clarifications to ptc/00-03-03, section 21.3.15
Revised Text:
Add the following text to the end of the first paragraph of this section:
This behavior of causing a retry only occurs if the ORB receives a ForwardRequest from an interceptor. If ForwardRequest is raised anywhere else it is pass through the ORB as is normal for a user exception.And change the first sentence of the second paragraph from:
If an Interceptor raises a ForwardRequest exception, no other Interceptors are called for that interception point.to:
If the ORB receives a ForwardRequest exception in response to a call of an interceptor, no other Interceptors are called for that interception point.Actions taken: Incorporate change and close issue.
"Put 3545 on the next vote as "Close, no change". I misunderstood the relationship in Java between the properties object and the args object on ORB.init when I raised this issue. There apparently isn't any relationship and I thought there was."
Resolution: Vote YES to close this issue with no change.
Revised Text:
Actions taken: Close issue, no change.
April 11, 2000: received issue
This operation is called during ORB initialization.
All calls to
ORBInitInfo::register_initial_reference must
be made at this point so that the list
of initial references is complete for the post_init
point.
with:
This operation is called during ORB initialization. If it is expected that initial services registered by an interceptor will be used by other interceptors, then those initial services shall be registered at this point via calls to ORBInitInfo::register_initial_reference.
Actions taken: Incorporate change
and close issue.
April 19, 2000: received issue
8. The TSC is copied back to the RSC, overwriting the slots in the RSC.
with:
8. The TCS from the thread on which the ORB invoked the target operation is copied back to the RSC, overwriting the slots in the RSC.
Actions taken: Incorporate change
and close issue.
April 27, 2000: received issue
The last line in the Java mapping of register_orb_initializer is wrong. It reads:
To run a program called MyApp using this logging service, the user could type:
java -Dorg.omg.PortableInterceptor.ORBInitializerClass.com.x.Logging = com.x.Logging.LoggingService MyApp
It should read:
To run a program called MyApp using this logging service, the user could type:
java -Dorg.omg.PortableInterceptor.ORBInitializerClass.com.x.Logging.LoggingService MyApp
Actions taken: Incorporate change
and close issue.
May 4, 2000: received issue
"This attribute contains the arguments passed to ORB_init. They may or may not contain the ORB's arguments."
I take this to mean that any ORB_init arguments that applied to the ORB instance being created may not be present. All other strings passed to ORB_init will be present so initialisation strings can be passed to the interceptors through ORB_init.
With the current text it is possible to think that you may not get *any* of the arguments to ORB_init.
Resolution: Vote on A, B or C.
Revised Text:
To clarify ptc/2000-04-05 page 21-42 Section 21.7.2.3 Arguments:
Current Text: This attribute contains the arguments passed to ORB_init. They may or may not contain the ORB's arguments.
Resolution Choices:
A. No Change. The discussion indicates a new issue needs to be raised to address this at a higher level.
B. This attribute contains the arguments passed to ORB_init. It may or may not contain the arguments which the ORB recognizes. It shall contain all arguments passed to ORB_init which the ORB does not recognize.
C. This attribute shall contain all the arguments that are passed to ORB_init.
Actions taken: Vote not conclusive. Unresolved.
May 3, 2000: received issue
This is rather inconvenient, especially for OTS, where I want to to talk to an XA interface from the interception points. The problem is that XA is sensitive to the calling thread and doesn't allow me to, for example, start something in one thread and finish it in another.
Now, consider the following:
- The POA spec already requires preinvoke, the operation, and
postinvoke to run in the same thread.
- The sequence of invocations if a servant locator is present
for interceptors is:
1) receive_request_service_context
2) preinvoke
3) receive_request
4) operation
5) postinvoke
6) send_reply or send_exception
Of these, 2, 4, and 5 must happen in the same thread.
Now, what is the likelihood that an interceptor implementation will
switch context after preinvoke and before receive_request, only to have
to switch back to the original thread after preinvoke and before the
operation? Essentially zero, I think. It's a lot harder and a lot less
efficient to do that context switch than to not do it. In other words,
I don't think we would lose anything if we required that 3 and 4
must run in the same thread. Similarly, an implementation isn't going to do a context switch after 4 (or 5) and before 6, because at point 6 I still must be able to modify the reply context. (If the ORB uses a separate thread to squirt reply packets onto the wire, it might as well context switch to that reply thread *after* point 6, because until after point 6, it can't marshal anything anyway.)
So, I would like to consider a change such that 2-6 must happen in the same thread. It would make OTS and other services that have some implicit dependency on thread-specific data much easier to implement, and I don't think it would constrain ORB implementations.
Resolution:
Revised Text:
The following paragraph be added to the end of section
21.3.10.2 "Additional Server-side Details" on page 21-17:
If a POA and a servant locator are present, the order of their operations and interception points is:
1) ServerRequestInterceptor.receive_request_service_context
2) ServantLocator.preinvoke
3) ServerRequestInterceptor.receive_request
4) the operation
5) ServantLocator.postinvoke
6) ServerRequestInterceptor send_reply, send_exception, or send_other
preinvoke, the operation, and postInvoke are required to execute
in the same thread (see section 11.3.6 ServantLocator Interface on
page 11-25). Since receive_request occurs within this chain,
receive_request shall also execute in the same thread. postinvoke executes in the same thread as preinvoke in order for postinvoke to perform any necessary closure processing. Likewise, the sending interception points (send_reply, send_exception, and send_other) should also execute in the same thread.
Adding this restriction changes a number of other statements in the spec as well. The following paragraphs in doc # ptc/2000-04-05 must also change:
Page 21-14, first paragraph of section 21.3.9.2 "receive_request":
This interception point allows an Interceptor to query request information after all the information, including operation parameters, are available. This interception point may or may not execute in the same thread as the target invocation.
will change to:
This interception point allows an Interceptor to query request information after all the information, including operation parameters, are available. This interception point shall execute in the same thread as the target invocation.
The following sentence will be added to the end of the first paragraph in each of the sections: 21.3.9.3 "send_reply", 21.3.9.4 "send_exception", and 21.3.9.5 "send_other":
This interception point shall execute in the same thread as the target invocation.
Page 21-35, points 5 and 6 of section 21.4.4.5:
5. The ORB logically copies the RSC to the server-side TSC after the receive_request_service_context points are processed and before the servant manager is called. This TSC is within the context for both the invocation of the servant manager and the invocation of the target operation. The receive_request points may modify the RSC, but this no longer affects the TSC.
6. Control transfers to the server threads which may read and write this server-side TSC.
will change to:
5. The ORB logically copies the RSC to the server-side TSC after the receive_request_service_context points are processed and before the servant manager is called. This TSC is within the context for the receive_request points, the invocation of the servant manager, and the invocation of the target operation. The receive_request points may modify the RSC, but this no longer affects the TSC.
6. The receive_request points are called. These points have access to the RSC - though modifying the RSC at this point has no affect on the TSC. Since these points execute in the same thread as the target operation invocation, these points may modify the server-side TSC. After the receive_request points are called, control transfers to the server threads which may also read and write this server-side TSC.
Page 21-36, Figure 21-1 also needs changing. Either a two-way arrow must exist between the boxes for receive_request and Thread Scope PICurrent or the receive_request box is put within the Server Threads box. Ditto for the "Send Interception Points" box. Any preferences?
Page 21-37, the last paragraph of section 21.4.4.6:
Interceptors shall assume that each interception point logically runs in its own thread, with no context relationship between it and any other thread. While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did.
will change to:
Interceptors shall assume that each client-side interception point logically runs in its own thread, with no context relationship between it and any other thread. While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did.
Interceptors shall assume that all server-side interception points except receive_request_service_context run in the same thread as the target operation invocation, thereby sharing thread context information. receive_request_service_context, like all client-side interception points, logically runs in its own thread, with no context relationship between it and any other thread.
Actions taken: Incorporate change close issue.
May 18, 2000: received issue
To create a non-local object and register it in pre_init one needs a POA which can only be obtained via resolve_initial_references.
Resolution: Incorporate change.
Revised Text:
Remove the first sentence of 21.7.2.7:
"This operation is only valid during post_init."
Add the following paragraphs following the existing paragraph of 21.7.2.7:
If resolve_initial_references is used to obtain a reference to the RootPOA, and new children POAs of that RootPOA are created during pre_init or post_init, then no IORInterceptors are executed for these newly created POAs. Further, regardless of the policy set associated with the these POAs, no components added via IORInfo::add_ior_component or IORInfo::add_ior_component_to_profile will appear in references created by these POAs.
Invocations are allowed on references created by these POAs at anytime. If the invocations occur during pre_invoke or post_invoke, then no RequestInterceptors are executed.
Actions taken: Close issue. No Change.
May 19, 2000: received issue
Actions taken: Close issue. No Change.
March 16, 2000: received issue
Resolution: In table 21-2 ServerRequestInfo
Validity, on page 21-28 of ptc/2000-04-05, change the rows for
target_most_derived_interface and target_is_a. Also add a new
footnote.
Revised Text:
Table for those rows change to (with footnote 4):
receive_request_
service_contexts receive_request send_reply send_exception send_other
4 4 4
no yes no no no
and the new footnote is: The operation is not available in this interception point because the necessary information requires access to the target object's servant, which may no longer be available to the ORB. For example, if the object's adapter is a POA that uses a ServantLocator, then the ORB invokes the interception point after it calls ServantLocator::postinvoke().
Actions taken: Incorporate change and close issue.
May 23, 2000: received issue
Change document #ptc/2000-04-05, page 4-25, section titled "Default Resolution Order" from:
The default order for processing a call to CORBA::ORB::resolve_initial_references
for a given <ObjectID> is:
1. Resolve with -ORBInitRef for this <ObjectID> if possible
2. Resolve with an -ORBDefaultInitRef entry if possible
3. Resolve with pre-configured ORB settings.
to:
The default order for processing a call to CORBA::ORB::resolve_initial_references
for a given <ObjectID> is:
1. Resolve with -ORBInitRef for this <ObjectID> if possible
2. Resolve with an -ORBDefaultInitRef entry if possible
3. Resolve with a register_initial_reference entry if possible
4. Resolve with pre-configured ORB settings.
Actions taken: Incorporate change and close issue.
However, this is modified by issue 3742.
May 24, 2000: received issue
Issue 3653: Should get/set_slot on PICurrent be disallowed in ORBInitializer? (interceptors-ftf)
Click here for
this issue's archive.
Source: Sun Microsystems (Dr. Harold Carr, Ph.D., harold.carr@sun.com)
Nature: Uncategorized Issue
Severity:
Summary: Currently one can write code like post_init(ORBInitInfo
info) { PICurrent pic = (narrow
...)info.resolve_initial_references("PICurrent"); SlotId id = info.allocate_slot_id();
pic.set_slot(id,
...); } It would be most efficient if an implementation could wait
until after all ORBInitializer
complete to allocate a fixed sized slot table. However, the current
spec makes it impossible to wait.
I do not think there is anything useful you can do via set_slot at
this point so disallowing it should
not be a problem.
Resolution: For performance reasons, we have always wanted a
fixed size slot table. Without fixing the problem in this issue,
we lose any fixed-size optimizations.
Revised Text:
In document #ptc/2000-04-05, change the following:
Append the following sentence to section 21.4.3.1 "get_slot"
If get_slot is called from within an ORB initializer (see section 21.7
Registering Interceptors) BAD_INV_ORDER with a minor code of 10 shall be
raised.
Append the following sentence to section 21.4.3.2 "set_slot"
If set_slot is called from within an ORB initializer (see section 21.7
Registering Interceptors) BAD_INV_ORDER with a minor code of 10 shall be
raised.
Append the following sentences to section 21.7.2.11 "allocate_slot_id":
Note that while slot id's can be allocated within an ORB initializer, the slots themselves cannot be initialized. Calling set_slot or get_slot on the PICurrent (see section 21.4 Portable Interceptor Current) within an ORB initializer shall raise a BAD_INV_ORDER with a minor code of 10.
Actions taken: Incorporate change and close issue.
May 26, 2000: received issue
Actions taken: Incorporate change and close issue.
See issue XX for exact text.
May 30, 2000: received issue
void IORInfo::components_available( in IORInfo info ) ;It would not be legal to call IORInfo::add_ior_component nor IORInfo::add_ior_component_to_profile in IORInfo::components_available.
Resolution: Exact text to be determined as a new
issue if this issue passes.
Actions taken: Close issue. No change.
May 30, 2000: received issue
/**
* A value type that captures the concept of creating
* object references according to a template.
*
* Object ID is the value passed to create_reference_with_id or the equivalent
* assigned in create_reference.
*
* Note that the ORB must provide an implementation for
* ObjectTemplateFactory and register it.
*/
valuetype IORTemplate
{
typedef sequence< octet > ObjectID ;
IOP::IOR create_reference_with_id( in ObjectID id ) ;
factory init( in Object obj ) ;
};
Add the following attribute to IORInfo:
local interface IORInfo {
attribute IORTemplate ior_template;
} ;
Actions taken: Close issue. No change.
May 30, 2000: received issue
Actions taken: Close issue. No change.
May 30, 2000: received issue
Proposal:
The persistent server ID is assigned by passing a
-ORBPersistentServerID= ... // some value
parameter to the ORB_init() call. In java this is done using the
org.omg.CORBA.PersistentServerID
property.
Resolution: Exact text to be determined as a new
issue if this issue passes.
Actions taken: Close issue. No change.
May 30, 2000: received issue
Resolution: Exact text to be determined as a new
issue if this issue passes.
Actions taken: Incorporate change and close issue.
However, this is out-of-scope for the interceptors FTF. It is being
transferred to the IDL to java RTF.
May 30, 2000: received issue
Proposal:
The persistent port id is assigned by passing a
-ORBPersistentServerPort=... // some value
parameter to the ORB_init() call. In java this is done using the
org.omg.CORBA.PersistentServerPort
proprty to indicate the listening port for the activation daemon.
Resolution: Exact text to be determined as a new
issue if this issue passes.
Actions taken: Close issue. No change.
May 30, 2000: received issue
Resolution: Exact text to be determined as a new
issue if this issue passes.
Actions taken: Close issue. No change.
May 30, 2000: received issue
A.receive_request_service_contexts is called;
B.receive_request_service_contexts is called;
C.receive_request_service_contexts is called;
A.receive_request is called;
B.receive_request is called and raises a SystemException;
C.send_exception is called;
B.send_exception is called;
A.send_exception is called;
In this scenario you can see that the flow for each Interceptor follows the rules. Since the receive_request_service_contexts starting point ran to completion then, no matter what happens in intermediate points, a "terminating" intercpetion point must be called for all interceptors.
Actions taken: Incorporate change and close issue.
June 28, 2000: received issue
The offending verbage is in the first of the following 2 paragraphs from ptc/2000-04-05, page 21-44, between >>> and <<<:
Each service that implements Interceptors will provide an instance of ORBInitializer. To use a service, an application would first call register_orb_initializer, passing in the service?s ORBInitializer. After this is complete, the application would instantiate a new ORB by calling ORB_init with a new ORB ID. >>>ORB_init calls each registered ORBInitializer. The returned ORB will contain any Interceptors that the given service requires. <<<
register_orb_initializer is a global operation. An ORBInitializer registered at a given point in time will be called by all instantiating ORB_init calls that occur after that point in time. (An instantiating ORB_init call is one which produces a new ORB. In other words, one that is not passed the ID of an existing ORB.) No ORB instantiated before that point in time will be affected by that ORBInitializer. Moreover, if register_orb_initializer is called from within an initializer, the initializer registered by that call will not be called for the ORB currently being initialized. That initializer will only be invoked on an ORB instantiated at a later time.
The offending sentence implies that the ORB initializers are called on EVERY ORB_Init call. It should only be called on every ORB_Init call that instantiates a new ORB. This "instantiating ORB_Init call" is defined in the next paragraph, but it should be defined and used in the first for clarity. I propose rewriting the above two paragraphs as shown in the revised text section.
Resolution:
Revised Text:
Each service that implements Interceptors will provide an instance of
ORBInitializer. To use a service, an application would first call
register_orb_initializer, passing in the service's
ORBInitializer. After this is complete, the application would make an
instantiating ORB_Init call. (An instantiating ORB_init call is one
which produces a new ORB. In other words, one that is not passed the
ID of an existing ORB.) This instantiating ORB_Init call calls each
registered ORBInitializer. The returned ORB will contain any
Interceptors that the given service requires.
register_orb_initializer is a global operation. An ORBInitializer registered at a given point in time will be called by all instantiating ORB_init calls that occur after that point in time. No ORB instantiated before that point in time will be affected by that ORBInitializer. Moreover, if register_orb_initializer is called from within an initializer, the initializer registered by that call will not be called for the ORB currently being initialized. That initializer will only be invoked on an ORB instantiated at a later time.
Actions taken: Incorporate change close issue.
June 14, 2000: received issue
4.8.4.1 Default Resolution Order
The default order for processing a call to CORBA::ORB::resolve_initial_references for a given ObjectID is:
1. Resolve with -ORBInitRef for this ObjectID if possible
2. Resolve with an -ORBDefaultInitRef entry if possible
3. Resolve with a register_initial_reference entry if possible
4. Resolve with pre-configured ORB settings.
to one of two choices:
CHOICE A:
The default order for processing a call to CORBA::ORB::resolve_initial_references for a given ObjectID is:
1. Resolve with -ORBInitRef for this ObjectID if possible
2. Resolve with a register_initial_reference entry if possible
3. Resolve with pre-configured ORB settings.
4. Resolve with an -ORBDefaultInitRef entry if possible
OR:
CHOICE B:
1. Resolve with a register_initial_reference entry if possible
2. Resolve with -ORBInitRef for this ObjectID if possible
3. Resolve with pre-configured ORB settings.
4. Resolve with an -ORBDefaultInitRef entry if possible
Resolution: Vote for A, B or NO CHANGE.
Revised Text:
Actions taken: Incorporate change close issue. Note
that this supercedes issue 3642. Note that choice B passed.
March 16, 2000: received issue
PortableInterceptor::LOCATION_FORWARD_PERMANENTfrom the list of possible values for reply_status.
Change the 3 bullet of the "On the client" section to:
Within the receive_other interception point, this attibute will be any of: SUCCESSFUL, LOCATION_FORWARD or TRANSPORT_RETRY. SUCCESSFUL means an asynchronous request returned successfully. LOCATION_FORWARD means that a reply came back with LOCATION_FORWARD as its status. TRANSPORT_RETRY means that the transport mechanism indicated a retry - a GIOP reply with a status of NEEDS_ADDRESSING_MODE, for instance.Change the 3 bullet of the "On the server" section similarly.
Change 21.3.12.11 to:
If the reply_status attribute is LOCATION_FORWARD, then this attribute will contain the object to which the request will be forwarded. It is indeterminate whether a forwarded request will actually occur.Change 21.3.13 footnote 2 to:
If the reply_status attribute is not LOCATION_FORWARD, accessing this attribute will raise BAD_INV_ORDER with a standard minor code of 10.Change 21.3.13.2 to:
This attribute is the actual object on which the operation will be invoked. If the reply_status is LOCATION_FORWARD, then on subsequent request, effective_target will contain the forwardIOR while target will remain unchanged.Change 21.3.14 footnote 2 same as 21.3.13 footnote 2.
Change 21.3.15 to:
exception ForwardRequest {
Object forward;
};
The ForwardRequest exception is the means by which an Interceptor can
indicate to the ORB that a retry of the request should occur with the
new object given in the exception. If an Interceptor raises a
ForwardRequest exception, no other Interceptors are called for that
interception point. The remaining Interceptors in the Flow Stack shall
have their appropriate ending interception point called: receive_other
on the client, or send_other on the server. The reply_status in the
receive_other or send_other would be LOCATION_FORWARD,
depending on the value of the permanent element of ForwardRequest.
Change the definition of ForwardRequest in 21.10 to:
exception ForwardRequest {
Object forward;
};
and change the ReplyStatus values to:
// Valid reply_status values:
const ReplyStatus SUCCESSFUL = 0;
const ReplyStatus SYSTEM_EXCEPTION = 1;
const ReplyStatus USER_EXCEPTION = 2;
const ReplyStatus LOCATION_FORWARD = 3;
const ReplyStatus TRANSPORT_RETRY = 4;
Actions taken: Incorporate change and close issue.
August 2, 2000: received issue
The summary of issue 3660 (IORInfo::get_effective_policy access to POA policies ) says: "The standard POA policies should be available via IORInfo::get_effective_policy" The resolution says: Exact text to be determined as a new issue if this issue passes. I think we could agree to add text (like that suggested by Bob) to say policies passed to create_POA are available as an editorial part of 3660. This would result in text like the following: ------------------------- An ORB service implementation may determine what server side policy of a particular type is in effect for an IOR being constructed by calling the get_effective_policy. The returned CORBA::Policy object shall only be a policy whose type was registered via ORBInitInfo::register_policy_factory (see section 21.7.2.12, register_policy_factory on page 21-43) AND policies defined in module PortableServer. If a policy for the given type was not registered via register_policy_factory or is not defined in module PortableServer, this operation will raise INV_POLICY with a standard minor code of 2. ------------------------- It seems that no one wants the registration bits any longer. And, in the process of looking at this, it was discovered that the text does not say what happens when the given policy is not in effect. Removing the bits about policy factory registration and adding the policy not in effect bits seems to go beyond the scope of 3660. The revised text below would remove the factory registration requirement and specify what is returned when the given policy is not in effect.
An ORB service implementation may determine what server side policy of
a particular type is in effect for an IOR being constructed by calling
the get_effective_policy operation. When the IOR being constructed is
for an object implemented using a POA, all Policy objects passed to the
PortableServer::POA::create_POA call that created that POA are
accessable via get_effective_policy.
If a policy for the given type is not known to the ORB, then this
operation will raise INV_POLICY with a standard minor code of 2.
Parameters
type
The CORBA::PolicyType specifying the type of policy to return.
Return Value
The effective CORBA::Policy object of the requested type.
If a policy for the given type is known but that policy is not in
effect, then this operation will return a nil object reference.
Actions taken: Incorporate change and close issue.
August 16, 2000: received issue