Issue 3055: _default_POA (cxx_revision) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: what should _default_POA() return if no default ORB exists in the server (that is, ORB_init() with an empty ORB ID was never called)? Resolution: Revised Text: Actions taken: November 23, 1999: received issue Discussion: deferred in June 2011 to the next RTF End of Annotations:===== Date: Tue, 23 Nov 1999 06:56:43 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com Reply-To: C++ Revision Task Force To: C++ Revision Task Force cc: issues@omg.org Subject: _default_POA Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: p~>!!kO*!!j4Qd9^c8!! Hi, what should _default_POA() return if no default ORB exists in the server (that is, ORB_init() with an empty ORB ID was never called)? Cheers, Michi. -- Michi Henning +61 7 3236 1633 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: "'C++ Revision Task Force'" Cc: issues@omg.org Subject: RE: _default_POA Date: Mon, 22 Nov 1999 19:40:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: OER!!#?2!!HVg!!J,m!! > From: Michi Henning [mailto:michi@ooc.com.au] ... > what should _default_POA() return if no default ORB exists in > the server (that is, ORB_init() with an empty ORB ID was never called)? We throw BAD_INV_ORDER. Date: Sun, 28 Nov 1999 08:51:35 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: Paul Kyzivat cc: "'C++ Revision Task Force'" Subject: RE: _default_POA In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA91401E3@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 3IW!!GN9e9jc4!!2]f!! On Mon, 22 Nov 1999, Paul Kyzivat wrote: > > From: Michi Henning [mailto:michi@ooc.com.au] > ... > > what should _default_POA() return if no default ORB exists in > > the server (that is, ORB_init() with an empty ORB ID was never > called)? > > We throw BAD_INV_ORDER. Interesting. We create a new ORB on the fly... Either behavior is sensible, given that the spec doesn't say anything about it. But the difference in our respective implementations indicates that there is certainly a hole in the spec that needs to be plugged... One thing that has concerned me for a long time: _default_POA almost certainly returns the wrong thing for any servant that doesn't belong to the Root POA. To be safe, I *must* override _default_POA in the skeleton, otherwise, calls to _this() return the wrong reference. I have a feeling that we should change the mapping to remove this silent (and dangerous) misbehavior. One option I can see is to leave _default_POA as non-pure, but to have the default implemention throw an exception. That way, I'd at least be alerted to the fact that something wrong is likely to be happening. Opinions? Cheers, Michi. From: Paul Kyzivat To: "'Michi Henning'" , Paul Kyzivat Cc: "'C++ Revision Task Force'" Subject: RE: _default_POA Date: Mon, 29 Nov 1999 11:13:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: V$8!!"3n!!7nFe9=#9e9 > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Saturday, November 27, 1999 5:52 PM > To: Paul Kyzivat > Cc: 'C++ Revision Task Force' > Subject: RE: _default_POA > > > On Mon, 22 Nov 1999, Paul Kyzivat wrote: > > > > From: Michi Henning [mailto:michi@ooc.com.au] > > ... > > > what should _default_POA() return if no default ORB exists in > > > the server (that is, ORB_init() with an empty ORB ID was > never called)? > > > > We throw BAD_INV_ORDER. > > Interesting. We create a new ORB on the fly... Either > behavior is sensible, > given that the spec doesn't say anything about it. But the > difference > in our respective implementations indicates that there is certainly > a hole in the spec that needs to be plugged... Yes, I agree, as long as it doesn't mean we have to change our implementation to match yours. > > One thing that has concerned me for a long time: _default_POA almost > certainly returns the wrong thing for any servant that doesn't > belong > to the Root POA. To be safe, I *must* override _default_POA > in the skeleton, > otherwise, calls to _this() return the wrong reference. I also don't like the way this "feature" was defined. In my experience it is most often the case that you want all instances of a given implementation to map to a particular POA. We provide an extension that permits the server developer to set a default at that granularity. > > I have a feeling that we should change the mapping to remove > this silent > (and dangerous) misbehavior. One option I can see is to leave > _default_POA > as non-pure, but to have the default implemention throw an > exception. > That way, I'd at least be alerted to the fact that something wrong > is > likely to be happening. Opinions? I hesitate to retroactively change this. I am quite sure that we have applications and tests that would break with this change. We typically only use the root POA for things like servant managers. For them it is often convenient to use _this to get them activated. Date: Wed, 5 Jan 2000 09:59:25 +1000 (EST) From: Michi Henning To: C++ Revision Task Force Subject: Proposal for 3055 Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: [l)!!C!Ne9Y0nd9487e9 On page 1-129, second para, insert the following text just before the last sentence (beginning with "Classes derived from ServantBase can override...": If no default ORB exists in a process (that is, no call to ORB_init() with an empty ORB ID was made previously), _default_POA() throws a BAD_INV_ORDER exception. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@corvette.floorboard.com Message-ID: <38729FBE.F9107D73@floorboard.com> Date: Tue, 04 Jan 2000 17:34:54 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: C++ Revision Task Force Subject: Re: Proposal for 3055 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: OS[!!QWT!!?Kmd9Jg`!! Michi Henning wrote: > > On page 1-129, second para, insert the following text just before > the last > sentence (beginning with "Classes derived from ServantBase can > override...": > > If no default ORB exists in a process (that is, no call to > ORB_init() > with an empty ORB ID was made previously), _default_POA() > throws > a BAD_INV_ORDER exception. I'm concerned about this proposal. I don't recall anywhere that equates the "default" ORB with the one whose ORBid is the empty string. Won't this cause clients to break if the -ORBid parameter appears in argv because then there won't be a default ORB by this definition? I think we really need to state instead that the default ORB is the first one created in the process. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jbiggar@corvette.floorboard.com Message-ID: <3872A664.BF256C37@floorboard.com> Date: Tue, 04 Jan 2000 18:03:16 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: C++ Revision Task Force Subject: Re: Proposal for 3055 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ;Lgd9!DEe9]o0e9YXZ!! Michi Henning wrote: > > I think we really need to state instead that the default ORB is the > > first one created in the process. > > We could do this. But then we have to assign the issue to the core RTF > because the core spec says (on page 4-17): > > If an empty string is passed and no arg_list parameters indicate > the ORB reference to be returned, the default ORB for the > environment will be returned. > > The proposal I made was simply to deal with the question of "what if there > is no default ORB". What you are proposing is "let's make sure that there > always is a default ORB", so that's a core issue. I believe that there is should be a difference between the "default ORB for the environment", which is the one that is administratively configured to be returned when no non-empty ORBid is provided and the "default ORB for the process" which is what _default_POA() returns. Given that, I don't think there is a core issue at all, since _default_POA() is C++ specific. > Personally, I'm not hung up about this. However, I'm not sure what > the ramifications of your proposal would be. Any subtle changes in > semantics anywhere? For applications that use more than one ORB, > I would expect that something will break... Making it the first ORB constructed in the process is the only way I see to give _default_POA() consistent semantics that can be relied on. For clients that initialize only one ORB, (and usually the empty ORBid one at that), there should be no perceived change in semantics. For current clients that initialize more than one ORB right now, they already must explicitly override _default_POA() for all of their servants in order to not have undefined behavior, so there should be no perceived change in semantics there either. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 5 Jan 2000 11:45:50 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: C++ Revision Task Force Subject: Re: Proposal for 3055 In-Reply-To: <38729FBE.F9107D73@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: gj7!!+24e9o%Be9=-Ge9 On Tue, 4 Jan 2000, Jonathan Biggar wrote: > Michi Henning wrote: > > > > On page 1-129, second para, insert the following text just before > the last > > sentence (beginning with "Classes derived from ServantBase can > override...": > > > > If no default ORB exists in a process (that is, no call to > ORB_init() > > with an empty ORB ID was made previously), _default_POA() > throws > > a BAD_INV_ORDER exception. > > I'm concerned about this proposal. I don't recall anywhere that > equates > the "default" ORB with the one whose ORBid is the empty string. > Won't > this cause clients to break if the -ORBid parameter appears in argv > because then there won't be a default ORB by this definition? > > I think we really need to state instead that the default ORB is the > first one created in the process. We could do this. But then we have to assign the issue to the core RTF because the core spec says (on page 4-17): If an empty string is passed and no arg_list parameters indicate the ORB reference to be returned, the default ORB for the environment will be returned. The proposal I made was simply to deal with the question of "what if there is no default ORB". What you are proposing is "let's make sure that there always is a default ORB", so that's a core issue. Personally, I'm not hung up about this. However, I'm not sure what the ramifications of your proposal would be. Any subtle changes in semantics anywhere? For applications that use more than one ORB, I would expect that something will break... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 5 Jan 2000 12:33:26 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: C++ Revision Task Force Subject: Re: Proposal for 3055 In-Reply-To: <3872A664.BF256C37@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 6=Rd9fZEe9e)~e9T8P!! On Tue, 4 Jan 2000, Jonathan Biggar wrote: > I believe that there is should be a difference between the "default ORB > for the environment", which is the one that is administratively > configured to be returned when no non-empty ORBid is provided and the > "default ORB for the process" which is what _default_POA() returns. > Given that, I don't think there is a core issue at all, since > _default_POA() is C++ specific. OK, I can buy that argument. However, in that case, I think we must state explicitly in the C++ mapping that the "default ORB for the process" is *not* the same as the "default ORB" mentioned in the core. In addition, we would have to state that the "default ORB for the process" is, by definition, the first initialized ORB. I'm concerned about terminology confusion though... > > Personally, I'm not hung up about this. However, I'm not sure what > > the ramifications of your proposal would be. Any subtle changes in > > semantics anywhere? For applications that use more than one ORB, > > I would expect that something will break... > > Making it the first ORB constructed in the process is the only way I > see > to give _default_POA() consistent semantics that can be relied on. > For > clients that initialize only one ORB, (and usually the empty ORBid > one > at that), there should be no perceived change in semantics. For > current > clients that initialize more than one ORB right now, they already > must > explicitly override _default_POA() for all of their servants in > order to > not have undefined behavior, so there should be no perceived change > in > semantics there either. I like this, and I agree with your reasoning. My only concern is the terminology confusion. Can we remove all references to the "default ORB for the process" and call it the "first ORB" then? What if several threads call ORB_init() concurrently? Which ORB is the "first" ORB then? cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@corvette.floorboard.com Message-ID: <3872C14A.7C3652B@floorboard.com> Date: Tue, 04 Jan 2000 19:58:02 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: C++ Revision Task Force Subject: Re: Proposal for 3055 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: @@R!!gY/!!c88e9LkPe9 Michi Henning wrote: > > On Tue, 4 Jan 2000, Jonathan Biggar wrote: > > > I believe that there is should be a difference between the > "default ORB > > for the environment", which is the one that is administratively > > configured to be returned when no non-empty ORBid is provided and > the > > "default ORB for the process" which is what _default_POA() > returns. > > Given that, I don't think there is a core issue at all, since > > _default_POA() is C++ specific. > > OK, I can buy that argument. However, in that case, I think we must > state explicitly in the C++ mapping that the "default ORB for the > process" > is *not* the same as the "default ORB" mentioned in the core. In > addition, > we would have to state that the "default ORB for the process" is, by > definition, the first initialized ORB. > > I'm concerned about terminology confusion though... Fine, we can just refer to the "first" ORB, rather than the "default" one. > > > Personally, I'm not hung up about this. However, I'm not sure what > > > the ramifications of your proposal would be. Any subtle changes in > > > semantics anywhere? For applications that use more than one ORB, > > > I would expect that something will break... > > > > Making it the first ORB constructed in the process is the only way I see > > to give _default_POA() consistent semantics that can be relied on. For > > clients that initialize only one ORB, (and usually the empty ORBid one > > at that), there should be no perceived change in semantics. For current > > clients that initialize more than one ORB right now, they already must > > explicitly override _default_POA() for all of their servants in order to > > not have undefined behavior, so there should be no perceived change in > > semantics there either. > > I like this, and I agree with your reasoning. My only concern is the > terminology confusion. Can we remove all references to the "default ORB > for the process" and call it the "first ORB" then? What if several threads > call ORB_init() concurrently? Which ORB is the "first" ORB then? Doesn't the ORB implementation already need to serialize ORB creation to handle the case where more than one thread calls ORB_init with the same ORBid? If so, it is just whichever one gets there first. If the application really cares about the order, it can serialize the calls itself. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Authentication-Warning: duzanmac.gte.com: gdd0 owned process doing -bs To: Michi Henning Cc: Jonathan Biggar , C++ Revision Task Force Subject: Re: Proposal for 3055 MIME-Version: 1.0 Content-ID: <2122.947084604.1@gte.com> Date: Wed, 05 Jan 2000 10:03:24 -0500 From: "Gary D. Duzan" Content-Type: text/plain; charset="us-ascii" X-UIDL: P&Q!!h , Michi Henning wrote: =>On Tue, 4 Jan 2000, Jonathan Biggar wrote: => =>> I believe that there is should be a difference between the "default ORB =>> for the environment", which is the one that is administratively =>> configured to be returned when no non-empty ORBid is provided and the =>> "default ORB for the process" which is what _default_POA() returns. =>> Given that, I don't think there is a core issue at all, since =>> _default_POA() is C++ specific. => =>OK, I can buy that argument. However, in that case, I think we must =>state explicitly in the C++ mapping that the "default ORB for the process" =>is *not* the same as the "default ORB" mentioned in the core. In addition, =>we would have to state that the "default ORB for the process" is, by =>definition, the first initialized ORB. => =>I'm concerned about terminology confusion though... => =>> > Personally, I'm not hung up about this. However, I'm not sure what =>> > the ramifications of your proposal would be. Any subtle changes in =>> > semantics anywhere? For applications that use more than one ORB, =>> > I would expect that something will break... =>> =>> Making it the first ORB constructed in the process is the only way I see =>> to give _default_POA() consistent semantics that can be relied on. For =>> clients that initialize only one ORB, (and usually the empty ORBid one =>> at that), there should be no perceived change in semantics. For current =>> clients that initialize more than one ORB right now, they already must =>> explicitly override _default_POA() for all of their servants in order to =>> not have undefined behavior, so there should be no perceived change in =>> semantics there either. => =>I like this, and I agree with your reasoning. My only concern is the =>terminology confusion. Can we remove all references to the "default ORB =>for the process" and call it the "first ORB" then? What if several threads =>call ORB_init() concurrently? Which ORB is the "first" ORB then? => => cheers, => => Michi. =>-- =>Michi Henning +61 7 3891 5744 =>Object Oriented Concepts +61 4 1118 2700 (mobile) =>Suite 4, 904 Stanley St +61 7 3891 5009 (fax) =>East Brisbane 4169 michi@ooc.com.au =>AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html => From: Paul Kyzivat To: "'Michi Henning'" , C++ Revision Task Force Subject: RE: Proposal for 3055 Date: Wed, 5 Jan 2000 09:22:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: E"l!!M`Ne9G\J!!LAEe9 I think this needs some discussion. As far as I know, there is no formal definition of "default ORB". The definition implicitly proposed here is one possibility among many. What about the simplest case - where ORB_init has been called exactly once? Shouldn't the result of this be the "default ORB" regardless of what ORB ID was specified? Also, in general, in any particular environment, I would expect that the empty ORB ID is equivalent to some non-empty ORB ID. In that environment I would expect the use of the empty id or the equivalent non-empty id to be synonomous. So, if the the "default ORB" is to be defined by some particular ORB ID rather than by some dynamic algorithm, then I would think it would be defined this way. Paul > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Tuesday, January 04, 2000 6:59 PM > To: C++ Revision Task Force > Subject: Proposal for 3055 > > > > On page 1-129, second para, insert the following text just > before the last > sentence (beginning with "Classes derived from ServantBase > can override...": > > If no default ORB exists in a process (that is, no call > to ORB_init() > with an empty ORB ID was made previously), _default_POA() > throws > a BAD_INV_ORDER exception. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-> henning.html > From: Paul Kyzivat To: "'Michi Henning'" , Jonathan Biggar Cc: C++ Revision Task Force Subject: RE: Proposal for 3055 Date: Wed, 5 Jan 2000 10:01:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: [dTd9gC6!!!~De9NMhd9 > I like this, and I agree with your reasoning. My only concern is the > terminology confusion. Can we remove all references to the > "default ORB > for the process" and call it the "first ORB" then? What if > several threads > call ORB_init() concurrently? Which ORB is the "first" ORB then? I am not convinced that "first orb" is quite right either. Suppose I do: ORB_init ... orb->shutdown(true); orb->destroy(); ORB_init ... In this "second generation" orb there is still clearly an orb that can be meaningfully considered a default. Date: Wed, 5 Jan 2000 13:10:20 -0330 From: Matthew Newhook To: Paul Kyzivat Cc: "'Michi Henning'" , Jonathan Biggar , C++ Revision Task Force Subject: Re: Proposal for 3055 Message-ID: <20000105131020.A21206@ooc.com> References: <9B164B713EE9D211B6DC0090273CEEA91402A3@bos1.noblenet.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA91402A3@bos1.noblenet.com> Content-Type: text/plain; charset=us-ascii X-UIDL: `-"e9HAid9%+8!!~4o!! Hi, On Wed, Jan 05, 2000 at 10:01:12AM -0500, Paul Kyzivat wrote: > > > I like this, and I agree with your reasoning. My only concern is > the > > terminology confusion. Can we remove all references to the > > "default ORB > > for the process" and call it the "first ORB" then? What if > > several threads > > call ORB_init() concurrently? Which ORB is the "first" ORB then? > > I am not convinced that "first orb" is quite right either. > > Suppose I do: > > ORB_init > ... > orb->shutdown(true); > orb->destroy(); > > ORB_init > ... > > In this "second generation" orb there is still clearly an orb that > can be > meaningfully considered a default. I dunno. To me it was always pretty clear that the default ORB was the ORB with the id "" (the empty string). That was basically derived from the wording in the core that Michi quoted earlier. I don't see a compelling reason to change that. Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: Paul Kyzivat To: "'Matthew Newhook'" , Paul Kyzivat Cc: "'Michi Henning'" , Jonathan Biggar , C++ Revision Task Force Subject: RE: Proposal for 3055 Date: Wed, 5 Jan 2000 12:28:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: \V1e9J2o!!j/7!!CLU!! May be clear to you, but apparently not to everybody. Jon sent comments similar to mine about default orb. Also, in my example, the two calls to ORB_init presumably return different orb instances. If _default_POA is called after the second ORB_init call, does it return the root POA from the second orb, or does it fail while trying to get the root POA from the first orb? Paul > -----Original Message----- > From: Matthew Newhook [mailto:matthew@ooc.com] > Sent: Wednesday, January 05, 2000 11:40 AM > To: Paul Kyzivat > Cc: 'Michi Henning'; Jonathan Biggar; C++ Revision Task Force > Subject: Re: Proposal for 3055 > > > Hi, > > On Wed, Jan 05, 2000 at 10:01:12AM -0500, Paul Kyzivat wrote: > > > > > I like this, and I agree with your reasoning. My only > concern is the > > > terminology confusion. Can we remove all references to the > > > "default ORB > > > for the process" and call it the "first ORB" then? What if > > > several threads > > > call ORB_init() concurrently? Which ORB is the "first" ORB then? > > > > I am not convinced that "first orb" is quite right either. > > > > Suppose I do: > > > > ORB_init > > ... > > orb->shutdown(true); > > orb->destroy(); > > > > ORB_init > > ... > > > > In this "second generation" orb there is still clearly an > orb that can be > > meaningfully considered a default. > > I dunno. To me it was always pretty clear that the default ORB was > the ORB with the id "" (the empty string). That was basically > derived > from the wording in the core that Michi quoted earlier. I don't see > a > compelling reason to change that. > > Regards, Matthew > -- > Matthew Newhook E-Mail: > mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 > Date: Wed, 5 Jan 2000 13:59:50 -0330 From: Matthew Newhook To: Paul Kyzivat Cc: "'Michi Henning'" , Jonathan Biggar > , C++ Revision Task Force Subject: Re: Proposal for 3055 Message-ID: <20000105135950.A21429@ooc.com> References: <9B164B713EE9D211B6DC0090273CEEA91402A9@bos1.noblenet.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA91402A9@bos1.noblenet.com> Content-Type: text/plain; charset=us-ascii X-UIDL: n>K!!8'$!!'87!!3+Qe9 Hi, On Wed, Jan 05, 2000 at 12:28:34PM -0500, Paul Kyzivat wrote: > May be clear to you, but apparently not to everybody. My interpretation was gained from reading the core specification (specifically the section that Michi quoted). > Jon sent comments similar to mine about default orb. > > Also, in my example, the two calls to ORB_init presumably return > different > orb instances. If _default_POA is called after the second ORB_init > call, > does it return the root POA from the second orb, or does it fail > while > trying to get the root POA from the first orb? If you follow the core then _default_POA() doesn't exist unless the default ORB (that is the ORB with the empty string id) is not yet initialized. Therefore, I believe that the appropriate exception is BAD_INV_ORDER Anyway, as far as I can see in an environment with multiple ORBs _default_POA() doesn't really mean anything. I would bet that in 99.9% of the cases that this is an error. > Paul Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 05 Jan 2000 13:30:43 -0500 To: Paul Kyzivat From: Steve Vinoski Subject: RE: Proposal for 3055 Cc: C++ Revision Task Force In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA91402A3@bos1.noblenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: 1- >> I like this, and I agree with your reasoning. My only concern is the >> terminology confusion. Can we remove all references to the >> "default ORB >> for the process" and call it the "first ORB" then? What if >> several threads >> call ORB_init() concurrently? Which ORB is the "first" ORB then? > >I am not convinced that "first orb" is quite right either. > >Suppose I do: > > ORB_init > ... > orb->shutdown(true); > orb->destroy(); > > ORB_init > ... > >In this "second generation" orb there is still clearly an orb that can be >meaningfully considered a default. From: Paul Kyzivat To: "'Steve Vinoski'" , Paul Kyzivat Cc: C++ Revision Task Force Subject: RE: Proposal for 3055 Date: Wed, 5 Jan 2000 14:26:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: iD6e9?>C!!LXG!!_*A!! Steve, That clarification is helpful. For one thing, I think it clears up the question about "" vs the orb id that happens to be equivalent to the default. However, in conjunction with the discussion that has occurred on this I think there are still some unclear points. Specifying that _default_POA would do something similar to ORB_init(?,?,"") makes a lot of sense, if an identical call has already been made. But if there is no orb already initialized, it seems like a bad idea to have _default_POA cause one to be initialized, which is what this would do. Another problem is that ORB_init takes argc/argv as arguments. The implementation of _default_POA doesn't have access to those, so it can't pass them in a call to ORB_init. Without those, it can't guarantee that it will get the same orb that a call to ORB_init(argc,argv,"") would have returned in the main thread. So, if this technique is used, the default implementation of _default_POA can never be depended upon to do anything useful - it will do the wrong thing whenever "-ORBid XXX" is present in argv. A developer can never depend on this implementation unless he can ensure argv is never used to override the ORBid. Paul > -----Original Message----- > From: Steve Vinoski [mailto:vinoski@iona.com] > Sent: Wednesday, January 05, 2000 1:31 PM > To: Paul Kyzivat > Cc: C++ Revision Task Force > Subject: RE: Proposal for 3055 > > > Being the originator of _default_POA (and, actually, default > ORBs, for that > matter), I can say with certainty that the original intent > was that the > default implementation of the function would invoke ORB_init > with "" as its > third argument. Anyone requiring it to use something else > would need to > override it. I don't see why it needs to be more complicated > than that, so > I think Michi's proposal is spot on. > > --steve X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 05 Jan 2000 15:39:32 -0500 To: Paul Kyzivat From: Steve Vinoski Subject: RE: Proposal for 3055 Cc: C++ Revision Task Force In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA91402AE@bos1.noblenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: 8fTd9@/Vd9b_3!!3=:!! At 02:26 PM 1/5/00 -0500, Paul Kyzivat wrote: >Steve, > >That clarification is helpful. For one thing, I think it clears up the >question about "" vs the orb id that happens to be equivalent to the >default. > >However, in conjunction with the discussion that has occurred on this I >think there are still some unclear points. > >Specifying that _default_POA would do something similar to >ORB_init(?,?,"") makes a lot of sense, if an identical call has already been >made. But if there is no orb already initialized, it seems like a bad idea >to have _default_POA cause one to be initialized, which is what this would >do. No, Michi's proposal is to raise BAD_INV_ORDER in that case. Your implementation of _default_POA() would need to detect that the equivalent of the following code had not yet been invoked by the application, and raise the exception: int argc = 0; ... = ORB_init(argc, 0, ""); >Another problem is that ORB_init takes argc/argv as arguments. The >implementation of _default_POA doesn't have access to those, so it can't >pass them in a call to ORB_init. Without those, it can't guarantee that it >will get the same orb that a call to ORB_init(argc,argv,"") would have >returned in the main thread. So, if this technique is used, the default >implementation of _default_POA can never be depended upon to do anything >useful - it will do the wrong thing whenever "-ORBid XXX" is present in >argv. A developer can never depend on this implementation unless he can >ensure argv is never used to override the ORBid. True, but passing a "-ORBid XXX" argument to ORB_init is in essence identical to passing "XXX" as the third argument, which means you're not getting the default ORB from that call. Or at least that's one possible interpretation. :-( As I related Matthew Newhook in private email, unfortunately this whole area of ORB initialization, shutdown, and destroy is really messed up. A number of different groups of people have worked on it over the past five or so years, and each group appears to have imparted slightly different semantics on the whole mess with each change. I have my own opinions about this, but frankly, I'm not sure we can really fix _default_POA() correctly until we get the whole lot fixed. Maybe we should just defer this issue. --steve Sender: jbiggar@corvette.floorboard.com Message-ID: <3873AA5A.E1CD8CA5@floorboard.com> Date: Wed, 05 Jan 2000 12:32:26 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: "'Steve Vinoski'" , C++ Revision Task Force Subject: Re: Proposal for 3055 References: <9B164B713EE9D211B6DC0090273CEEA91402AE@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: /O]!!Y=b!!MlA!!@Q9!! Paul Kyzivat wrote: > However, in conjunction with the discussion that has occurred on > this I > think there are still some unclear points. > > Specifying that _default_POA would do something similar to > ORB_init(?,?,"") makes a lot of sense, if an identical call has > already been > made. But if there is no orb already initialized, it seems like a > bad idea > to have _default_POA cause one to be initialized, which is what this > would > do. > > Another problem is that ORB_init takes argc/argv as arguments. The > implementation of _default_POA doesn't have access to those, so it > can't > pass them in a call to ORB_init. Without those, it can't guarantee > that it > will get the same orb that a call to ORB_init(argc,argv,"") would > have > returned in the main thread. So, if this technique is used, the > default > implementation of _default_POA can never be depended upon to do > anything > useful - it will do the wrong thing whenever "-ORBid XXX" is present > in > argv. A developer can never depend on this implementation unless he > can > ensure argv is never used to override the ORBid. These points are precisely why I objected to Michi's first proposal. I only see two workable alternatives: 1. Just deprecate _default_POA() having a default implementation and make it pure virtual. 2. Define it to return the "first" ORB created in the process, with two definitions of "first" possible: a. The result of the literal first call to ORB_init, so if that ORB is destroyed, then the default _default_POA() implementation breaks thereafter with an exception. b. The result of the first call to ORB_init after any given point in time where there are exactly zero active ORBs in the process. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 6 Jan 2000 07:48:50 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Paul Kyzivat , "'Steve Vinoski'" , C++ Revision Task Force Subject: Re: Proposal for 3055 In-Reply-To: <3873AA5A.E1CD8CA5@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 1~cd9piD!!Zpp!!cGf!! On Wed, 5 Jan 2000, Jonathan Biggar wrote: > These points are precisely why I objected to Michi's first proposal. I > only see two workable alternatives: > > 1. Just deprecate _default_POA() having a default implementation and > make it pure virtual. Doing that would break an awful lot of code that currently works just fine. I don't think we can do that. > 2. Define it to return the "first" ORB created in the process, with two > definitions of "first" possible: > a. The result of the literal first call to ORB_init, so if that ORB > is destroyed, then the default _default_POA() implementation breaks > thereafter with an exception. I think this option is the best one because it yields the fewest surprises. > b. The result of the first call to ORB_init after any given point in > time where there are exactly zero active ORBs in the process. I don't like this one much. It seems too complex. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: "'Steve Vinoski'" , Paul Kyzivat Cc: C++ Revision Task Force Subject: RE: Proposal for 3055 Date: Wed, 5 Jan 2000 16:44:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: W8Q!!>*&e9^)'!![j*e9 > From: Steve Vinoski [mailto:vinoski@iona.com] > >Specifying that _default_POA would do something similar to > >ORB_init(?,?,"") makes a lot of sense, if an identical call > has already been > >made. But if there is no orb already initialized, it seems > like a bad idea > >to have _default_POA cause one to be initialized, which is > what this would > >do. > > No, Michi's proposal is to raise BAD_INV_ORDER in that case. Your > implementation of _default_POA() would need to detect that > the equivalent > of the following code had not yet been invoked by the application, > and > raise the exception: > > int argc = 0; > ... = ORB_init(argc, 0, ""); My point here was that _default_POA can't merely make the call you show above to get its orb. It must have some special friend relationship with ORB_init to know what has already been done. Rather than using ORB_init both as a way to create an orb and as a way to access an already initialized orb, it would be nice to separate out those functions. This in useful not only in _default_POA, but in many places. In theory it is cleaner to pass the orb around to whoever needs it, but in practice this gets cumbersome. > > >Another problem is that ORB_init takes argc/argv as arguments. The > >implementation of _default_POA doesn't have access to those, > so it can't > >pass them in a call to ORB_init. Without those, it can't > guarantee that it > >will get the same orb that a call to ORB_init(argc,argv,"") > would have > >returned in the main thread. So, if this technique is used, > the default > >implementation of _default_POA can never be depended upon to > do anything > >useful - it will do the wrong thing whenever "-ORBid XXX" is > present in > >argv. A developer can never depend on this implementation > unless he can > >ensure argv is never used to override the ORBid. > > True, but passing a "-ORBid XXX" argument to ORB_init is in essence > identical to passing "XXX" as the third argument, which means > you're not getting the default ORB from that call. > Or at least that's one possible interpretation. :-( I agree, but that doesn't help the programmer decide if the default implementation of _default_POA can be used. The advantage of "first POA" is that the programmer can know which one that is, and when that is useful. > > As I related Matthew Newhook in private email, unfortunately > this whole > area of ORB initialization, shutdown, and destroy is really > messed up. A > number of different groups of people have worked on it over > the past five > or so years, and each group appears to have imparted slightly > different > semantics on the whole mess with each change. I have my own > opinions about > this, but frankly, I'm not sure we can really fix > _default_POA() correctly > until we get the whole lot fixed. Maybe we should just defer > this issue. I agree with you that there is an issue of architectural coherence that seems to have been lost. I would support deferring until we can at least scope the set of interrelated issues and explore them as a whole. This probably cuts across multiple rtfs - at least core and c++. From: Paul Kyzivat To: "'Michi Henning'" , Jonathan Biggar Cc: Paul Kyzivat , "'Steve Vinoski'" , C++ Revision Task Force Subject: RE: Proposal for 3055 Date: Wed, 5 Jan 2000 17:04:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: U\Zd9(=Z!!5a From: Michi Henning [mailto:michi@ooc.com.au] > > 1. Just deprecate _default_POA() having a default > implementation and > > make it pure virtual. > > Doing that would break an awful lot of code that currently > works just fine. I don't think we can do that. I agree. > > > 2. Define it to return the "first" ORB created in the > process, with two > > definitions of "first" possible: > > a. The result of the literal first call to ORB_init, so > if that ORB > > is destroyed, then the default _default_POA() implementation > breaks > > thereafter with an exception. > > I think this option is the best one because it yields the > fewest surprises. > > > b. The result of the first call to ORB_init after any > given point in > > time where there are exactly zero active ORBs in the process. > > I don't like this one much. It seems too complex. I prefer b. - I don't see that it is significantly more complex - Doing a would break code that I am aware of. I have written code that does ORB_init/shutdown/ORB_init, and then requires _default_POA to return the root poa from the second orb. This certainly seemed like a reasonable expectation at the time. Date: Thu, 6 Jan 2000 08:02:34 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: Jonathan Biggar , "'Steve Vinoski'" , C++ Revision Task Force Subject: RE: Proposal for 3055 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA91402B7@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 3mnd9SH1!!(2D!!%M&!! On Wed, 5 Jan 2000, Paul Kyzivat wrote: > > > b. The result of the first call to ORB_init after any > > given point in > > > time where there are exactly zero active ORBs in the process. > > > > I don't like this one much. It seems too complex. > > I prefer b. > > - I don't see that it is significantly more complex > > - Doing a would break code that I am aware of. > > I have written code that does ORB_init/shutdown/ORB_init, and then > requires > _default_POA to return the root poa from the second orb. > > This certainly seemed like a reasonable expectation at the time. I could go along with this. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Mon, 15 Jan 2001 23:40:54 -0330 From: Matthew Newhook To: cxx_revision@omg.org Subject: Issue 3055: _default_POA Message-ID: <20010115234054.B12335@ooc.com> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2.5i Content-Type: text/plain; charset=us-ascii X-UIDL: &ne!!"~_!!"0Je9,F@!! Hi, This is a nasty issue and IMO one of the worst and most error prone sections of the current C++ mapping. We see so many problems from our customers relating to misuse of _default_POA() -- somehow the customers seem to think that _default_POA() is magic. Either _this() should never have existed in the first place, OR _default_POA() should have been pure virtual. Frankly, my preference would be to make _default_POA() pure virtual and be done with it. Yes, this is not backwards compatible and lots of applications will have to change. However, I think that the change will be quite trivial. If the user wants the current behaviour they can define: PortableServer::POA_ptr _default_POA() { int ac = 0; CORBA::ORB_var orb = CORBA::ORB_init(ac, 0); return PortableServer::POA::_narrow( CORBA::Object_var(orb -> resolve_initial_references("RootPOA"))); } Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Sender: jbiggar@corvette.floorboard.com Message-ID: <3A68D5C2.8B0F028E@floorboard.com> Date: Fri, 19 Jan 2001 16:03:14 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: cxx_revision@omg.org Subject: Re: Issue 3055: _default_POA References: <20010115234054.B12335@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 4<>e9\%,e9SH > Hi, > > This is a nasty issue and IMO one of the worst and most error prone > sections of the current C++ mapping. We see so many problems from > our customers relating to misuse of _default_POA() -- somehow the > customers seem to think that _default_POA() is magic. > > Either _this() should never have existed in the first place, OR > _default_POA() should have been pure virtual. > > Frankly, my preference would be to make _default_POA() pure virtual > and be done with it. Yes, this is not backwards compatible and lots > of applications will have to change. > > However, I think that the change will be quite trivial. If the user > wants the current behaviour they can define: > > PortableServer::POA_ptr > _default_POA() > { > int ac = 0; > CORBA::ORB_var orb = CORBA::ORB_init(ac, 0); > return PortableServer::POA::_narrow( > CORBA::Object_var(orb -> resolve_initial_references("RootPOA"))); > } Well, it's not quite that trivial for some applications, since ORB_init won't necessarily return the right ORB. The semantics of _default_POA() say that it returns the root POA of the default ORB, but it never defines what the default ORB is. I'll bet that there are at least two ORB implementations that have different meanings for the term default ORB. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 19 Jan 2001 22:02:24 -0330 From: Matthew Newhook To: Jonathan Biggar Cc: cxx_revision@omg.org Subject: Re: Issue 3055: _default_POA Message-ID: <20010119220224.C23365@ooc.com> References: <20010115234054.B12335@ooc.com> <3A68D5C2.8B0F028E@floorboard.com> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A68D5C2.8B0F028E@floorboard.com>; from jon@floorboard.com on Fri, Jan 19, 2001 at 04:03:14PM -0800 Content-Type: text/plain; charset=us-ascii X-UIDL: ^/9!!'OFe9+[h!!V^l!! Hi, On Fri, Jan 19, 2001 at 04:03:14PM -0800, Jonathan Biggar wrote: > ... > Well, it's not quite that trivial for some applications, since ORB_init > won't necessarily return the right ORB. The semantics of _default_POA() > say that it returns the root POA of the default ORB, but it never > defines what the default ORB is. I'll bet that there are at least two > ORB implementations that have different meanings for the term default > ORB. If the specification doesn't say that the default ORB is the ORB with id "" then it's broken and should be fixed. I have it on good authority that this was the intent of the spec (see the archive for a post from Steve V. on this topic). This is absolutely the worst part of the POA specification -- it's unbelievable how many problems this causes our customers -- especially (but definitely not limited to) those that use multiple ORBs. > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725