Issue 616: POA::id_to_reference() (port-rtf) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Within context of request invocation, the POA can return ObjectId for target object. One could pass this to POA::id_to_reference to get references used to invoke target. Not true in non-retain case Resolution: Revised Text: Actions taken: July 8, 1997: received issue Discussion: End of Annotations:===== Return-Path: X-Sender: vinoski@karloff.boston.iona.ie Date: Tue, 08 Jul 1997 10:46:50 -0400 To: issues@omg.org, port-rtf@omg.org From: Steve Vinoski Subject: id_to_reference() and WrongPolicy I noticed a potential problem with POA::id_to_reference() a few weeks ago when asnwering a comp.object.corba question. Within the context of a request invocation, the POA current can return the ObjectId for the target object. Presumably, one could then pass this to POA::id_to_reference() in order to get the object reference used to invoke the target. Unfortunately, this does not seem to be true in the non-retain case, since the spec says that WrongPolicy is raised if retain is not set. This means that getting the target object reference is not possible in the non-retain case. Surely the spec meant to say that id_to_reference() and id_to_servant() could always be called within the context of a request invocation, regardless of POA policy? Or am I missing something? --steve Return-Path: Sender: jon@floorboard.com Date: Sat, 11 Apr 1998 18:37:56 -0700 From: Jonathan Biggar To: port-rtf@omg.org Subject: Re: Issue 616 >From: Steve Vinoski >Subject: id_to_reference() and WrongPolicy > >I noticed a potential problem with POA::id_to_reference() a few weeks >ago when asnwering a comp.object.corba question. > >Within the context of a request invocation, the POA current can >return the ObjectId for the target object. Presumably, one could >then pass this to POA::id_to_reference() in order to get the object >reference used to invoke the target. > >Unfortunately, this does not seem to be true in the non-retain case, >since the spec says that WrongPolicy is raised if retain is not set. >This means that getting the target object reference is not possible >in the non-retain case. >Surely the spec meant to say that id_to_reference() and >id_to_servant could always be called within the context of a >request invocation, regardless of POA policy? Or am I missing >something? Proposal: close with no action Discussion: Steve, it appears that you can always get the servant and reference through other means when you are in the context of an invocation. The servant is obvious (this for C++, other language mappings may vary), and the reference could always be manufactured via a call to create_reference_with_id. Certainly a special case could be added to id_to_reference() and id_to_servant() to make them work for non-retain when in an invocation context, but that would complicate the implementation (since they would only work for a single id, namely the object being invoked) for little apparent gain. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Sun, 3 May 1998 20:57:13 +0100 From: jhierro@jam.tid.es (Juan Jose Hierro Sureda) To: port-rtf@omg.org, jon@floorboard.com Subject: Re: Issue 616 X-Sun-Charset: US-ASCII On Sat, 11 Apr 1998 18:37:56 -0700 Jonathan Biggar wrote: > > >From: Steve Vinoski > >Subject: id_to_reference() and WrongPolicy > > > >I noticed a potential problem with POA::id_to_reference() a few > weeks > >ago when asnwering a comp.object.corba question. > > > >Within the context of a request invocation, the POA current can > >return the ObjectId for the target object. Presumably, one could > >then pass this to POA::id_to_reference() in order to get the object > >reference used to invoke the target. > > > >Unfortunately, this does not seem to be true in the non-retain > case, > >since the spec says that WrongPolicy is raised if retain is not > set. > >This means that getting the target object reference is not possible > >in the non-retain case. > > >Surely the spec meant to say that id_to_reference() and > >id_to_servant could always be called within the context of a > >request invocation, regardless of POA policy? Or am I missing > >something? > > Proposal: close with no action > Disagree. > Discussion: > > Steve, it appears that you can always get the servant and reference > through other means when you are in the context of an invocation. > The > servant is obvious (this for C++, other language mappings may vary), > I agree in this respect. > and > the reference could always be manufactured via a call to > create_reference_with_id. > The answer is not so trivial in my honest opinion. I'll try to explain the point: If we want to create a reference to the object using create_reference_with_id, then we need to pass the CORBA RepositoryId for the reference. In a first approach, someone may argue that the servant must know which is the primary interface of the CORBA object it is currently incarnating (otherwise, it wouldn't be able to implement the _primary_interface method properly). Thus, the CORBA RepositoryId associated to the primary interface may be used when create_reference_with_id was invoked. However, the servant may want to know which was the most derived interface that was 'visible' through the reference being used by the client when the operation in question was invoked. An such interface MAY be different than the primary interface supported by the object. I'll try to better illustrate the point with an example. Suppose that a CORBA object export interfaces C, which in turns inherit from B, which inherits from A, as illustrated in the following diagram: interface A | | interface B | | interface C In my server, I may decide to create a CORBA object "x" whose primary interface is C. This will mean that the servant designated to incarnate the object must implement all operations defined in interface C (operations defined in C's body or inherit from A and B): MyCImpl servant; PortableServer::ObjectId_var oid = PortableServer::string_to_ObjectId ("x"); poa -> activate_object_with_id (oid, servant); However, when the server creates and return references to the CORBA object "x", it may wish restrict visibility through that references. In some situations, it would limit visibility to interface B: CORBA::Object_var ref1 = poa->create_reference_with_id (oid, "IDL:B:1.0"); return ref1; While in others, it would restrict visibility to interface A: CORBA::Object_var ref2 = poa->create_reference_with_id (oid, "IDL:A:1.0"); return ref2; An, in others, it would not restrict visibility at all: CORBA::Object_var ref3 = poa->create_reference_with_id (oid, "IDL:C:1.0"); return ref3; Strictly speaking, returning ref1 will not DEFINITIVELY restrict visibility to operations defined in interface B, but allows the server programmer to excercise 'control' in respect to how narrowing is performed when ref1 is used. Actually, if the client tries to narrow ref1 and gain visibility of operations defined in interface A or B, there will not be any problem. If he tries to narrow and gain visibility of operations defined in interface C, the client will consult the server (by means of remotely invoking an _is_a operation from the client). This circumstance, may be used by the server to excercise 'control' and deny narrowing to specific clients !! The facts about how narrowing works and what does it means to pass a Repository Id instead of other in operations for creating reference, are the first issues we need to clarify in this RTF because they are not rather clear in the spec. Following the description given above, we resolve all the gaps at the same time we provide a very powerful functionality to the POA and the CORBA programming model. I would like to propose its adoption (what does it means to pass a repository id in creation of reference, how does it affect narrowing) since it may help to resolve some other issues and introduce a very powerful functionality. If the proposal is accepted, then obtaining a replication of the actual reference that was used during invocation makes sense in the context of an invocation as opposed to simply replicating that reference using the primary interface of the CORBA object being incarnated. Fortunately, the issue would be easily resolved with the proposal given below. > Certainly a special case could be added to id_to_reference() and > id_to_servant() to make them work for non-retain when in an > invocation > context, but that would complicate the implementation (since they > would > only work for a single id, namely the object being invoked) for > little > apparent gain. > In my mind, what is needed is to include an operation that may help to obtain a reference to the target CORBA object being incarnated by a servant in the context of an invocation. Something with the same functionality as _this() in C++ but defined in IDL, thus mappeable to all programming languages. Proposal: Add operation get_reference in Current interface. This operation returns a CORBA object reference to the CORBA object incarnated in the context of the current invocation: interface Current { ... CORBA::Object get_reference () raises (NoContext); }; Return-Path: Sender: jon@floorboard.com Date: Sun, 03 May 1998 13:51:19 -0700 From: Jonathan Biggar To: Juan Jose Hierro Sureda CC: port-rtf@omg.org Subject: Re: Issue 616 References: <9805031957.AA08761@jam.tid.es> Juan Jose Hierro Sureda wrote: > Strictly speaking, returning ref1 will not DEFINITIVELY restrict > visibility > to operations defined in interface B, but allows the server > programmer to excercise > 'control' in respect to how narrowing is performed when ref1 is > used. Actually, > if the client tries to narrow ref1 and gain visibility of operations > defined in > interface A or B, there will not be any problem. If he tries to > narrow and gain > visibility of operations defined in interface C, the client will > consult the > server (by means of remotely invoking an _is_a operation from the > client). This > circumstance, may be used by the server to excercise 'control' and > deny narrowing > to specific clients !! > Proposal: > > Add operation get_reference in Current interface. This operation > returns > a CORBA object reference to the CORBA object incarnated in the > context of > the current invocation: > > interface Current { > ... > CORBA::Object get_reference () raises (NoContext); > }; Juan, this sounds like a great idea, but it fails at one simple point, which is unrecoverable. The RepositoryId of the reference that the client has is not transmitted to the server via the GIOP Request message, so the server cannot implement this proposed operation in the way that you have stated. Also, this sounds a lot like a security through obscurity mechanism, which wouldn't work against a determined attacker anyway. Close, but no cigar. (Hopefully that's not too politically incorrect to say, these days!) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Mon, 4 May 1998 19:21:22 +0100 From: jhierro@jam.tid.es (Juan Jose Hierro Sureda) To: jhierro@jam.tid.es, jon@floorboard.com Subject: Re: Issue 616 Cc: port-rtf@omg.org X-Sun-Charset: US-ASCII Jon Biggar wrote: > > > Proposal: > > > > Add operation get_reference in Current interface. This > operation returns > > a CORBA object reference to the CORBA object incarnated in the > context of > > the current invocation: > > > > interface Current { > > ... > > CORBA::Object get_reference () raises (NoContext); > > }; > > Juan, this sounds like a great idea, but it fails at one simple > point, > which is unrecoverable. The RepositoryId of the reference that the > client has is not transmitted to the server via the GIOP Request > message, so the server cannot implement this proposed operation in > the > way that you have stated. > You are true. It was my fault by not checking the spec once again and rely on my memories :-( At least, the discussion has helped to illustrate that the operation I proposed cannot be implemented in the way I have stated :-) One last word I want to state is that while the operation I proposed was not implementable, the discussion about semantics of create_reference* operations and narrowing is still in place and the proposal I presented deserves consideration whenever we get into discussions related to how repository ids passed in create_reference* operations affect narrowing, etc. This is an issue that is not well defined in the spec, in my honest opinion, and should be clarified in the RTF. My proposal in this respect is tto postpone its discussion to resolution of other issues that are more related to the point (issue 934, 738, 752). Do you agree ? In respect to issue 616, the proposal from Jon makes sense to me and I agree to accept his proposal. Thanks, -- Juanjo Date: Mon, 01 Feb 1999 13:00:09 -0500 From: Paul H Kyzivat Organization: NobleNet To: CORE RTF Subject: RE: Issue 616: POA::id_to_reference() I began looking at this issue in more detail in order to formulate a recommendation, and found that things are even more messed up than the issue text says: - of all the poa X_to_Y operations, only servant_to_reference takes the current invocation context into account as a special case. - steve asserts in this issue that id_to_servant and id_to_reference also should. - it appears to me that if we follow that philosophy, then servant_to_id and reference_to_servant should also work specially if their argument matches up with the current invocation context. I can see two ways to clean this up: 1) consistently make all the poa mapping operations take the current invocation context into account as a special case. 2) decide that the mapping operations should not be sensitive to invocation context. Remove the existing special case from servant_to_reference. Instead, add a complete set of accessors to Current to get anything that might be needed about the current invocation. (get_reference & get_servant should do the trick) In my opinion the suggestions to add get_reference to Current just further cloud the issue. Paul ====================================================================== Issue 616: POA::id_to_reference() (port-rtf) Source: IONA (Mr. Steve Vinoski, vinoski@iona.com) Nature: Uncategorized Severity: Summary: Within context of request invocation, the POA can return ObjectId for target object. One could pass this to POA::id_to_reference to get references used to invoke target. Not true in non-retain case Resolution: Revised Text: Actions taken: July 8, 1997: received issue Discussion: End of Annotations:===== Return-Path: X-Sender: vinoski@karloff.boston.iona.ie Date: Tue, 08 Jul 1997 10:46:50 -0400 To: issues@omg.org, port-rtf@omg.org From: Steve Vinoski Subject: id_to_reference() and WrongPolicy I noticed a potential problem with POA::id_to_reference() a few weeks ago when asnwering a comp.object.corba question. Within the context of a request invocation, the POA current can return the ObjectId for the target object. Presumably, one could then pass this to POA::id_to_reference() in order to get the object reference used to invoke the target. Unfortunately, this does not seem to be true in the non-retain case, since the spec says that WrongPolicy is raised if retain is not set. This means that getting the target object reference is not possible in the non-retain case. Surely the spec meant to say that id_to_reference() and id_to_servant() could always be called within the context of a request invocation, regardless of POA policy? Or am I missing something? --steve [snip rest of discussion] Date: Mon, 08 Feb 1999 15:33:34 -0500 From: Paul H Kyzivat Organization: NobleNet To: CORE RTF Subject: Re: Issue 616: POA::id_to_reference() References: <36B5EBA9.B2A1E718@noblenet.com> I sent the following out a week ago, but nobody has commented. I would like a sense of the group before proceeding to write up a specific proposal, so I am sending this out again. My preference is to change so that all invocation context specific behavior is obtained from POACurrent, and that all the operations on POA produce results that are invariant to the current invocation context. I prefer this because it is clear and consistent, while still providing all needed functionality. The problem is that it is not backward compatible w/r/t servant_to_reference. If this is unacceptable, then I think we should make queries on the POA take the invocation context into account whenever that makes sense. That would affect at least servant_to_id and reference_to_servant. This too is not entirely backward compatible. Comments please! Paul I began looking at this issue in more detail in order to formulate a recommendation, and found that things are even more messed up than the issue text says: - of all the poa X_to_Y operations, only servant_to_reference takes the current invocation context into account as a special case. - steve asserts in this issue that id_to_servant and id_to_reference also should. - it appears to me that if we follow that philosophy, then servant_to_id and reference_to_servant should also work specially if their argument matches up with the current invocation context. I can see two ways to clean this up: 1) consistently make all the poa mapping operations take the current invocation context into account as a special case. 2) decide that the mapping operations should not be sensitive to invocation context. Remove the existing special case from servant_to_reference. Instead, add a complete set of accessors to Current to get anything that might be needed about the current invocation. (get_reference & get_servant should do the trick) In my opinion the suggestions to add get_reference to Current just further cloud the issue. Paul ====================================================================== Issue 616: POA::id_to_reference() (port-rtf) Source: IONA (Mr. Steve Vinoski, vinoski@iona.com) Nature: Uncategorized Severity: Summary: Within context of request invocation, the POA can return ObjectId for target object. One could pass this to POA::id_to_reference to get references used to invoke target. Not true in non-retain case Resolution: Revised Text: Actions taken: July 8, 1997: received issue Discussion: End of Annotations:===== Return-Path: X-Sender: vinoski@karloff.boston.iona.ie Date: Tue, 08 Jul 1997 10:46:50 -0400 To: issues@omg.org, port-rtf@omg.org From: Steve Vinoski Subject: id_to_reference() and WrongPolicy I noticed a potential problem with POA::id_to_reference() a few weeks ago when asnwering a comp.object.corba question. Within the context of a request invocation, the POA current can return the ObjectId for the target object. Presumably, one could then pass this to POA::id_to_reference() in order to get the object reference used to invoke the target. Unfortunately, this does not seem to be true in the non-retain case, since the spec says that WrongPolicy is raised if retain is not set. This means that getting the target object reference is not possible in the non-retain case. Surely the spec meant to say that id_to_reference() and id_to_servant() could always be called within the context of a request invocation, regardless of POA policy? Or am I missing something? --steve [snip rest of discussion] Date: Mon, 08 Feb 1999 15:39:44 -0500 From: Paul H Kyzivat Organization: NobleNet To: CORE RTF Subject: Re: Issue 616: POA::id_to_reference() References: <36B5EBA9.B2A1E718@noblenet.com> About a week ago I sent out the message below. I began looking at this issue in more detail in order to formulate a recommendation, and found that things are even more messed up than the issue text says: - of all the poa X_to_Y operations, only servant_to_reference takes the current invocation context into account as a special case. - steve asserts in this issue that id_to_servant and id_to_reference also should. - it appears to me that if we follow that philosophy, then servant_to_id and reference_to_servant should also work specially if their argument matches up with the current invocation context. I can see two ways to clean this up: 1) consistently make all the poa mapping operations take the current invocation context into account as a special case. 2) decide that the mapping operations should not be sensitive to invocation context. Remove the existing special case from servant_to_reference. Instead, add a complete set of accessors to Current to get anything that might be needed about the current invocation. (get_reference & get_servant should do the trick) In my opinion the suggestions to add get_reference to Current just further cloud the issue. Paul ====================================================================== Issue 616: POA::id_to_reference() (port-rtf) Source: IONA (Mr. Steve Vinoski, vinoski@iona.com) Nature: Uncategorized Severity: Summary: Within context of request invocation, the POA can return ObjectId for target object. One could pass this to POA::id_to_reference to get references used to invoke target. Not true in non-retain case Resolution: Revised Text: Actions taken: July 8, 1997: received issue Discussion: End of Annotations:===== Return-Path: X-Sender: vinoski@karloff.boston.iona.ie Date: Tue, 08 Jul 1997 10:46:50 -0400 To: issues@omg.org, port-rtf@omg.org From: Steve Vinoski Subject: id_to_reference() and WrongPolicy I noticed a potential problem with POA::id_to_reference() a few weeks ago when asnwering a comp.object.corba question. Within the context of a request invocation, the POA current can return the ObjectId for the target object. Presumably, one could then pass this to POA::id_to_reference() in order to get the object reference used to invoke the target. Unfortunately, this does not seem to be true in the non-retain case, since the spec says that WrongPolicy is raised if retain is not set. This means that getting the target object reference is not possible in the non-retain case. Surely the spec meant to say that id_to_reference() and id_to_servant() could always be called within the context of a request invocation, regardless of POA policy? Or am I missing something? --steve [snip rest of discussion] Paul Kyzivat Software Architect Noblenet Inc. 337 Turnpike Road Southboro Massachusetts 01772 USA Work: 508-229-4662 Fax: 508-460-3456 Home: 508-779-5387 Netscape Conference Address Netscape Conference DLS Server Additional Information: Last Name Kyzivat First Name Paul Date: Tue, 09 Feb 1999 23:37:57 -0500 From: Bob Kukura Organization: IONA Technologies X-Accept-Language: en To: Paul H Kyzivat CC: CORE RTF , vinoski@iona.com Subject: Re: Issue 616: POA::id_to_reference() References: <36B5EBA9.B2A1E718@noblenet.com> <36BF4B90.5171CA49@noblenet.com> Paul H Kyzivat wrote: > > About a week ago I sent out the message below. > I began looking at this issue in more detail in order to formulate a > recommendation, and found that things are even more messed up than > the > issue text says: > > - of all the poa X_to_Y operations, only servant_to_reference takes > the > current invocation context into account as a special case. This makes perfect sense to me. The parameters to all of the other X_to_Y() operations unambiguously identify an object. But the servant passed to servant_to_refenence() might serve many different object identities. The current invocation context is used to determine which identity applies. > > - steve asserts in this issue that id_to_servant and id_to_reference > also should. Thats not how I'd interpret Steve's issue. These operations are passed the object_id, so I don't think he is suggesting that they need an invocation context to determine the identity. I think his issue has to due with id_to_reference() not being available, even in an invocation context, without the RETAIN policy. My recollection of the reason the RETAIN policy is required for id_to_reference() is that the POA needs to get the RepositoryId from the servant. Notice that the ObjectNotActive exception is raised if the object_id is not in the active object map. Outside the context of an invocation, there is no way for the POA to know for sure what servant will be used unless its in the AOM. Possibly, Steve is suggesting that the servant, and therefore the RepositoryId, are available in the context of an invocation, regardless of the RETAIN policy or AOM. Care to comment, Steve? > > - it appears to me that if we follow that philosophy, then > servant_to_id and reference_to_servant should also work specially > if > their argument matches up with the current invocation context. > > I can see two ways to clean this up: > > 1) consistently make all the poa mapping operations take the current > invocation context into account as a special case. > > 2) decide that the mapping operations should not be sensitive to > invocation context. Remove the existing special case from > servant_to_reference. Instead, add a complete set of accessors to > Current to get anything that might be needed about the current > invocation. (get_reference & get_servant should do the trick) I don't think either of these is what Steve intended. > > In my opinion the suggestions to add get_reference to Current just > further cloud the issue. > > Paul > > ====================================================================== > Issue 616: > POA::id_to_reference() > (port-rtf) > Source: IONA (Mr. Steve Vinoski, vinoski@iona.com) > Nature: Uncategorized > Severity: > Summary: Within context of request invocation, the POA can return > ObjectId for target object. One could pass this to > POA::id_to_reference > to get references used to invoke target. Not true in non-retain case > Resolution: > Revised Text: > Actions taken: > July 8, 1997: received issue > Discussion: > > End of Annotations:===== > Return-Path: > X-Sender: vinoski@karloff.boston.iona.ie > Date: Tue, 08 Jul 1997 10:46:50 -0400 > To: issues@omg.org, port-rtf@omg.org > From: Steve Vinoski > Subject: id_to_reference() and WrongPolicy > > I noticed a potential problem with POA::id_to_reference() a few > weeks > ago when asnwering a comp.object.corba question. > > Within the context of a request invocation, the POA current can > return the ObjectId for the target object. Presumably, one could > then pass this to POA::id_to_reference() in order to get the object > reference used to invoke the target. > > Unfortunately, this does not seem to be true in the non-retain case, > since the spec says that WrongPolicy is raised if retain is not set. > This means that getting the target object reference is not possible > in the non-retain case. > > Surely the spec meant to say that id_to_reference() and > id_to_servant() could always be called within the context of a > request invocation, regardless of POA policy? Or am I missing > something? > > --steve > > [snip rest of discussion] > > Paul Kyzivat > Software Architect > Noblenet Inc. > > 337 Turnpike Road > Southboro > Massachusetts > 01772 > USA > Work: 508-229-4662 > Fax: 508-460-3456 > Home: 508-779-5387 > Netscape Conference Address > Netscape Conference DLS Server > > Additional Information: > Last Name > Kyzivat > First Name > Paul -Bob Sender: jon@floorboard.com Date: Wed, 10 Feb 1999 00:16:35 -0800 From: Jonathan Biggar X-Accept-Language: en To: Bob Kukura CC: Paul H Kyzivat , CORE RTF , vinoski@iona.com Subject: Re: Issue 616: POA::id_to_reference() References: <36B5EBA9.B2A1E718@noblenet.com> <36BF4B90.5171CA49@noblenet.com> <36C10D25.FFA73135@iona.com> Bob Kukura wrote: > > Paul H Kyzivat wrote: > > > > About a week ago I sent out the message below. > > I began looking at this issue in more detail in order to formulate > a > > recommendation, and found that things are even more messed up than > the > > issue text says: > > > > - of all the poa X_to_Y operations, only servant_to_reference > takes the > > current invocation context into account as a special case. > > This makes perfect sense to me. The parameters to all of the other > X_to_Y() operations unambiguously identify an object. But the > servant > passed to servant_to_refenence() might serve many different object > identities. The current invocation context is used to determine > which > identity applies. > > > > > - steve asserts in this issue that id_to_servant and > id_to_reference > > also should. > > Thats not how I'd interpret Steve's issue. These operations are > passed > the object_id, so I don't think he is suggesting that they need an > invocation context to determine the identity. I think his issue has > to > due with id_to_reference() not being available, even in an > invocation > context, without the RETAIN policy. I'm with Bob on this one. There should be three types of "conversion" operations: 1. Those that can function in any context: reference_to_id() 2. Those that need special cases when the POA has MULTIPLE_ID: servant_to_id() servant_to_reference() 3. Those that can use the invocation context when NON_RETAIN: reference_to_servant() id_to_servant() id_to_reference() Both type 2 & 3 operations should make use of the invocation context (if available) to get the extra information necessary to perform the operation. The servant_to_reference() operation was special cased to handle the invocation context in CORBA 2.3 so that portable Java skeletons could properly implement _this(). However, there doesn't seem to be any reason to not extend that special case to the other type 2 & 3 operations, since the correct result of the operations inside an invocation context is clear. For type 2 operations, the id or reference associated with the target object is returned. For type 3 operations, the servant or reference associated with the target object is returned. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 16 Feb 1999 17:16:15 -0500 From: Paul H Kyzivat Organization: NobleNet To: CORE RTF Subject: Re: Issue 616: POA::id_to_reference() References: <36B5EBA9.B2A1E718@noblenet.com> <36BF4B90.5171CA49@noblenet.com> Jishnu - please add this to the next vote. Issue 616: POA::id_to_reference() (port-rtf) Source: IONA (Mr. Steve Vinoski, vinoski@iona.com) Nature: Uncategorized Severity: Summary: Within context of request invocation, the POA can return ObjectId for target object. One could pass this to POA::id_to_reference to get references used to invoke target. Not true in non-retain case Resolution: - of all the poa X_to_Y operations, only servant_to_reference takes the current invocation context into account as a special case. - steve asserts in this issue that id_to_servant and id_to_reference also should. - it appears to me that if we follow that philosophy, then servant_to_id and reference_to_servant should also work specially if their argument matches up with the current invocation context. I can see two ways to clean this up: 1) consistently make all the poa mapping operations take the current invocation context into account as a special case. 2) decide that the mapping operations should not be sensitive to invocation context. Remove the existing special case from servant_to_reference. Instead, add a complete set of accessors to Current to get anything that might be needed about the current invocation. (get_reference & get_servant should do the trick) I AM RECOMMENDING THE SECOND ALTERNATIVE. Revised Text: In section 11.3.8.20, replace the first paragraph and the first line of the second paragraph with: "This operation requires the RETAIN policy and either the UNIQUE_ID or IMPLICIT_ACTIVATION policies. Otherwise the WrongPolicy exception is raised." "This operation has three possible behaviors." Delete the third bullet item (beginning with: If the operation was invoked in the context...). In section 11.3.9, replace the last sentence of the second paragraph with: "Thereafter, it can be used within the context of a method dispatched by the POA to obtain the POA, ObjectId, Servant, and Object reference that are associated with the object on which that operation was invoked." Add the following two new sections after section 11.3.9.2: 11.3.9.3 get_servant Servant get_servant() raises(NoContext); This operation returns the servant assigned to service the operation in whose context it is called. If called outside the context of a POA-dispatched operation, a NoContext exception is raised. 11.3.9.4 get_reference Object get_reference() raises(NoContext); This operation returns an object reference identifying the object in whose context it is called. If called outside the context of a POA-dispatched operation, a NoContext exception is raised. This operation is equivalent to calling get_object_id and get_POA, and then calling create_reference_with_id on the POA, passing the result from get_object_id. The RepositoryId passed to create_reference_with_id is that of the most derived interface implemented by the servant. At the end of section 11.4 (on page 11-47) add the following operations to the Current interface: Servant get_servant() raises(NoContext); Object get_reference() raises(NoContext); Actions taken: July 8, 1997: received issue Discussion: Date: Tue, 16 Feb 1999 21:47:33 -0800 From: Jonathan Biggar Organization: Floorboard Software X-Accept-Language: en To: Paul H Kyzivat CC: CORE RTF Subject: Re: Issue 616: POA::id_to_reference() References: <36B5EBA9.B2A1E718@noblenet.com> <36BF4B90.5171CA49@noblenet.com> <36C9EE2F.98D5E513@noblenet.com> Paul H Kyzivat wrote: > I can see two ways to clean this up: > > 1) consistently make all the poa mapping operations take the current > invocation context into account as a special case. > > 2) decide that the mapping operations should not be sensitive to > invocation context. Remove the existing special case from > servant_to_reference. Instead, add a complete set of accessors to > Current to get anything that might be needed about the current > invocation. (get_reference & get_servant should do the trick) > I AM RECOMMENDING THE SECOND ALTERNATIVE. I am also opposed to this change. The original change to servant_to_reference() was changed to support Java portable stubs. This proposal breaks the Java language mapping. I would prefer that the X_to_Y() calls make use of the invocation context where appropriate instead. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 17 Feb 1999 15:32:10 -0500 From: Paul H Kyzivat Organization: NobleNet To: Jonathan Biggar CC: CORE RTF Subject: Re: Issue 616: POA::id_to_reference() References: <36B5EBA9.B2A1E718@noblenet.com> <36BF4B90.5171CA49@noblenet.com> <36C9EE2F.98D5E513@noblenet.com> <36CA57F5.581875A0@floorboard.com> Jonathan Biggar wrote: > > Paul H Kyzivat wrote: > > > I can see two ways to clean this up: > > > > 1) consistently make all the poa mapping operations take the > current > > invocation context into account as a special case. > > > > 2) decide that the mapping operations should not be sensitive to > > invocation context. Remove the existing special case from > > servant_to_reference. Instead, add a complete set of accessors to > > Current to get anything that might be needed about the current > > invocation. (get_reference & get_servant should do the trick) > > > I AM RECOMMENDING THE SECOND ALTERNATIVE. > > I am also opposed to this change. The original change to > servant_to_reference() was changed to support Java portable stubs. > This > proposal breaks the Java language mapping. I would prefer that the > X_to_Y() > calls make use of the invocation context where appropriate instead. I had forgotten about that, though I was aware that what I have proposed is an incompatible change and might be objected to as a result. If this is an unacceptable show-stopper, then I can instead propose changes to the other X_to_Y operations so as to provide consistent behavior. (But that is also an incompatible change!) If we are to make an incompatible change, I would rather make one that leaves the spec cleaner rather than messier. That is why I chose this approach. Can we see how the votes shake out and go from there? Date: Wed, 17 Feb 1999 17:15:57 -0800 From: Jonathan Biggar Organization: Floorboard Software X-Accept-Language: en To: Paul H Kyzivat CC: CORE RTF Subject: Re: Issue 616: POA::id_to_reference() References: <36B5EBA9.B2A1E718@noblenet.com> <36BF4B90.5171CA49@noblenet.com> <36C9EE2F.98D5E513@noblenet.com> <36CA57F5.581875A0@floorboard.com> <36CB274A.BCEF5535@noblenet.com> Paul H Kyzivat wrote: > I had forgotten about that, though I was aware that what I have proposed > is an incompatible change and might be objected to as a result. I'm not getting down on you, but it should be considered bad form to make a change that was needed by the Java language binding for CORBA 2.2, only to take it back soon thereafter. I do consider this a showstopper. > If this is an unacceptable show-stopper, then I can instead propose > changes to the other X_to_Y operations so as to provide consistent > behavior. (But that is also an incompatible change!) I don't necessarily consider it incompatible. For these other calls that didn't take into account the invocation context, the CORBA 2.2 behavior was to throw an exception. I don't expect there to be many, if any, applications that rely on this behavior. > If we are to make an incompatible change, I would rather make one that > leaves the spec cleaner rather than messier. That is why I chose this > approach. > > Can we see how the votes shake out and go from there? Well, I would prefer to convince you that this is a showstopper now, before a vote, but ultimately only votes decide things. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 18 Feb 1999 13:58:10 -0500 From: Paul H Kyzivat Organization: NobleNet To: Jonathan Biggar CC: CORE RTF Subject: Re: Issue 616: POA::id_to_reference() References: <36B5EBA9.B2A1E718@noblenet.com> <36BF4B90.5171CA49@noblenet.com> <36C9EE2F.98D5E513@noblenet.com> <36CA57F5.581875A0@floorboard.com> <36CB274A.BCEF5535@noblenet.com> <36CB69CC.7E22C194@floorboard.com> Jonathan Biggar wrote: > > I'm not getting down on you, but it should be considered bad form to > make a > change that was needed by the Java language binding for CORBA 2.2, > only to > take it back soon thereafter. I do consider this a showstopper. > > > If this is an unacceptable show-stopper, then I can instead > propose > > changes to the other X_to_Y operations so as to provide consistent > > behavior. (But that is also an incompatible change!) > > I don't necessarily consider it incompatible. For these other calls > that > didn't take into account the invocation context, the CORBA 2.2 > behavior was > to throw an exception. I don't expect there to be many, if any, > applications that rely on this behavior. > > > If we are to make an incompatible change, I would rather make one > that > > leaves the spec cleaner rather than messier. That is why I chose > this > > approach. > > > > Can we see how the votes shake out and go from there? > > Well, I would prefer to convince you that this is a showstopper now, > before > a vote, but ultimately only votes decide things. We still have time for a couple of iterations. I just want to get a reading of the general feelings for cleanlyness vs compatibility, given that the compatibility issue is relatively small. (After all, Java will still have a way to do what it needs, just a different way.) >From an overall API design perspective, it makes more sense for attributes of the invocation context to be handled separately from the attributes of the POA. I don't want to give up on that without a try. Sender: jon@floorboard.com Date: Sat, 20 Feb 1999 13:19:49 -0800 From: Jonathan Biggar X-Accept-Language: en To: Jishnu Mukerji CC: Jeff Mischkinsky , "Robert A. Kukura" , Tom Rutt , Jonathan Biggar , Stephen McNamara , Randy Fox , Bill Janssen , Michi Henning , Juan Jose Hierro Sureda , Bill Beckwith , Paul Kyzivat , Ken Cavanaugh , Edward Cobb , orb_revision@omg.org Subject: Re: Core RTF 2.4 Vote 4 References: <36CDDA7B.BD455FF4@fpk.hp.com> Jishnu Mukerji wrote: > > Core RTF 2.4 Vote 4 is now posted and available at: > > http://www.omg.org/pub/orbrev/votes/2_4vote4.html > > The votes are due by 1700EST of Feb 26, 99 Here are Floorboard's votes: Yes on: 2314, 2343, 2436, 2454 No on: 616, 2308 Comments: 616: I suppose I have already made my objections to this one pretty clear. To recap, it breaks the Java language binding portable skeletons by removing a feature that was specifically added to the POA. Removing this feature is a step backwards. 2308: I've made my objections to this pretty clear as well. This is a case where a drive for "consistency" in the model will break the use of the SINGLE_THREAD_MODEL. No one can write portable code using the SINGLE_THREAD_MODEL that needs to make collocated recursive calls with this change. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Sender: vinoski@mail.boston.iona.ie Date: Mon, 22 Feb 1999 17:14:51 -0500 To: Jonathan Biggar From: Steve Vinoski Subject: Re: Core RTF 2.4 Vote 4 Cc: Jishnu Mukerji , Jeff Mischkinsky , "Robert A. Kukura" , Tom Rutt , Stephen McNamara , Randy Fox , Bill Janssen , Michi Henning , Juan Jose Hierro Sureda , Bill Beckwith , Paul Kyzivat , Ken Cavanaugh , Edward Cobb , orb_revision@omg.org References: <36CDDA7B.BD455FF4@fpk.hp.com> At 01:19 PM 2/20/99 -0800, Jonathan Biggar wrote: >Comments: > >616: I suppose I have already made my objections to this one pretty >clear. To recap, it breaks the Java language binding portable skeletons >by removing a feature that was specifically added to the POA. Removing >this feature is a step backwards. As the originator of issue 616 and someone who has watched the recent email discussion concerning it, I'm very surprised that it is being voted on at this time. It seems pointless to vote on something that is nowhere near being agreed upon. I'd like to urge Core RTF members to follow Jon Biggar's lead and vote no on the proposed resolution for 616. As Jon correctly points out, it breaks the Java language mapping and undoes an explicit change made for portable skeletons. It also misses the mark on my original issue, which both Jon and Bob Kukura have pointed out in recent email messages. --steve Date: Mon, 22 Feb 1999 18:11:28 -0500 From: Paul H Kyzivat Organization: NobleNet To: Steve Vinoski CC: Jonathan Biggar , Jishnu Mukerji , Jeff Mischkinsky , "Robert A. Kukura" , Tom Rutt , Stephen McNamara , Randy Fox , Bill Janssen , Michi Henning , Juan Jose Hierro Sureda , Bill Beckwith , Ken Cavanaugh , Edward Cobb , orb_revision@omg.org Subject: Re: Core RTF 2.4 Vote 4 References: <36CDDA7B.BD455FF4@fpk.hp.com> <4.1.19990222170826.00c853f0@mail.boston.iona.ie> Perhaps I chose a poor way to proceed with this - I am pretty new to participating in RTFs. If so I apologize. I let it go for a vote because it was the best way I could see to straw poll all the voters. My earlier postings had some nice, interesting discussion, but with only 2 or three participants. Given that there seem to be definite trade-offs, I wanted to get a full range of opinions. I would prefer that people vote their opinion, rather than just voting NO on procedural grounds. If everyone's opinion is NO, then that is good data for how to proceed. Paul Steve Vinoski wrote: > > At 01:19 PM 2/20/99 -0800, Jonathan Biggar wrote: > >Comments: > > > >616: I suppose I have already made my objections to this one > pretty > >clear. To recap, it breaks the Java language binding portable > skeletons > >by removing a feature that was specifically added to the POA. > Removing > >this feature is a step backwards. > > As the originator of issue 616 and someone who has watched the > recent > email > discussion concerning it, I'm very surprised that it is being voted > on > at > this time. It seems pointless to vote on something that is nowhere > near > being agreed upon. > > I'd like to urge Core RTF members to follow Jon Biggar's lead and > vote > no > on the proposed resolution for 616. As Jon correctly points out, it > breaks > the Java language mapping and undoes an explicit change made for > portable > skeletons. It also misses the mark on my original issue, which both > Jon and > Bob Kukura have pointed out in recent email messages. Date: Tue, 23 Feb 1999 11:32:52 +1000 (EST) From: Michi Henning To: Core Revision Task Force Subject: DSTC's vote 4 Organization: Triodia Technologies DSTC votes yes on 2314, 2343, 2436, and 2454. DSTC votes no on 616 and 2308 DSTC casts no vote (that's not a "no" vote, but no vote at all ;-) on 1665 because, as Jishnu says, 1665 will (maybe) be included in the next round. Rationale on 616: I agree with Jon that breaking language bindings without warning or consultation is bad form. Rationale on 2308: I see no reason for making the behavior of a recursive call on the same servant illegal, at least not without further arguments to convince me otherwise. Also, we should watch out for interactions between 2308 and 2303 (about serialization of POA requests). It would be embarrassing to come to conflicting resolutions... Suggestion: Subsume 2308 into 2303 and deal with them as a single issue. They are closely related. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Tue, 23 Feb 1999 16:41:18 -0500 From: Paul H Kyzivat Organization: NobleNet To: CORE RTF Subject: Re: Issue 616: POA::id_to_reference() References: <36B5EBA9.B2A1E718@noblenet.com> <36BF4B90.5171CA49@noblenet.com> While I haven't seen a tally of the votes yet, it appears that my proposal for 616 has been voted down. In this case it seems that people can't stomach an incompatible change for the sake of cleaning things up. So, I can propose it the other way - make all of the X_to_Y operations that are appropriate take cognizance of the invocation context. Is that enough? Or should the values *also* be directly available from Current, where it will be explicit what source they come from? At this point my heart isn't in this one, because I think we are doing the wrong thing, so I am just going to sit back and listen. Sender: jon@floorboard.com Date: Tue, 23 Feb 1999 15:28:49 -0800 From: Jonathan Biggar X-Accept-Language: en To: Paul H Kyzivat CC: CORE RTF Subject: Re: Issue 616: POA::id_to_reference() References: <36B5EBA9.B2A1E718@noblenet.com> <36BF4B90.5171CA49@noblenet.com> <36D3207E.4872A1E4@noblenet.com> Paul H Kyzivat wrote: > > While I haven't seen a tally of the votes yet, it appears that my > proposal for 616 has been voted down. In this case it seems that > people > can't stomach an incompatible change for the sake of cleaning things > up. > > So, I can propose it the other way - make all of the X_to_Y > operations > that are appropriate take cognizance of the invocation context. > > Is that enough? Or should the values *also* be directly available > from > Current, where it will be explicit what source they come from? > > At this point my heart isn't in this one, because I think we are > doing > the wrong thing, so I am just going to sit back and listen. Let me propose a compromise: 1. I don't particularly mind adding Current::get_servant() to get the servant and Current::get_reference() to get the reference, as long as the definition of Current::get_reference() makes it clear that this is not necessarily the reference that the client used to invoke the operation, but one generated by the server that refers to the same object. So I would vote in favor of adding these operations to Current. Having a Current::get_servant() operation would simplify the use of the C++ tie servant, since the tied object would no longer need to store a pointer to the servant. 2. I would also support deprecating the behavior of servant_to_reference() that takes the invocation context into account, as long as enough time is given for the Java mapping (or others) to convert to using Current::get_reference(). This would mean not changing this operations behavior until at least the next minor CORBA revision. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 23 Feb 1999 19:23:27 -0500 From: Paul H Kyzivat Organization: NobleNet To: Jonathan Biggar CC: CORE RTF Subject: Re: Issue 616: POA::id_to_reference() References: <36B5EBA9.B2A1E718@noblenet.com> <36BF4B90.5171CA49@noblenet.com> <36D3207E.4872A1E4@noblenet.com> <36D339B1.97FB8D56@floorboard.com> Jonathan Biggar wrote: > > Let me propose a compromise: > > 1. I don't particularly mind adding Current::get_servant() to get > the > servant and Current::get_reference() to get the reference, as long > as > the definition of Current::get_reference() makes it clear that this > is > not necessarily the reference that the client used to invoke the > operation, but one generated by the server that refers to the same > object. So I would vote in favor of adding these operations to > Current. > > Having a Current::get_servant() operation would simplify the use of > the > C++ tie servant, since the tied object would no longer need to store > a > pointer to the servant. > > 2. I would also support deprecating the behavior of > servant_to_reference() that takes the invocation context into > account, > as long as enough time is given for the Java mapping (or others) to > convert to using Current::get_reference(). This would mean not > changing > this operations behavior until at least the next minor CORBA > revision. I am happy with this compromise. Posted-Date: Mon, 1 Mar 1999 09:29:54 +0100 (MET) Sender: jhierro@tid.es Date: Mon, 01 Mar 1999 09:26:26 +0100 From: Juan Jose Hierro Sureda Organization: Telefonica I+D To: Jishnu Mukerji CC: Jeff Mischkinsky , "Robert A. Kukura" , Tom Rutt , Jonathan Biggar , Stephen McNamara , Randy Fox , Bill Janssen , Michi Henning , Juan Jose Hierro Sureda , Bill Beckwith , Paul Kyzivat , Ken Cavanaugh , Edward Cobb , orb_revision@omg.org Subject: Re: Core RTF 2.4 Vote 4 References: <36CDDA7B.BD455FF4@fpk.hp.com> Hello all, I couldn't send this email on friday. For some strange reason, it didn't go through the email system. It is my vote to Core RTF 2.4 Vote 4. YES: 2343, 2436, 2454 ABSTAIN: 2308, 2314 NO: 616 (the proposed get_reference operation in Current is fine but I'm concerning about breaking the current Java mapping) I would suggest opening a different issue which requests for inclusion of get_reference in the POA Current interface. That issue would be different from issue 616. Best regards, -- Juanjo Date: Mon, 01 Mar 1999 18:34:16 -0500 From: Paul H Kyzivat Organization: NobleNet To: Jishnu Mukerji CC: CORE RTF Subject: Re: Resolutions to vote on this Friday References: <36DB18A8.C4F78ABF@fpk.hp.com> Jishnu Mukerji wrote: > > Paul, > > Let me know which issues of yours are going to be ready to vote on > by > this Friday. As far as I can tell the following are still to be > resolved: > > 616, 962, 963, and the infamous 1665. I don't know. Here is status as best I understand. Let me know what you think: 616: My last cut has not been accepted. Jon suggested a compromise that I could live with. I guess it is up to me to turn it into a draft proposal. But I don't know if there is concensus or if it still needs more discussion. I don't believe anybody replied to Jon. 962, 963: These were George Scott's issues. He agreed to write up proposals for them. So I haven't been worrying about them. I don't consider them very important, and since they are his in the first place, they can stay unresolved until he has the time. 1665: I already posted a revised draft for comments last Thurs, but so far there have been none. Considering the bitching that went on last time I don't know if this is ready to vote or not. 2303: I posted an approach (without revised text) that has received some support, but again I am not sure if we have anything like concensus. I am not in a rush to turn this into revised text unless it is clear that there is concensus on the approach, because this one is going to be a pain to write up. 2308: My proposed wording has been strongly objected to from both directions. I have no idea what to propose here. I have asked Jon or Michi to propose something if they like. (But I doubt they can propose anything that won't be objected to by someone else.) Do you think I should try to get a vote on any of these this week? You can put my most recent text for 1665 up to a vote if you like. Sender: jis@fpk.hp.com Message-ID: <38162D2B.76E57EC2@fpk.hp.com> Date: Tue, 26 Oct 1999 18:37:31 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: orb_revision@omg.org Subject: Issue 616 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 64Yd9o2H!!X+0!!GpWd9 OK let me stir the pot a little on this one. Subject: id_to_reference() and WrongPolicy See http://www.omg.org/issues/issue616.txt I noticed a potential problem with POA::id_to_reference() a few weeks ago when asnwering a comp.object.corba question. Within the context of a request invocation, the POA current can return the ObjectId for the target object. Presumably, one could then pass this to POA::id_to_reference() in order to get the object reference used to invoke the target. Unfortunately, this does not seem to be true in the non-retain case, since the spec says that WrongPolicy is raised if retain is not set. This means that getting the target object reference is not possible in the non-retain case. Surely the spec meant to say that id_to_reference() and id_to_servant() could always be called within the context of a request invocation, regardless of POA policy? Or am I missing something? ________________________________________________________ The last concrete compromise proposal was: 1. I don't particularly mind adding Current::get_servant() to get the servant and Current::get_reference() to get the reference, as long as the definition of Current::get_reference() makes it clear that this is not necessarily the reference that the client used to invoke the operation, but one generated by the server that refers to the same object. So I would vote in favor of adding these operations to Current. Having a Current::get_servant() operation would simplify the use of the C++ tie servant, since the tied object would no longer need to store a pointer to the servant. 2. I would also support deprecating the behavior of servant_to_reference() that takes the invocation context into account, as long as enough time is given for the Java mapping (or others) to convert to using Current::get_reference(). This would mean not changing this operations behavior until at least the next minor CORBA revision. If this is considered acceptable then we have the following: ___________________________________________________________ Resolution: Add the operations get_servant and get_reference to PortableSerever::Current, such that get_reference returns a locally manufactured reference to the target object of this invocation, and the get_servant returns the servant that hosts the target object of this invocation. Question do we want to deprecate servant_to_reference or let it be as is? Revised text: 1. Append the following to section 11.3.9: _______________________________________________________________- 11.3.9.3 get_reference Object get_reference() raises(NoContext); This operation returns a locally manufactured reference to the object in whose context it is called. If called outside the context of a POA dispatched operation, a NoContext exception is raised. 11.3.9.4 get_servant Servant get_servant() raises(NoContext); This operation returns a reference to the servant that hosts the object in whose context it is called. If called outside the context of a POA dispatched operation, a NoContext exception is raised. __________________________________________________________________ 2. In the IDL for PortableServer::Current on page 11-47, append the following lines within the scope of the interface Current (i.e. immediately following the line that reads "ObjectId get_object_id() raises(NoContext);": Object get_reference() raises(NoContext); Servant get_servant() raises(NoContext); ______________________________________________________________ Comments? Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Wed, 27 Oct 1999 09:36:19 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: Jishnu Mukerji CC: orb_revision@omg.org Subject: Re: Issue 616 X-Priority: 3 (Normal) References: <38162D2B.76E57EC2@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: !(E!!Bo/e9hN3e9oHod9 Jishnu Mukerji wrote: > > OK let me stir the pot a little on this one. > > Subject: id_to_reference() and WrongPolicy Jishnu, My memory is a little hazy on this, but I think I remember we discussed this and related topics ad nauseum. If I remember right, we decided that this sort of operation on the POA ought to be independent of the invocation context, and so is ok the way it is. Instead, we decided (via another issue that is still open I think) to provide more information from POACurrent. Of course this may just be wishful thinking on my part rather than a correct memory. Paul > > See http://www.omg.org/issues/issue616.txt > > I noticed a potential problem with POA::id_to_reference() a few > weeks > ago when asnwering a comp.object.corba question. > > Within the context of a request invocation, the POA current can > return the ObjectId for the target object. Presumably, one could > then pass this to POA::id_to_reference() in order to get the object > reference used to invoke the target. > > Unfortunately, this does not seem to be true in the non-retain case, > since the spec says that WrongPolicy is raised if retain is not set. > This means that getting the target object reference is not possible > in the non-retain case. > > Surely the spec meant to say that id_to_reference() and > id_to_servant() could always be called within the context of a > request invocation, regardless of POA policy? Or am I missing > something? > > ________________________________________________________ > > The last concrete compromise proposal was: > > 1. I don't particularly mind adding Current::get_servant() to get > the > servant and Current::get_reference() to get the reference, as long > as > the definition of Current::get_reference() makes it clear that this > is > not necessarily the reference that the client used to invoke the > operation, but one generated by the server that refers to the same > object. So I would vote in favor of adding these operations to > Current. > > Having a Current::get_servant() operation would simplify the use of > the C++ tie servant, since the tied object would no longer need to > store a > pointer to the servant. > > 2. I would also support deprecating the behavior of > servant_to_reference() that takes the invocation context into > account, > as long as enough time is given for the Java mapping (or others) to > convert to using Current::get_reference(). This would mean not > changing this operations behavior until at least the next minor > CORBA > revision. > > If this is considered acceptable then we have the following: > ___________________________________________________________ > > Resolution: Add the operations get_servant and get_reference to > PortableSerever::Current, such that get_reference returns a locally > manufactured > reference to the target object of this invocation, and the > get_servant > returns > the servant that hosts the target object of this invocation. > > Question do we want to deprecate servant_to_reference or let it be > as > is? > > Revised text: > > 1. Append the following to section 11.3.9: > > _______________________________________________________________- > > 11.3.9.3 get_reference > > Object get_reference() raises(NoContext); > > This operation returns a locally manufactured reference to the > object > in whose > context it is called. If called outside the context of a POA > dispatched > operation, a NoContext exception is raised. > > 11.3.9.4 get_servant > > Servant get_servant() raises(NoContext); > > This operation returns a reference to the servant that hosts the > object in whose > context it is called. If called outside the context of a POA > dispatched > operation, a NoContext exception is raised. > > __________________________________________________________________ > > 2. In the IDL for PortableServer::Current on page 11-47, append the > following > lines within the scope of the interface Current (i.e. immediately > following the > line that reads "ObjectId get_object_id() raises(NoContext);": > > Object get_reference() raises(NoContext); > > Servant get_servant() raises(NoContext); > > ______________________________________________________________ > > Comments? > > Jishnu. > > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jon@floorboard.com Message-ID: <381898FC.55ED6BF3@floorboard.com> Date: Thu, 28 Oct 1999 11:42:04 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: orb_revision@omg.org Subject: Re: Issue 616 References: <38162D2B.76E57EC2@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 0!\!!R0~!!b!#!!C$;e9 Jishnu Mukerji wrote: > The last concrete compromise proposal was: > > 1. I don't particularly mind adding Current::get_servant() to get > the > servant and Current::get_reference() to get the reference, as long > as > the definition of Current::get_reference() makes it clear that this > is > not necessarily the reference that the client used to invoke the > operation, but one generated by the server that refers to the same > object. So I would vote in favor of adding these operations to > Current. > > Having a Current::get_servant() operation would simplify the use of > the C++ tie servant, since the tied object would no longer need to > store a > pointer to the servant. > > 2. I would also support deprecating the behavior of > servant_to_reference() that takes the invocation context into > account, > as long as enough time is given for the Java mapping (or others) to > convert to using Current::get_reference(). This would mean not > changing this operations behavior until at least the next minor > CORBA revision. I don't see a particular reason to deprecate it, since we added that feature to fix the Java mapping problem (the need for portable stubs to make _this() work). > If this is considered acceptable then we have the following: > ___________________________________________________________ > > Resolution: Add the operations get_servant and get_reference to > PortableSerever::Current, such that get_reference returns a locally > manufactured > reference to the target object of this invocation, and the > get_servant returns > the servant that hosts the target object of this invocation. > > Question do we want to deprecate servant_to_reference or let it be > as is? I say leave it alone. > Revised text: > > 1. Append the following to section 11.3.9: > > _______________________________________________________________- > > 11.3.9.3 get_reference > > Object get_reference() raises(NoContext); > > This operation returns a locally manufactured reference to the > object in whose > context it is called. If called outside the context of a POA > dispatched > operation, a NoContext exception is raised. I think we should add the following as well: Note: This reference is not guaranteed to be identical to the original reference the client used to make the invocation, and calling the Object::is_equivalent operation to compare the two references may not necessarily return true. > 11.3.9.4 get_servant > > Servant get_servant() raises(NoContext); > > This operation returns a reference to the servant that hosts the > object in whose > context it is called. If called outside the context of a POA > dispatched > operation, a NoContext exception is raised. > > __________________________________________________________________ > > 2. In the IDL for PortableServer::Current on page 11-47, append the > following > lines within the scope of the interface Current (i.e. immediately > following the > line that reads "ObjectId get_object_id() raises(NoContext);": > > Object get_reference() raises(NoContext); > > Servant get_servant() raises(NoContext); > > ______________________________________________________________ Other than my above comment this seems fine. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jis@fpk.hp.com Message-ID: <38189D78.2CB91A0D@fpk.hp.com> Date: Thu, 28 Oct 1999 15:01:12 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Jonathan Biggar CC: orb_revision@omg.org Subject: Re: Issue 616 References: <38162D2B.76E57EC2@fpk.hp.com> <381898FC.55ED6BF3@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: nii!!h)Oe9V4Y!!4;De9 Jon, Thanks. I'll add that paragraph, and remove any deprecation language that might have sneaked in. Then I will send it in for a vote and see if that generates further comments. Thanks, Jishnu. Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > The last concrete compromise proposal was: > > > > 1. I don't particularly mind adding Current::get_servant() to get > the > > servant and Current::get_reference() to get the reference, as long > as > > the definition of Current::get_reference() makes it clear that > this is > > not necessarily the reference that the client used to invoke the > > operation, but one generated by the server that refers to the same > > object. So I would vote in favor of adding these operations to > > Current. > > > > Having a Current::get_servant() operation would simplify the use > of > > the C++ tie servant, since the tied object would no longer need to > store a > > pointer to the servant. > > > > 2. I would also support deprecating the behavior of > > servant_to_reference() that takes the invocation context into > account, > > as long as enough time is given for the Java mapping (or others) > to > > convert to using Current::get_reference(). This would mean not > > changing this operations behavior until at least the next minor > CORBA revision. > > I don't see a particular reason to deprecate it, since we added that > feature to fix the Java mapping problem (the need for portable stubs > to > make _this() work). > > > If this is considered acceptable then we have the following: > > ___________________________________________________________ > > > > Resolution: Add the operations get_servant and get_reference to > > PortableSerever::Current, such that get_reference returns a > locally manufactured > > reference to the target object of this invocation, and the > get_servant returns > > the servant that hosts the target object of this invocation. > > > > Question do we want to deprecate servant_to_reference or let it be > as is? > > I say leave it alone. > > > Revised text: > > > > 1. Append the following to section 11.3.9: > > > > _______________________________________________________________- > > > > 11.3.9.3 get_reference > > > > Object get_reference() raises(NoContext); > > > > This operation returns a locally manufactured reference to the > object in whose > > context it is called. If called outside the context of a POA > dispatched > > operation, a NoContext exception is raised. > > I think we should add the following as well: > > Note: This reference is not guaranteed to be identical to the > original > reference the client used to make the invocation, and calling the > Object::is_equivalent operation to compare the two references may > not > necessarily return true. > > > 11.3.9.4 get_servant > > > > Servant get_servant() raises(NoContext); > > > > This operation returns a reference to the servant that hosts the > object in whose > > context it is called. If called outside the context of a POA > dispatched > > operation, a NoContext exception is raised. > > > > __________________________________________________________________ > > > > 2. In the IDL for PortableServer::Current on page 11-47, append > the following > > lines within the scope of the interface Current (i.e. immediately > following the > > line that reads "ObjectId get_object_id() raises(NoContext);": > > > > Object get_reference() raises(NoContext); > > > > Servant get_servant() raises(NoContext); > > > > ______________________________________________________________ > > Other than my above comment this seems fine. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Fri, 29 Oct 1999 08:32:26 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: Jonathan Biggar CC: Jishnu Mukerji , orb_revision@omg.org Subject: Re: Issue 616 X-Priority: 3 (Normal) References: <38162D2B.76E57EC2@fpk.hp.com> <381898FC.55ED6BF3@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: )>2!!=;\!! > > 2. I would also support deprecating the behavior of > > servant_to_reference() that takes the invocation context into > > account, as long as enough time is given for the Java mapping (or > > others) to convert to using Current::get_reference(). This would > > mean not changing this operations behavior until at least the next > > minor CORBA revision. > > I don't see a particular reason to deprecate it, since we added that > feature to fix the Java mapping problem (the need for portable stubs > to make _this() work). I believe the new operations on Current (namely get_reference) provide an alternative way to solve the Java mapping problem with _this(). The reason for deprecating this feature is that context sensitive behavior like this is generally a bad idea - it leads to confusion and misunderstanding. Going the deprecation route means that orbs can keep the old behavior for awhile until things like the java mapping are resolved. Sender: jis@fpk.hp.com Message-ID: <381F4323.48B5AB90@fpk.hp.com> Date: Tue, 02 Nov 1999 15:01:39 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: orb_revision@omg.org, "Juan J. Hierro" Subject: Re: Core RTF 2k Vote 3 Announcement References: <381A0B26.E45E7741@fpk.hp.com> <381ECB42.6E5B33F8@tid.es> <381F2145.A867BDA6@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: A#Sd9X;Fe9/A'!!g(~e9 Jishnu Mukerji wrote: > > Juan J. Hierro wrote: > > > I guess that all members agree with my amendment to resolution > > of issue 616. It seems like it is an editorial mistake in the > > proposed revised text ... However, some people have already voted > > YES for adoption of the proposed text for issue 616 ... PLEASE > > REVISE YOUR VOTE AND DECLARE WHETHER YOU AGREE OR NOT WITH MY > > PROPOSED AMENDMENT. Ahhhhh! Now I see where it is an editorial mistake. It is the second occurence of it that is an editorial mistake, and yes indeed it is. Sorry about protesting too soon.:-} (sheepish grin). Yes that is fixed editorially, and Juan, your vote on 616 is now recorded as YES as per your earlier request. Please pardon my hasty response earlier. Thanks for your understanding, cooperation and indulgence, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Posted-Date: Wed, 3 Nov 1999 16:05:24 +0100 (MET) Message-ID: <38204F3C.40FD25FE@tid.es> Date: Wed, 03 Nov 1999 16:05:32 +0100 From: "Juan J. Hierro" Organization: Telefonica I+D X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: Jishnu Mukerji CC: orb_revision@omg.org Subject: Re: Core RTF 2k Vote 3 Announcement References: <381A0B26.E45E7741@fpk.hp.com> <381ECB42.6E5B33F8@tid.es> <381F2145.A867BDA6@fpk.hp.com> Content-Type: multipart/mixed; boundary="------------517D546DFD967BF8425DA6FB" X-UIDL: m[,e9;MH!!bp[!!/(Pd9 Jishnu Mukerji wrote: > > Juan J. Hierro wrote: > > > I guess that all members agree with my amendment to resolution > > of issue 616. It seems like it is an editorial mistake in the > > proposed revised text ... However, some people have already voted > > YES for adoption of the proposed text for issue 616 ... PLEASE > > REVISE YOUR VOTE AND DECLARE WHETHER YOU AGREE OR NOT WITH MY > > PROPOSED AMENDMENT. > > The votes that come in with suggetion like "YES" with the following > change will > be counted as "NO", unless, the proposed change of word is purely > editorial. The > judgement call on what is editorial will be made by me (ahem the > Chair) based on > advise from the voters, and knowledge of the history of how the > proposal came to > be in the form it is in. > Ok. > It is my intention to enforce this modus operandi because it is very difficult > for voters to keep track of what they are exactly voting on if the proposed > resolutions keep changing underneath them while a vote is in progress. Ok. I see your point, and will follow the modus operandi you propose from now on. > So in > effect the resolutions are frozen for that vote for the duration of > the vote, as > soon as the vote is announced. Revised resolutions can be presented > in a > subsequent vote addressing concerns raised during a previous vote. > Ok. > So, in this particular case, since that language was specifically included as an > add-on request by the proposer of the resolution (Jon Biggar), it is hereby > ruled to be not an editorial mistake. > Understood. > Please just vote YES or NO on the resolution as presented, and put an alternate > resolution up for vote in the next round, if you feel strongly enough about it. > Based on your clarifications, Telefonica I+D votes NO. > Thanks for your understanding, cooperation and indulgence, > Thanks to you for your clarifications. Best regards, -- Juanjo [] vcard1.vcf