Issue 2357: Misleading text for DSI invoke() and _primary_interface() (cxx_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Section 20.38.3 of the CORBA 2.3 draft states: I believe that the intent of this paragraph is to forbid the user from calling invoke() and _primary_interface() directly, not to forbid the POA from calling _primary_interface() in circumstances other than processing a request. The paragraph should be reworded to say: "The invoke() and _primary_interface() methods will be called by the POA, and should never be explicitly called by the application." Resolution: Close no change. This issue is already addressed in the CORBA 2.3 specification. Revised Text: Actions taken: January 29, 1999: received issue June 13, 2000: closed issue Discussion: End of Annotations:===== Sender: jon@floorboard.com Date: Fri, 29 Jan 1999 10:43:13 -0800 From: Jonathan Biggar X-Accept-Language: en To: issues@omg.org, cxx_revision@omg.org Subject: Misleading text for DSI invoke() and _primary_interface() Section 20.38.3 of the CORBA 2.3 draft states: "It is expected that the invoke() and _primary_interface() methods will be only invoked by the POA in the context of serving a CORBA request. Invoking this method in other circumstances may lead to unpredictable results." I believe that the intent of this paragraph is to forbid the user from calling invoke() and _primary_interface() directly, not to forbid the POA from calling _primary_interface() in circumstances other than processing a request. The paragraph should be reworded to say: "The invoke() and _primary_interface() methods will be called by the POA, and should never be explicitly called by the application." -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 29 Jan 1999 14:51:37 -0500 From: Paul H Kyzivat Organization: NobleNet To: Jonathan Biggar CC: issues@omg.org, cxx_revision@omg.org Subject: Re: Misleading text for DSI invoke() and _primary_interface() References: <36B20141.15BF973@floorboard.com> Jonathan Biggar wrote: > > Section 20.38.3 of the CORBA 2.3 draft states: > > "It is expected that the invoke() and _primary_interface() methods > will > be only invoked by the POA in the context of serving a CORBA > request. > Invoking this method in other circumstances may lead to > unpredictable > results." > > I believe that the intent of this paragraph is to forbid the user > from > calling invoke() and _primary_interface() directly, not to forbid > the > POA from calling _primary_interface() in circumstances other than > processing a request. > > The paragraph should be reworded to say: > > "The invoke() and _primary_interface() methods will be called by the > POA, and should never be explicitly called by the application." I think your new wording is an improvement because it relaxes restrictions that don't seem well motivated. But I wonder why anything needs to be said at all. While I doubt that other reasons to call these functions will be common, why should they be forbidden? Assuming the caller makes the calls with the correct arguments, the results should be well defined. For example, someone might want to write a shim DSI servant that sits between the POA and a real servant, logging or filtering requests and then delegating the calls on. Is there any reason why this should not be expected to work portably? Sender: jon@floorboard.com Date: Fri, 29 Jan 1999 12:12:45 -0800 From: Jonathan Biggar X-Accept-Language: en To: Paul H Kyzivat CC: issues@omg.org, cxx_revision@omg.org Subject: Re: Misleading text for DSI invoke() and _primary_interface() References: <36B20141.15BF973@floorboard.com> <36B21149.A5F0CB4F@noblenet.com> Paul H Kyzivat wrote: > I think your new wording is an improvement because it relaxes > restrictions that don't seem well motivated. > > But I wonder why anything needs to be said at all. While I doubt > that > other reasons to call these functions will be common, why should > they be > forbidden? Assuming the caller makes the calls with the correct > arguments, the results should be well defined. > > For example, someone might want to write a shim DSI servant that > sits > between the POA and a real servant, logging or filtering requests > and > then delegating the calls on. Is there any reason why this should > not be > expected to work portably? The problem with a "shim" DSI servant is that it can't be written portably. An ORB may (and probably will) define additional interfaces that are used internally by the ORB's POA implementation to operate correctly. For example, a POA may very well need to determine if a servant is a static or dynamic servant. There is no portable interface to make that determination, so the ORB implementor might add an additional method to the base servant class. A portable "shim" DSI servant can't know what additional stuff it might need to pass through to the real servant. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 29 Jan 1999 17:29:07 -0500 From: Paul H Kyzivat Organization: NobleNet To: Jonathan Biggar CC: issues@omg.org, cxx_revision@omg.org Subject: Re: Misleading text for DSI invoke() and _primary_interface() References: <36B20141.15BF973@floorboard.com> <36B21149.A5F0CB4F@noblenet.com> <36B2163D.6EA47D35@floorboard.com> Jonathan Biggar wrote: > > The problem with a "shim" DSI servant is that it can't be written > portably. An ORB may (and probably will) define additional > interfaces > that are used internally by the ORB's POA implementation to operate > correctly. For example, a POA may very well need to determine if a > servant is a static or dynamic servant. There is no portable > interface > to make that determination, so the ORB implementor might add an > additional method to the base servant class. > > A portable "shim" DSI servant can't know what additional stuff it > might > need to pass through to the real servant. I must be missing something... If I, as a server developer, want to use a DSI servant, then I derive my class from PortableServer::DynamicImplementation class MyDSI : public PortableServer::DynamicImplementation {...} my_poa->set_servant(new MyDSI); Now, if I wanted to use the short of shim I was talking about, I should be able to do the following: class MyDSI : public PortableServer::DynamicImplementation {...} class MyShim : public PortableServer::DynamicImplementation {...} my_poa->set_servant(new MyShim(new MyDSI)); Both MyDSI and MyShim should then have everything they need, using portable code. But this isn't an important issue that is worth further discussion. If people think the restrictive wording is needed then I am happy to go with the proposed text. Paul Sender: jon@floorboard.com Date: Fri, 29 Jan 1999 15:52:29 -0800 From: Jonathan Biggar X-Accept-Language: en To: Paul H Kyzivat CC: issues@omg.org, cxx_revision@omg.org Subject: Re: Misleading text for DSI invoke() and _primary_interface() References: <36B20141.15BF973@floorboard.com> <36B21149.A5F0CB4F@noblenet.com> <36B2163D.6EA47D35@floorboard.com> <36B23633.2FB98B27@noblenet.com> Paul H Kyzivat wrote: > I must be missing something... > > If I, as a server developer, want to use a DSI servant, then I > derive my > class from PortableServer::DynamicImplementation > > class MyDSI : public PortableServer::DynamicImplementation > {...} > > my_poa->set_servant(new MyDSI); > > Now, if I wanted to use the short of shim I was talking about, > I should be able to do the following: > > class MyDSI : public PortableServer::DynamicImplementation > {...} > > class MyShim : public PortableServer::DynamicImplementation > {...} > > my_poa->set_servant(new MyShim(new MyDSI)); > > Both MyDSI and MyShim should then have everything they need, > using portable code. Not necessarily. As I said before, there may be implementation dependent interfaces in the servant class that have been added by the ORB implementor to make his ORB function correctly. If the call to those interfaces doesn't pass through from MyShim to MyDSI, then the ORB may malfunction. In fact, now that I think of it, your code almost certainly won't work properly anyway, since _this(), when called in your MyDSI class, can't properly return the correct result, since it is being called on a servant that isn't registered with the POA. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org