Issue 2513: POA issue, section 11.3.8.10 (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Section 11.3.8.10 of the Core draft 2.3a says that the application is free to assign its own servant manager to the root POA, but the next section says that the set_servant_manager() operation requires that the POA in question must support the request processing policy of USE_SERVANT_MANAGER. But as the root POA has a req. proc. policy of USE_ACTIVE_OBJECT_MAP_ONLY, surely the user CANNOT assign a servant manager to the root POA. The text is a mistake, isn"t it? The application cannot "assign its own servant manager to the root POA". Unless there is some subtlety to the meaning of the word "assign" which make it different from "set". I thought the root POA was something the user could not tamper with in any way. Resolution: Revised Text: Actions taken: March 5, 1999: received issue October 30, 2000: closed issue Discussion: End of Annotations:===== ender: "George Scott" Date: Thu, 04 Mar 1999 19:42:36 -0800 From: "George M. Scott" Organization: Inprise Corporation X-Accept-Language: en To: java-rtf@omg.org, cxx_revision@omg.org CC: orb_revision@omg.org Subject: Behavior of POA Servant's _this() [Sorry for the broad distribution of this issue, but it falls in several camps. The actual text is in the C++ and Java mapping chapters, but the POA issues are of general interest to orb_revision, so I've included that list as well.] The text describing the use of _this() in the Java and C++ mapping chapters is somewhat confusing and needs to be clarified. In particular section 20.35.5 "Skeleton Operations" of the C++ mapping and section 25.19.2 "Mapping of PortableServer::Servant" of the Java mapping list the three purposes of _this(). The second and third purposes seems to be very important for usability of the POA, but are confusing as worded. The text in section 20.35.5 (C++) states: "2. Outside the context of a request invocation on the target object represented by the servant, [_this()] allows a servant to be implicitly activated if its POA allows implicit activation. This requires the activating POA to have been created with the IMPLICIT_ACTIVATION policy. If the POA was not created with the IMPLICIT_ACTIVATION policy, the PortableServer::WrongPolicy exception is thrown. The POA used for implicit activation is gotten by invoking _default_POA() on the servant." 3. Outside the context of a request invocation on the target object represented by the servant, [_this()] will return the object reference for a servant that has already been activated, as long as the servant is not incarnating multiple CORBA objects. This requires the POA with which the servant was activated to have been created with the UNIQUE_ID and RETAIN policies. If the POA was created with the MULTIPLE_ID or NON_RETAIN policies, the PortableServer::WrongPolicy exception is thrown. The POA is gotten by invoking _default_POA() on the servant." Keeping the above two rules in mind, what should happen when the following code is executed outside the context of a request invocation? // Java // Get the root POA POA rootPOA = POAHelper.narrow(orb.resolve_initial_references("RootPOA")); // create persistent POA for CounterManager Policy policies[] = new Policy[1]; policies[0] = rootPOA.create_lifespan_policy(LifespanPolicyValue.PERSISTENT); POA persistentPOA = rootPOA.create_POA("persistent", null, policies); // create a servant. Assume servant is implementing the IDL interface Foo. MyServant servant = new MyServant(); // Activate the servant persistentPOA.activate_object_with_id(servant, "MyID".getBytes()); // Now invoke _this() Foo foo = servant._this(); What happens when _this() is invoked? From reading the spec, I would say that the value of _default_POA() should be checked and then if the object is activated on that POA and the POA has the approriate policies, then the reference for that object will be returned. Otherwise, if the object is not activated on the POA returned by _default_POA(), and that POA supports implicit activation, the object is implicitly activated. So from my understanding, the call to _this() above would actually activate the servant with the root POA, instead of returning a reference to the already active object on the user created persistent POA. This in my mind does not seem like the correct behavior, and will result in great confusion among users. I think the intention of the spec was that _this() in the above case should in fact return the reference for the servant on the persistent POA, without requiring the user to override the _default_POA() method. (BTW, a reading of the original ORB Portability submission supports this conclusion). There are several cases which I think are important to handle, and I was hoping we could reach agreement on these cases and clarify the the text accordingly. The cases of concern are: 1. In the context of executing a request invocation on the target object represented by the servnat, _this() should return the reference for the target object currently being incarnated by the servant being invoked. (The current text appears to be adequate for this case). 2. Outside the context of request execution on the taget object represented by the servant, there are several cases: a. If the servant has not been activated on any POA, then implicit activation should occur using the POA returned by _default_POA(). If the default POA does not have the IMPLICIT_ACTIVATION policy then the PortableServer::WrongPolicy exception is thrown. (Note, the POA actually needs more than just IMPLICIT_ACTIVATION policy, the text should be updated to be equivalent to servant_to_reference implicit activation text). b. If the servant has been activated with a single POA and that POA has the UNIQUE_ID policy then _this() returns the reference associated with that activation. (Note, I have removed the RETAIN policy requirement since it is implicit, objects cannot be activated on POAs which do not have the RETAIN policy) c. If the servant has been activated with a single POA and that POA has the MULTIPLE_ID policy then _this() throws PortableServer::WrongPolicy. d. If the servant has been activated with multiple POAs then the PortableServer::WrongPolicy exception is thrown. The above behavior is, in my opinion, the intended behavior of _this(), and is generally compatible with a possible interperation of the current specification. If there are no disagreements about this I will write up a formal proposal with the text changes for both the C++ and Java chapters. Of course, I do expect there will be some discussion. ;-) George Date: Fri, 05 Mar 1999 09:32:32 -0500 From: Paul H Kyzivat Organization: NobleNet To: "George M. Scott" CC: java-rtf@omg.org, cxx_revision@omg.org, orb_revision@omg.org Subject: Re: Behavior of POA Servant's _this() References: <36DF52AC.E10A7CE8@inprise.com> George M. Scott wrote: > > What happens when _this() is invoked? From reading the spec, I > would > say that the value of _default_POA() should be checked and then if > the > object is activated on that POA and the POA has the approriate > policies, then the reference for that object will be returned. > Otherwise, if the object is not activated on the POA returned by > _default_POA(), and that POA supports implicit activation, the > object > is implicitly activated. > > So from my understanding, the call to _this() above would actually > activate the servant with the root POA, instead of returning a > reference to the already active object on the user created > persistent > POA. I agree that this is what a conforming implementation must do. (Assuming _default_POA isn't overridden by MyServant.) > This in my mind does not seem like the correct behavior, and will > result in great confusion among users. I think the intention of the > spec was that _this() in the above case should in fact return the > reference for the servant on the persistent POA, without requiring > the > user to override the _default_POA() method. (BTW, a reading of the > original ORB Portability submission supports this conclusion). > > There are several cases which I think are important to handle, and I > was hoping we could reach agreement on these cases and clarify the > the text accordingly. The cases of concern are: > > 1. In the context of executing a request invocation on the target > object > represented by the servnat, _this() should return the reference > for > the target object currently being incarnated by the servant being > invoked. > (The current text appears to be adequate for this case). > > 2. Outside the context of request execution on the taget object > represented > by the servant, there are several cases: > > a. If the servant has not been activated on any POA, then > implicit > activation should occur using the POA returned by > _default_POA(). > If the default POA does not have the IMPLICIT_ACTIVATION > policy > then the PortableServer::WrongPolicy exception is thrown. > (Note, > the POA actually needs more than just IMPLICIT_ACTIVATION > policy, > the text should be updated to be equivalent to > servant_to_reference > implicit activation text). > > b. If the servant has been activated with a single POA and that > POA > has the UNIQUE_ID policy then _this() returns the reference > associated with that activation. (Note, I have removed the > RETAIN > policy requirement since it is implicit, objects cannot be > activated > on POAs which do not have the RETAIN policy) > > c. If the servant has been activated with a single POA and that > POA > has the MULTIPLE_ID policy then _this() throws > PortableServer::WrongPolicy. > > d. If the servant has been activated with multiple POAs then the > PortableServer::WrongPolicy exception is thrown. This implies that you expect the orb to, in effect, override the implementation of _default_POA for servants that have been activated. The ways that come immediately to mind to do this are: - Each servant must remember all the POAs in which it is activated - Each servant must keep track of how many POAs it is activated in and which one if only one. When deactivation results in the count going from 2 to 1, it will have to search all POAs for the one it is activated in. - _this() must search all POAs for activations of the servant. All of these alternatives seem expensive compared to the benefit. While it would be nice for _this to work in a more intuitive way, I don't think a behavior that takes a page of text to describe will ever be intuitive. A truly intuitive understanding of _this requires that a servant only be associated with one object reference. In any case, the proposal is a fairly radical and incompatible change for those of us that are already shipping a POA implementation, and for our customers. I don't see any way to make this change in an upward compatible way. I would like to see things left the way they are. X-Sender: vinoski@mail.boston.iona.ie Date: Fri, 05 Mar 1999 11:20:37 -0500 To: Paul H Kyzivat From: Steve Vinoski Subject: Re: Behavior of POA Servant's _this() Cc: "George M. Scott" , java-rtf@omg.org, cxx_revision@omg.org, orb_revision@omg.org References: <36DF52AC.E10A7CE8@inprise.com> I agree completely with Paul. --steve At 09:32 AM 3/5/99 -0500, Paul H Kyzivat wrote: >George M. Scott wrote: >> >> What happens when _this() is invoked? From reading the spec, I would >> say that the value of _default_POA() should be checked and then if the >> object is activated on that POA and the POA has the approriate >> policies, then the reference for that object will be returned. >> Otherwise, if the object is not activated on the POA returned by >> _default_POA(), and that POA supports implicit activation, the object >> is implicitly activated. >> >> So from my understanding, the call to _this() above would actually >> activate the servant with the root POA, instead of returning a >> reference to the already active object on the user created persistent >> POA. > >I agree that this is what a conforming implementation must do. >(Assuming _default_POA isn't overridden by MyServant.) > >> This in my mind does not seem like the correct behavior, and will >> result in great confusion among users. I think the intention of the >> spec was that _this() in the above case should in fact return the >> reference for the servant on the persistent POA, without requiring the >> user to override the _default_POA() method. (BTW, a reading of the >> original ORB Portability submission supports this conclusion). >> >> There are several cases which I think are important to handle, and I >> was hoping we could reach agreement on these cases and clarify the >> the text accordingly. The cases of concern are: >> >> 1. In the context of executing a request invocation on the target >> object >> represented by the servnat, _this() should return the reference for >> the target object currently being incarnated by the servant being >> invoked. >> (The current text appears to be adequate for this case). >> >> 2. Outside the context of request execution on the taget object >> represented >> by the servant, there are several cases: >> >> a. If the servant has not been activated on any POA, then implicit >> activation should occur using the POA returned by >> _default_POA(). >> If the default POA does not have the IMPLICIT_ACTIVATION policy >> then the PortableServer::WrongPolicy exception is thrown. >> (Note, >> the POA actually needs more than just IMPLICIT_ACTIVATION >> policy, >> the text should be updated to be equivalent to >> servant_to_reference >> implicit activation text). >> >> b. If the servant has been activated with a single POA and that POA >> has the UNIQUE_ID policy then _this() returns the reference >> associated with that activation. (Note, I have removed the >> RETAIN >> policy requirement since it is implicit, objects cannot be >> activated >> on POAs which do not have the RETAIN policy) >> >> c. If the servant has been activated with a single POA and that POA >> has the MULTIPLE_ID policy then _this() throws >> PortableServer::WrongPolicy. >> >> d. If the servant has been activated with multiple POAs then the >> PortableServer::WrongPolicy exception is thrown. > >This implies that you expect the orb to, in effect, override the >implementation of _default_POA for servants that have been activated. >The ways that come immediately to mind to do this are: > >- Each servant must remember all the POAs in which it is activated > >- Each servant must keep track of how many POAs it is activated in > and which one if only one. When deactivation results in the count > going from 2 to 1, it will have to search all POAs for the one > it is activated in. > >- _this() must search all POAs for activations of the servant. > >All of these alternatives seem expensive compared to the benefit. >While it would be nice for _this to work in a more intuitive way, >I don't think a behavior that takes a page of text to describe >will ever be intuitive. > >A truly intuitive understanding of _this requires that a >servant only be associated with one object reference. > >In any case, the proposal is a fairly radical and incompatible change >for those of us that are already shipping a POA implementation, and for >our customers. I don't see any way to make this change in an upward >compatible way. > >I would like to see things left the way they are. Date: Fri, 05 Mar 1999 19:44:04 -0800 From: "George Scott" Organization: Inprise Corporation X-Accept-Language: en To: Paul H Kyzivat CC: java-rtf@omg.org, cxx_revision@omg.org, orb_revision@omg.org, gscott@inprise.com Subject: Re: Behavior of POA Servant's _this() References: <36DF52AC.E10A7CE8@inprise.com> <36DFEB00.E462DF08@noblenet.com> Paul H Kyzivat wrote: > > George M. Scott wrote: > > > > What happens when _this() is invoked? From reading the spec, I > would > > say that the value of _default_POA() should be checked and then if > the > > object is activated on that POA and the POA has the approriate > > policies, then the reference for that object will be returned. > > Otherwise, if the object is not activated on the POA returned by > > _default_POA(), and that POA supports implicit activation, the > object > > is implicitly activated. > > > > So from my understanding, the call to _this() above would actually > > activate the servant with the root POA, instead of returning a > > reference to the already active object on the user created > persistent > > POA. > > I agree that this is what a conforming implementation must do. > (Assuming _default_POA isn't overridden by MyServant.) Yes, I was assuming MyServant didn't override _default_POA(), sorry I didn't make that clear. > > This in my mind does not seem like the correct behavior, and will > > result in great confusion among users. I think the intention of > the > > spec was that _this() in the above case should in fact return the > > reference for the servant on the persistent POA, without requiring > the > > user to override the _default_POA() method. (BTW, a reading of > the > > original ORB Portability submission supports this conclusion). I wanted to clarify the above paragraph, and explain how I arrived at my conclusion. First, my conclusion is based on the original POA submission as finally published in CORBA 2.2. Subsequent changes applied to the specification of _this() in the yet unpublished CORBA 2.3 have only served to confuse the situation. First, let me talk about the _default_POA() method. The original submission and CORBA 2.2 state the following in Section 9.3.1 "The Servant IDL Type" (this text is identical in the current CORBA 2.3a draft section 11.3.1): "Values of type Servant support a language-specific programming interface that can be used by the ORB to obtain a default POA for that servant. This interface is used only to support implicit activation. A language mapping may provide a default implementation of this interface that returns the root POA of a default ORB." Please remember the key phrase "This intefaces is used *only* to support implicit activation" for our dicussion of _this() in a moment. The CORBA 2.2 C++ mapping chapter defines the _default_POA() method, but says nothing about its purpose. However, since its default behavior is defined and matches that of Section 9.3.1 it is fairly obvious the _default_POA() method is the "language-specific programming interface that can be used by the ORB to obtain a default POA". Now on to _this(). The _this() method is a language-mapping specific method and is defined in the C++ mapping chapter. The original CORBA 2.2 text is defined in section 20.34.2 "Skeleton operations" as follows: "All skeleton classes provide a _this() member function. This member function has three purposes: 1. Within the context of a request invocation on the target object represented by the servant, it allows the servant to obtain the object reference for the target CORBA object it is incarnating for that request. This is true even if the servant incarnates multiple CORBA objects. In this context, _this() can be called regardless of the policies the dispatching POA was created with. 2. Outside the context of a request invocation on the target object represented by the servant, it allows a servant to be implicitly activated if its POA allows implicit activation. This requires the activating POA to have been created with the IMPLICIT_ACTIVATION policy. If the POA was not created with the IMPLICIT_ACTIVATION policy, the PortableServer::WrongPolicy exception is thrown. 3. Outside the context of a request invocation on the target object represented by the servant, it will return the object reference for a servant that has already been activated, as long as the servant is not incarnating multiple CORBA objects. This requires the POA with which the servant is activated to have been created with the UNIQUE_ID and RETAIN policies. If the POA was created with the MULTIPLE_ID or NON_RETAIN policies, the PortableServer::WrongPolicy exception is thrown." Now, if you notice there is absolutely no mention in this text about the use of the _default_POA() method during processing of _this(). This is clearly a problem for case number 2, which needs some way to determine what POA should be used for implicit activation. However, it is not a problem for case number 3, which states "[_this()] will return the object reference for a servant that has already been activated, as long as the servant is not incarnating multiple CORBA objects." So assuming the example in my original message, the _this() method should return the reference for the already active Servant, and not result in a new implicit activation of that servant on the root POA. I believe the original text supports my conclusion, but I'm sure somebody will attempt to argue otherwise. Now the problem I was attempting to point out in my message, was the behavior for _this() was modified during our CORBA 2.3a work. The result of which is very confusing and contradictory. In particular the sentence "The POA used for implicit activation is gotten by invoking _default_POA() on the servant." was added to the end of the paragraph for case number 2, and the sentence "The POA is gotten by invoking _default_POA() on the servant." was added to the end of the paragraph for case number 3. Now the addition of the text to case number 2 I can agree with completely. It is the addition of the sentence to case number 3 with which I take issue. First, the addition of this text is adding an additional purpose for the _default_POA() method which contradicts the POA's text which states it "is used only to support implicit activation". Second, it is an incompatible change to the behavior of CORBA 2.2. Third, it results in a large usability problem for users. In the simplest form, my proposal is simply asking to revert case 3 for _this() back to its original form as defined by the POA submission and CORBA 2.2. This can be most easily done by simply removing the sentence "The POA is gotten by invoking _default_POA() on the servant." from the third case. Of course, I was also hoping to further clarify the meaning of the third case for those circumstances in which multiple POAs are involved. The text mentions that _this() will fail if the Servant is incarnating multiple CORBA objects, but assumes this happend because the MULTIPLE_ID policy is set, not because the object has been activated on multiple POAs. Now, on to your points: > This implies that you expect the orb to, in effect, override the > implementation of _default_POA for servants that have been > activated. No, not at all. Again, _default_POA() is only used for implicit activation. It should have nothing to do with _this() behavior when used with servants which are already active. > All of these alternatives seem expensive compared to the benefit. > While it would be nice for _this to work in a more intuitive way, > I don't think a behavior that takes a page of text to describe > will ever be intuitive. The behavior already takes more than half a page of text to describe. I only wish to elaborate slightly on one case, to handle the situation of servants being active on multiple POAs. A case which can happen, and is not well supported by the text. > A truly intuitive understanding of _this requires that a > servant only be associated with one object reference. At least we are in complete agreement on this point. > In any case, the proposal is a fairly radical and incompatible change > for those of us that are already shipping a POA implementation, and for > our customers. I don't see any way to make this change in an upward > compatible way. I don't see how it is radical. It is simply returning to the original spec, and adding a clarification of case 3 when multiple POAs are involved. As far as compatibility, we have already made the incompatible change, it was made as part of the CORBA 2.3a RTF! I'm proposing we at a minimum restore compatibility before CORBA 2.3 is officialy published. Of course, in addition, I would like the case covered when multiple POAs are involved. George Date: Mon, 08 Mar 1999 10:05:18 -0500 From: Paul H Kyzivat Organization: NobleNet To: George Scott CC: java-rtf@omg.org, cxx_revision@omg.org, orb_revision@omg.org Subject: Re: Behavior of POA Servant's _this() References: <36DF52AC.E10A7CE8@inprise.com> <36DFEB00.E462DF08@noblenet.com> <36E0A484.63A295F1@inprise.com> George, This seems to be a case where the original wording allowed reasonable people to make different interpretations of the same words. You argue that the changes made in 2.3a have deviated from the intentions of 2.2 and resulted in an incompatible change. But I interpreted (and implemented) 2.2 the other way, and I gather that at least one other orb vendor made the same interpretation. The changes that were voted in 2.3a are an indication of how the majority thought this was intended to work. To me, and our users, the changes you suggest would be an incompatible change. We can get into reading the tea leaves of 2.2 in order to discern the original intent, but I don't think that is a productive exercise. Instead, I think we ought to consider what is the best way to clarify this, taking into account what is most useful and what is practical to implement. You didn't respond to my comments about the implementation implications of your proposal. Does that mean you think there is an easier way, or that you don't think it matters? More comments interspersed. Paul George Scott wrote: > > I wanted to clarify the above paragraph, and explain how I arrived > at > my conclusion. First, my conclusion is based on the original POA > submission as finally published in CORBA 2.2. Subsequent changes > applied to the specification of _this() in the yet unpublished > CORBA 2.3 have only served to confuse the situation. > > First, let me talk about the _default_POA() method. The original > submission and CORBA 2.2 state the following in Section 9.3.1 > "The Servant IDL Type" (this text is identical in the current > CORBA 2.3a draft section 11.3.1): > > "Values of type Servant support a language-specific programming > interface that can be used by the ORB to obtain a default POA for > that servant. This interface is used only to support implicit > activation. A language mapping may provide a default > implementation of this interface that returns the root POA of a > default ORB." > > Please remember the key phrase "This intefaces is used *only* to > support implicit activation" for our dicussion of _this() in a > moment. I consider this to have been a mistake, in the same way that similar restrictions on _primary_interface have proven to be a mistake. A function does what it does, and should be used when you need that done. That of course begs the question about when the default POA should be used. But I don't think too much should be read into this statement. > > The CORBA 2.2 C++ mapping chapter defines the _default_POA() method, > but says nothing about its purpose. However, since its > default behavior is defined and matches that of Section 9.3.1 it is > fairly obvious the _default_POA() method is the > "language-specific programming interface that can be used by the ORB > to obtain a default POA". > > Now on to _this(). The _this() method is a language-mapping > specific > method and is defined in the C++ mapping chapter. The original > CORBA 2.2 text is defined in section 20.34.2 "Skeleton operations" > as follows: > > "All skeleton classes provide a _this() member function. This member > function has three purposes: > > 1. Within the context of a request invocation on the target object > represented by the servant, it allows the servant to obtain the > object reference for the target CORBA object it is incarnating for > that request. This is true even if the servant incarnates > multiple CORBA objects. In this context, _this() can be called > regardless of the policies the dispatching POA was created with. > > 2. Outside the context of a request invocation on the target object > represented by the servant, it allows a servant to be implicitly > activated if its POA allows implicit activation. This requires the > activating POA to have been created with the > IMPLICIT_ACTIVATION policy. If the POA was not created with the > IMPLICIT_ACTIVATION policy, the PortableServer::WrongPolicy > exception > is thrown. > > 3. Outside the context of a request invocation on the target object > represented by the servant, it will return the object reference for > a servant that has already been activated, as long as the servant > is not incarnating multiple CORBA objects. This > requires the POA with which the servant is activated to have been > created with the UNIQUE_ID and RETAIN policies. If the POA was > created with the MULTIPLE_ID or NON_RETAIN policies, the > PortableServer::WrongPolicy exception is thrown." > > Now, if you notice there is absolutely no mention in this text about > the use of the _default_POA() method during processing of _this(). > This is clearly a problem for case number 2, which needs some way > to determine what POA should be used for implicit activation. > However, it is not a problem for case number 3, which states > "[_this()] will return the object reference for a servant that has > already been activated, as long as the servant is not incarnating > multiple CORBA objects." I interpretted this as meaning "as long as the servant is not incarnating multiple CORBA objects in its default POA". I believe this is a reasonable interpretation, since in many places there are distinctions raised about servants incarnating multiple objects in the same POA, and never about servants incarnating objects in different POAs. Clearly this is not the only possible interpretation, since you see it differently. > > So assuming the example in my original message, the _this() method > should return the reference for the already active Servant, and not > result in a new implicit activation of that servant on the root POA. > I believe the original text supports my conclusion, but I'm sure > somebody will attempt to argue otherwise. > > Now the problem I was attempting to point out in my message, was the > behavior for _this() was modified during our CORBA 2.3a work. The > result of which is very confusing and contradictory. In particular > the sentence > > "The POA used for implicit activation is gotten by invoking > _default_POA() on the servant." > > was added to the end of the paragraph for case number 2, and the > sentence > > "The POA is gotten by invoking _default_POA() on the servant." > > was added to the end of the paragraph for case number 3. > > Now the addition of the text to case number 2 I can agree with > completely. It is the addition of the sentence to case number 3 > with which I take issue. First, the addition of this text is > adding an additional purpose for the _default_POA() > method which contradicts the POA's text which states it "is used > only > to support implicit activation". Second, it is an incompatible > change to the behavior of CORBA 2.2. Third, it results in a large > usability problem for users. > > In the simplest form, my proposal is simply asking to revert case 3 > for _this() back to its original form as defined by the POA > submission and CORBA 2.2. This can be most easily done by simply > removing the sentence "The POA is gotten by > invoking _default_POA() on the servant." from the third case. > > Of course, I was also hoping to further clarify the meaning of the > third case for those circumstances in which multiple POAs are > involved. The text mentions that _this() will fail if the Servant > is incarnating multiple CORBA objects, but assumes this happend > because the MULTIPLE_ID policy is set, not because > the object has been activated on multiple POAs. > > Now, on to your points: > > > This implies that you expect the orb to, in effect, override the > > implementation of _default_POA for servants that have been > activated. > > No, not at all. Again, _default_POA() is only used for implicit > activation. It should have nothing to do with _this() behavior > when used with servants which are already active. > > > All of these alternatives seem expensive compared to the benefit. > > While it would be nice for _this to work in a more intuitive way, > > I don't think a behavior that takes a page of text to describe > > will ever be intuitive. > > The behavior already takes more than half a page of text to > describe. > I only wish to elaborate slightly on one case, to handle the > situation > of servants being active on multiple POAs. A case which can happen, > and is not well supported by the text. I think we are agreeing that neither approach is especially intuitive. We need to document the way it is intended to work. But first we have to agree on what that should be. > > > A truly intuitive understanding of _this requires that a > > servant only be associated with one object reference. > > At least we are in complete agreement on this point. Perhaps it would have been better if things had been designed so it was impossible to do otherwise. > > > In any case, the proposal is a fairly radical and incompatible > > change for those of us that are already shipping a POA > > implementation, and for our customers. I don't see any way to > > make this change in an upward compatible way. > > I don't see how it is radical. It is simply returning to the > original > spec, and adding a clarification of case 3 when multiple POAs are > involved. As far as compatibility, we have already made the > incompatible change, it was made as part of the CORBA 2.3a RTF! > I'm proposing we at a minimum restore compatibility before CORBA 2.3 > is officialy published. Of course, in addition, I would like the > case covered when multiple POAs are involved. As I noted above, it is a radical and incompatible change for those of us that interpretted it as working in the way you dislike. For those that interpretted it as you did, the changes in 2.3a were the radical, incompatible changes. It looks like someone suffers either way. Sender: "George Scott" Date: Mon, 08 Mar 1999 19:56:36 -0800 From: "George M. Scott" Organization: Inprise Corporation X-Accept-Language: en To: Paul H Kyzivat CC: java-rtf@omg.org, cxx_revision@omg.org, orb_revision@omg.org Subject: Re: Behavior of POA Servant's _this() References: <36DF52AC.E10A7CE8@inprise.com> <36DFEB00.E462DF08@noblenet.com> <36E0A484.63A295F1@inprise.com> <36E3E72E.2894B6B4@noblenet.com> Paul H Kyzivat wrote: > > > We can get into reading the tea leaves of 2.2 in order to discern > the > original intent, but I don't think that is a productive exercise. > Instead, I think we ought to consider what is the best way to > clarify > this, taking into account what is most useful and what is practical > to > implement. I agree. > You didn't respond to my comments about the implementation implications > of your proposal. Does that mean you think there is an easier way, or > that you don't think it matters? Of course I am concerned with the practicality of the implementation, but I'm also concerned with the usability of the feature for users. Considering that _this() is primarly an ease-of-use feature, I think its use should be intuitively obvious especially for the very common case of a single servant activated once with a single POA. > I think we are agreeing that neither approach is especially intuitive. > We need to document the way it is intended to work. But first we have to > agree on what that should be. I can't comment on the way it was intended to work since I wasn't involved on the original design, and my interpretation has been characterized as a "misinterpretation". So instead, I will comment on how I think it should work. Maybe we can at least get some agreement on a few of these and see where to go from there. First, I believe there are three common cases which cover almost all use of _this(): 1. In the context of executing a request on the target servant, it should return the reference currently being incarnated. I think we can all agree on this one. 2. If a Servant has only been activated once with a single POA, it should return the reference it is incarnating. This is irrespective of the value returned by _default_POA(). 3. If a Servant has not been activated it will result in implicit activation with the Servant's default POA (assuming all of the correct policies are set on that POA). Then there are all of the corner cases: 1. A Servant which is activated multiple times with a single POA. 2. A Servant which is activated multiple times with different POAs. Now, in case 2 I can see where the default POA may indeed come in handy for selecting which POA should be used when _this() is called. Case 1 is obviously ambiguous and is defined to throw an exception in the spec today. We also need to consider how implicit activation works in this context. I will throw out another radical proposal, which really gets to the heart of the matter. There are really two types of servants used with the POA, those that have a single POA/OID for their lifetime, and those Servants which are "promiscuous" and have many POAs/OIDs over their lifetime. The problem with _this() is that we want it to behave differently for the different types, and there is no real easy way to distinguish the different types. So here are a couple of ideas: 1. A servant is considered non-promiscuous until proven otherwise. Once it has been promiscuous it is always considered promiscuous. This can be easily accomplished by recording the POA with the Servant when it is first activated. On subsequent activations, if the POA is already set, then it is cleared and marked as promiscuous. _this() will use the POA that was set upon activation, or if has been marked promiscuous it will use _default_POA(). 2. Add a new method to Servant is_promiscuous() which defaults to false, and must be overriden by user and set to true if the Servant can be activated multiple times at once. The POA would check this value during activation to verify behavior. This may require the use of counter on the Servant to keep track of how many POAs it has been activated with, as well as a pointer to the single POA it has been activated with if is_promiscuous() is false. George Date: Tue, 09 Mar 1999 11:12:07 -0500 From: Paul H Kyzivat Organization: NobleNet To: "George M. Scott" CC: java-rtf@omg.org, cxx_revision@omg.org, orb_revision@omg.org Subject: Re: Behavior of POA Servant's _this() References: <36DF52AC.E10A7CE8@inprise.com> <36DFEB00.E462DF08@noblenet.com> <36E0A484.63A295F1@inprise.com> <36E3E72E.2894B6B4@noblenet.com> <36E49BF4.1C72AC2E@inprise.com> George M. Scott wrote: > > > You didn't respond to my comments about the implementation > implications > > of your proposal. Does that mean you think there is an easier way, > or > > that you don't think it matters? > > Of course I am concerned with the practicality of the > implementation, > but I'm also concerned with the usability of the feature for users. > Considering that _this() is primarly an ease-of-use feature, I think > its use should be intuitively obvious especially for the very common > case of a single servant activated once with a single POA. If you can show a vaguely practical way to implement this behavior I might reconsider. It won't be an interesting ease-of-use feature if it has to search every POA. And I am not interested in adding expensive machinery to the management of every servant in order to speed up this one ease of use feature. If it comes to that, I would rather remove _this altogether, in favor of get_reference on POACurrent. > So instead, I will comment on how I think it should work. > Maybe we can at least get some agreement on a few of these and > see where to go from there. > > First, I believe there are three common cases which cover almost all > use of _this(): > > 1. In the context of executing a request on the target servant, it > should return the reference currently being incarnated. > I think we can all agree on this one. OK. > > 2. If a Servant has only been activated once with a single POA, it > should return the reference it is incarnating. This is > irrespective of the value returned by _default_POA(). This is part of the disagreement. Ignoring a number of consistency and efficiency issues, I agree that this would be a convenient behavior. But balancing out all the issues I don't agree. > > 3. If a Servant has not been activated it will result in implicit > activation with the Servant's default POA (assuming all of the > correct policies are set on that POA). OK. > > Then there are all of the corner cases: > > 1. A Servant which is activated multiple times with a single POA. > > 2. A Servant which is activated multiple times with different POAs. > > Now, in case 2 I can see where the default POA may indeed come in > handy for selecting which POA should be used when _this() is called. > Case 1 is obviously ambiguous and is defined to throw an exception > in the spec today. We also need to consider how implicit activation > works in this context. OK. > I will throw out another radical proposal, which really gets to the > heart of the matter. There are really two types of servants used > with the POA, those that have a single POA/OID for their lifetime, > and those Servants which are "promiscuous" and have many POAs/OIDs > over their lifetime. The problem with _this() is that we want it > to behave differently for the different types, and there is no real > easy way to distinguish the different types. So here are > a couple of ideas: > > 1. A servant is considered non-promiscuous until proven otherwise. > Once it has been promiscuous it is always considered promiscuous. > This can be easily accomplished by recording the POA with the > Servant when it is first activated. > On subsequent activations, if the POA is already set, then it is > cleared and marked as promiscuous. _this() will use the POA that > was set upon activation, or if has been marked promiscuous it > will use _default_POA(). > > 2. Add a new method to Servant is_promiscuous() which defaults to > false, and must be overriden by user and set to true if the > Servant can be activated multiple times at once. The POA would > check this value during activation to verify behavior. This > may require the use of counter on the Servant to keep track of > how many POAs it has been activated with, as well as a pointer to > the single POA it has been activated with if is_promiscuous() > is false. Your general notion of two kinds of servants is an interesting one. It would have been more interesting if it had been included in the original portability submission. But I think it is too large and incompatible a change to introduce via an RTF. Were we to consider this in some venue, then I would want to haggle over the details. But I don't think that is productive now. Don't get me wrong - I agree that there are usability problems with things as they are, around default_POA, _this, and in other areas. But they are not show stoppers and are not easily fixed with simple patches. Someday we ought to issue an RFP for improvements, but it is probably best to get more experience with what we have first. Sender: jis@fpk.hp.com Message-ID: <380E36E6.18A596@fpk.hp.com> Date: Wed, 20 Oct 1999 17:40:54 -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 2513 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &GL!!4_%!!hLk!!Y++e9 Issue 2513: Behavior of POA Servant's _this() (orb_revision) Click here for this issue's archive. Source: Inprise Corporation (Mr. George M. Scot, gscott@inprise.com gscott@visigenic.com) Nature: Uncategorized Issue Severity: Summary: The text describing the use of _this() in the Java and C++ mapping chapters is somewhat confusing and needs to be clarified. Resolution: Revised Text: Actions taken: March 5, 1999: received issue Discussion: ________________________________________________________________ After reading through the extensive discussion of this issue from the email archive, since the archive for this issue seems to be messed up in the issues list, I arrived at the conclusion that this issue should be closed No Change. Jeff M FYI George Scott was the only one who wanted this apparently hugely non-backward compatible change which appeared to have no hope of passing. So with some trepidation I am going to propose a No Change resolution for this one in the upcoming vote. 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: <380E4A0C.1CDE0C74@floorboard.com> Date: Wed, 20 Oct 1999 16:02:36 -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 2513 References: <380E36E6.18A596@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [O_d9*@\d9ZfD!!M='!! Jishnu Mukerji wrote: > > Issue 2513: Behavior of POA Servant's _this() (orb_revision) > > Click here for this issue's archive. > Source: Inprise Corporation (Mr. George M. Scot, gscott@inprise.com > gscott@visigenic.com) > Nature: Uncategorized Issue > Severity: > Summary: The text describing the use of _this() in the Java and C++ > mapping > chapters is somewhat confusing and needs to be clarified. > Resolution: > Revised Text: > Actions taken: > March 5, 1999: received issue > > Discussion: > > ________________________________________________________________ > > After reading through the extensive discussion of this issue from > the email > archive, since the archive for this issue seems to be messed up in > the issues > list, I arrived at the conclusion that this issue should be closed > No Change. > Jeff M FYI George Scott was the only one who wanted this apparently > hugely > non-backward compatible change which appeared to have no hope of > passing. So > with some trepidation I am going to propose a No Change resolution > for this one > in the upcoming vote. > > Comments? I support closing with no change. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org