Issue 5231: New issue: ForwardRequest(<local object>) (corba-rtf) Source: Oracle (Dr. Harold Carr, Ph.D., nobody) Nature: Uncategorized Issue Severity: Summary: The Portable Object Adapter and Portable Interceptors both are able to raise a ForwardRequest exception to allow redirection to another object. What happens if the ForwardRequest is to a local object? Is this even possible? Should it be allowed? I suggest we change the specification to make this illegal. Resolution: Revised Text: Actions taken: April 25, 2002: received issue April 11, 2012: Deferred Discussion: End of Annotations:===== Date: Thu, 25 Apr 2002 09:53:18 -0700 (PDT) From: Harold Carr To: issues@omg.org, corba-rtf@omg.org Subject: New issue: ForwardRequest() The Portable Object Adapter and Portable Interceptors both are able to raise a ForwardRequest exception to allow redirection to another object. What happens if the ForwardRequest is to a local object? Is this even possible? Should it be allowed? I suggest we change the specification to make this illegal. Cheers, Harold X-Sender: giddiv@postel X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Apr 2002 17:41:34 -0400 To: Harold Carr From: Victor Giddings Subject: Re: New issue: ForwardRequest() Cc: corba-rtf@omg.org At 09:53 AM 4/25/2002 -0700, Harold Carr wrote: The Portable Object Adapter and Portable Interceptors both are able to raise a ForwardRequest exception to allow redirection to another object. What happens if the ForwardRequest is to a local object? Just to make sure. By "local object" do you mean: 1) an instance of a local interface? 2) a collocated object instance? Is this even possible? 1) if client is in same process, no problem. It will be redirected to the local object. If client is remote, attempt to marshal the Object reference will fail with Marshal exception. 2) No problems, client (local or remote) will re-invoke on different object Should it be allowed? It is allowed if it doesn't break locality constraints. I suggest we change the specification to make this illegal. 1) It already is effectively. 2) Why should it be illegal? Cheers, Harold Victor Giddings mailto:victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 295 6501 Date: Thu, 2 May 2002 22:25:37 -0700 (PDT) From: Harold Carr To: corba-rtf@omg.org Subject: Issue 5231: ForwardRequest() Both Portable Interceptors (PI) and the Portable Object Adapter (POA) allow raising ForwardRequest(). However, the specification does not say what should happen if the given reference is an instance of a local interface. There may be problems. 1. If the client and server are not colocated and the ForwardRequest is raised on the server side, the local interface instance reference would need to be marshaled, which is not possible. It is not clear what should be indicated in this case. The PI spec says that SystemExceptions raised by interceptors are ignored. However, ForwardRequest is NOT a SystemException. 2. If the ForwardRequest is raised on the client side, it is not clear what should happen. For example, in the Java mappings, the initial invocation would go through a stub (digressing a moment - this leads to what happens when using DII?). When a retry is indicated that retry is handled by raising a RemarshalException which is caught in the Stub. It would need to be specified how the Stub's logic would handle such a situation (i.e., semantics of is_local, servant_pre/postinvoke, etc). It could probably be made to work, but is it worth it? 3. If the client and server are colocated and the ForwardRequest is raised on the server side then the problems of #2 apply. (There also may be additional issues of copying results - which is a form of marshaling/unmarshaling). Unless someone feels there is an important use case I suggest that raising ForwardRequest on a local interface instance be made illegal. Cheers, Harold Date: Wed, 23 Oct 2002 14:41:35 -0400 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Issue 5231 discussion Is there any strong reason to disallow ForwardRequest to local objects? As Victor points out in the archive: Just to make sure. By "local object" do you mean: 1) an instance of a local interface? 2) a collocated object instance? 1) if client is in same process, no problem. It will be redirected to the local object. If client is remote, attempt to marshal the Object reference will fail with Marshal exception. 2) No problems, client (local or remote) will re-invoke on different object Things become clearly much simpler if ForwardRequest to an instance of a local interface is not allowed since you then don't have to worry about who to notify when about the filure to marshal a local bject reference etc. So, what should we do? Any thoughts? Issue 5231: New issue: ForwardRequest() (corba-rtf) Click http://cgi.omg.org/issues/issue5231.txt for this issue's archive. Source: Sun Microsystems (Dr. Harold Carr, Ph.D., harold.carr@sun.com) Nature: Uncategorized Issue Severity: Summary: The Portable Object Adapter and Portable Interceptors both are able to raise a ForwardRequest exception to allow redirection to another object. What happens if the ForwardRequest is to a local object? Is this even possible? Should it be allowed? I suggest we change the specification to make this illegal. Sender: jbiggar@Resonate.com Date: Wed, 23 Oct 2002 13:20:24 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: corba-rtf@omg.org Subject: Re: Issue 5231 discussion Jishnu Mukerji wrote: > > Is there any strong reason to disallow ForwardRequest to local objects? > > As Victor points out in the archive: > > Just to make sure. By "local object" do you mean: > 1) an instance of a local interface? > 2) a collocated object instance? > > 1) if client is in same process, no problem. It will be redirected to > the local object. If client is remote, attempt to marshal the > Object reference will fail with Marshal exception. > 2) No problems, client (local or remote) will re-invoke on different > object > > Things become clearly much simpler if ForwardRequest to an instance of a > local interface is not allowed since you then don't have to worry about > who to notify when about the filure to marshal a local bject reference > etc. > > So, what should we do? Any thoughts? Hmmm, if we prohibit local objects from being the forward target, how does the ORB detect and enforce that beyond what it would already do by raising a MARSHAL exception? (Which in this case must go to the client with COMPLETED_YES, and the server would never know that it did a boo-boo.) Perhaps we should just punt and say that forwarding to a local object when the client is remote results in undefined behavior? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 23 Oct 2002 17:23:11 -0400 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: corba-rtf@omg.org Subject: Re: Issue 5231 discussion Jonathan Biggar wrote: > Hmmm, if we prohibit local objects from being the forward target, how > does the ORB detect and enforce that beyond what it would already do by > raising a MARSHAL exception? (Which in this case must go to the client > with COMPLETED_YES, and the server would never know that it did a > boo-boo.) > > Perhaps we should just punt and say that forwarding to a local object > when the client is remote results in undefined behavior? I could go for that. Want to propose some specific text? Thanks, Jishnu. Sender: jon@floorboard.com Date: Wed, 23 Oct 2002 21:42:24 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: Issue 5231 discussion Jishnu Mukerji wrote: > > Jonathan Biggar wrote: > > > Hmmm, if we prohibit local objects from being the forward target, how > > does the ORB detect and enforce that beyond what it would already do by > > raising a MARSHAL exception? (Which in this case must go to the client > > with COMPLETED_YES, and the server would never know that it did a > > boo-boo.) > > > > Perhaps we should just punt and say that forwarding to a local object > > when the client is remote results in undefined behavior? > > I could go for that. Want to propose some specific text? How about: 1. Add to section 11.3.5.1: Providing a local object as the forward_reference in a ForwardRequest exception results in undefined behavior if the request did not originate in the same process. 2. Add the same text to 21.3.15. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 24 Oct 2002 16:51:52 +0000 From: Harold Carr X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en To: Jonathan Biggar CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Issue 5231 discussion Hello, It seems that ForwardRequest() should be completely illegal or undefined. Here is an argument I raised before: ----- Both Portable Interceptors (PI) and the Portable Object Adapter (POA) allow raising ForwardRequest(). However, the specification does not say what should happen if the given reference is an instance of a local interface. There may be problems. 1. If the client and server are not colocated and the ForwardRequest is raised on the server side, the local interface instance reference would need to be marshaled, which is not possible. It is not clear what should be indicated in this case. The PI spec says that SystemExceptions raised by interceptors are ignored. However, ForwardRequest is NOT a SystemException. 2. If the ForwardRequest is raised on the client side, it is not clear what should happen. For example, in the Java mappings, the initial invocation would go through a stub (digressing a moment - this leads to what happens when using DII?). When a retry is indicated that retry is handled by raising a RemarshalException which is caught in the Stub. It would need to be specified how the Stub's logic would handle such a situation (i.e., semantics of is_local, servant_pre/postinvoke, etc). It could probably be made to work, but is it worth it? 3. If the client and server are colocated and the ForwardRequest is raised on the server side then the problems of #2 apply. (There also may be additional issues of copying results - which is a form of marshaling/unmarshaling). Unless someone feels there is an important use case I suggest that raising ForwardRequest on a local interface instance be made illegal. ------ Jonathan suggested: Providing a local object as the forward_reference in a ForwardRequest exception results in undefined behavior if the request did not originate in the same process. Unless the entire process can be explained (like above, Remarshal, is_local, etc) in this case without the need to change stubs, I would suggest it just be made illegal or undefined. Cheers, Harold Sender: jbiggar@Resonate.com Date: Thu, 24 Oct 2002 15:35:02 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Harold Carr CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Issue 5231 discussion Harold Carr wrote: > It seems that ForwardRequest() should be > completely illegal or undefined. > > Here is an argument I raised before: > > ----- > > Both Portable Interceptors (PI) and the Portable Object Adapter (POA) > allow raising ForwardRequest(). However, > the specification does not say what should happen if the given reference > is an instance of a local interface. There may be problems. > > 1. If the client and server are not colocated and the ForwardRequest > is raised on the server side, the local interface instance reference > would need to be marshaled, which is not possible. It is not clear > what should be indicated in this case. The PI spec says that > SystemExceptions raised by interceptors are ignored. However, > ForwardRequest is NOT a SystemException. I think this is a red herring, since the detection of the problem (a local object in a ForwardRequest) will occur inside the ORB, not inside an interceptor. What should happen in this case is exactly the same thing that should happen if a normal operation invocation happens to return a local object in an out or return parameter which needs to be returned to a remote client. > 2. If the ForwardRequest is raised on the client side, it is not clear > what should happen. For example, in the Java mappings, the initial > invocation would go through a stub (digressing a moment - this leads > to what happens when using DII?). When a retry is indicated that retry > is handled by raising a RemarshalException which is caught in the > Stub. It would need to be specified how the Stub's logic would handle > such a situation (i.e., semantics of is_local, servant_pre/postinvoke, > etc). It could probably be made to work, but is it worth it? > > 3. If the client and server are colocated and the ForwardRequest is > raised on the server side then the problems of #2 apply. (There also > may be additional issues of copying results - which is a form of > marshaling/unmarshaling). Not to dismiss your concern here, but most of this appears to be a concern with the Java portable stub & skeleton infrastructure, and not being a Java binding expert, I can't be reasonably expected to answer that, but I'll try. Can't the _servant_preinvoke() return a ServantObject whose servant member just happens to be the local object from the ForwardRequest. Since the local object implements the same Operations interface that the servant does, shouldn't this just work? And as long as that ServantObject isn't a ServantObjectExt, then the Interceptor framework won't get invoked. The DII case is interesting, and I can certainly agree it should fail there, since local objects don't support the DII. > Unless someone feels there is an important use case I suggest that > raising ForwardRequest on a local interface instance be made > illegal. Looking at it from the opposite point of view, a user should just expect this to work in the colocated case. If you are asking for an exception, it should be justified with specific information that shows that it is not feasible to implement it. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 04 Nov 2002 16:55:09 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Issue 5231 proposed resolution After ploughing through the archive it looks like the preponderance of opinion is aginst disallowing ForwardRequest to LocalObjects. So let us put the following resolution to vote and see if it passes. That is the only way to definitively tell what the real preponderance of opinion is. Jishnu. __________________________________________________________________ Issue 5231: New issue: ForwardRequest() (corba-rtf) Click here for this issue's archive. Source: Sun Microsystems (Dr. Harold Carr, Ph.D., harold.carr@sun.com) Nature: Uncategorized Issue Severity: Summary: The Portable Object Adapter and Portable Interceptors both are able to raise a ForwardRequest exception to allow redirection to another object. What happens if the ForwardRequest is to a local object? Is this even possible? Should it be allowed? I suggest we change the specification to make this illegal. Resolution: If we prohibit local objects from being the forward target, how does the ORB detect and enforce that beyond what it would already do by raising a MARSHAL exception? (Which in this case must go to the client with COMPLETED_YES, and the server would never know that it did amboo-boo.). A user should just expect this to work in the colocated case. If one is asking for an exception, it should be justified with specific information that shows that it is not feasible to implement it, and no real justification based on total unimplimentability has been provided so far in the discussion. So follow the principle of mimimal change and let ForwardRequests be raised with LocalObjects, and let them fail as is usual when an attempt is made to marshal said LocalObject. Revised Text: In formal/02-06-01 make the following changes: 1. Add to section 11.3.5.1: Providing a local object as the forward_reference in a ForwardRequest exception results in undefined behavior if the request did not originate in the same process. 2. Add the same text to 21.3.15. Actions taken: Incorporate changes and close issue. Date: Mon, 04 Nov 2002 16:55:09 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Issue 5231 proposed resolution After ploughing through the archive it looks like the preponderance of opinion is aginst disallowing ForwardRequest to LocalObjects. So let us put the following resolution to vote and see if it passes. That is the only way to definitively tell what the real preponderance of opinion is. Jishnu. __________________________________________________________________ Issue 5231: New issue: ForwardRequest() (corba-rtf) Click here for this issue's archive. Source: Sun Microsystems (Dr. Harold Carr, Ph.D., harold.carr@sun.com) Nature: Uncategorized Issue Severity: Summary: The Portable Object Adapter and Portable Interceptors both are able to raise a ForwardRequest exception to allow redirection to another object. What happens if the ForwardRequest is to a local object? Is this even possible? Should it be allowed? I suggest we change the specification to make this illegal. Resolution: If we prohibit local objects from being the forward target, how does the ORB detect and enforce that beyond what it would already do by raising a MARSHAL exception? (Which in this case must go to the client with COMPLETED_YES, and the server would never know that it did amboo-boo.). A user should just expect this to work in the colocated case. If one is asking for an exception, it should be justified with specific information that shows that it is not feasible to implement it, and no real justification based on total unimplimentability has been provided so far in the discussion. So follow the principle of mimimal change and let ForwardRequests be raised with LocalObjects, and let them fail as is usual when an attempt is made to marshal said LocalObject. Revised Text: In formal/02-06-01 make the following changes: 1. Add to section 11.3.5.1: Providing a local object as the forward_reference in a ForwardRequest exception results in undefined behavior if the request did not originate in the same process. 2. Add the same text to 21.3.15. Actions taken: Incorporate changes and close issue. Sender: carr@ha2sca-mail1.SFBay.Sun.COM Date: Wed, 06 Nov 2002 12:33:09 -0800 From: Harold Carr X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: Issue 5231 proposed resolution Hello all, I apologize for not bringing this up sooner, I've been out with the flu. > Revised Text: > In formal/02-06-01 make the following changes: > > 1. Add to section 11.3.5.1: > > Providing a local object as the forward_reference in a > ForwardRequest > exception results in undefined behavior if the request did not > originate > in the same process. > > 2. Add the same text to 21.3.15. Even if the object is in the same process (is process even defined in OMG documents?) it still won't work in both Java language mappings. Java stubs define a colocated optimization path. The first thing they ask is either: org.omg.CORBA.portable.ObjectImpl._is_local() or javax.rmi.CORBA.Util.isLocal (which ends up using the above). ObjectImpl._is_local just delegates: return _get_delegate().is_local(); But there is NO DELEGATE on local objects (I don't even think they inherit from ObjectImpl but can't remember right now). Bottom line: I think we should just disallow ForwardRequest() unless someone cares to define "process" (for all mappings) and update the Java mappings. Cheers, Harold Sender: jbiggar@Resonate.com Date: Wed, 06 Nov 2002 14:09:13 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Harold Carr CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Issue 5231 proposed resolution Harold Carr wrote: > > Hello all, > > I apologize for not bringing this up sooner, I've been out with the flu. > > > Revised Text: > > In formal/02-06-01 make the following changes: > > > > 1. Add to section 11.3.5.1: > > > > Providing a local object as the forward_reference in a ForwardRequest > > exception results in undefined behavior if the request did not originate > > in the same process. > > > > 2. Add the same text to 21.3.15. > > Even if the object is in the same process (is process even defined in > OMG documents?) it still won't work in both Java language mappings. > Java stubs define a colocated optimization path. The first thing they > ask is either: > > org.omg.CORBA.portable.ObjectImpl._is_local() > > or > > javax.rmi.CORBA.Util.isLocal (which ends up using the above). > > ObjectImpl._is_local just delegates: > > return _get_delegate().is_local(); > > But there is NO DELEGATE on local objects (I don't even think they > inherit from ObjectImpl but can't remember right now). > > Bottom line: I think we should just disallow ForwardRequest( object>) unless someone cares to define "process" (for all mappings) and > update the Java mappings. Hmmm, this appears to me to be a Java language mapping defect, not a general problem with the concept. I am quite sure that there are C++ implementations that handle forwarding to local objects right now (within the restriction that the invocation be locally generated of course.) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 06 Nov 2002 22:28:45 +0000 From: Harold Carr X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en To: Jonathan Biggar CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Issue 5231 proposed resolution Hello Jonathan, Jonathan Biggar wrote: > > Harold Carr wrote: > > > > > 1. Add to section 11.3.5.1: > > > > > > Providing a local object as the forward_reference in a > > >ForwardRequest > > > exception results in undefined behavior if the request did not > > >originate > > > in the same process. > > > > > > 2. Add the same text to 21.3.15. > > But there is NO DELEGATE on local objects (I don't even think they > > inherit from ObjectImpl but can't remember right now). > > > > Bottom line: I think we should just disallow > > ForwardRequest( > object>) unless someone cares to define "process" (for all > > mappings) and > > update the Java mappings. > > Hmmm, this appears to me to be a Java language mapping defect, not a > general problem with the concept. I am quite sure that there are > > C++ > implementations that handle forwarding to local objects right now > (within the restriction that the invocation be locally generated of > course.) I'm curious, can anyone say if they know of a C++ (or any other language mapping) were ForwardRequest() works (and how it works in the standard and mapping)? I suppose it would be possible to update the Java mappings such that _is_local would appear on LocalObject and return a default true. However, that can get complicated, as my next paragraph hints at. I still have a problem with the word "process". A running JVM is a process, but, since there are no globals in Java, CORBA objects created by different ORBs in the same VM instance are not considered colocated. Further, even for objects created by the same ORB, they still not be considered colocated unless they were loaded by the same class loader. What I just said applies to CORBA.Object. I am not clear of the details, off the top-of-my-head, of similar issues with LocalObject, but there may be some. Bottom line: to resolve this issue clearly it seems that one must precisely define "process" and also ensure that all language mappings either can support it or that issues be raised fix it. In fact, before passing this, it is probably a good idea to first raise and resolve languages issues to ensure it is even possible (probably is, but I'm not sure what that would entail). Cheers, Harold Sender: jbiggar@Resonate.com Date: Wed, 06 Nov 2002 14:45:23 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Harold Carr , corba-rtf@omg.org Subject: Re: Issue 5231 proposed resolution Harold Carr wrote: > > > Bottom line: I think we should just disallow ForwardRequest( > > object>) unless someone cares to define "process" (for all mappings) and > > > update the Java mappings. > > > > Hmmm, this appears to me to be a Java language mapping defect, not a > > general problem with the concept. I am quite sure that there are C++ > > implementations that handle forwarding to local objects right now > > (within the restriction that the invocation be locally generated of > > course.) > > I'm curious, can anyone say if they know of a C++ (or any other language > mapping) were ForwardRequest() works (and how it works in > the standard and mapping)? To the best of my knowledge, only Java has specified the exact code of a stub operation. There's nothing wrong with this, and is necessary due to Java's binary level portability. The other language mappings leave the exact code in a stub up to the vendor. I can unequivocably say that the way to make forwarding to a local object work in C++ is entirely obvious, and I can also unequivocably say that I know of at least one implementation where it works today. > I suppose it would be possible to update the Java mappings such that > _is_local would appear on LocalObject and return a default true. > However, that can get complicated, as my next paragraph hints at. > > I still have a problem with the word "process". A running JVM is a > process, but, since there are no globals in Java, CORBA objects > created > by different ORBs in the same VM instance are not considered > colocated. > Further, even for objects created by the same ORB, they still not be > considered colocated unless they were loaded by the same class > loader. > What I just said applies to CORBA.Object. I am not clear of the > details, off the top-of-my-head, of similar issues with LocalObject, > but > there may be some. > > Bottom line: to resolve this issue clearly it seems that one must > precisely define "process" and also ensure that all language > mappings > either can support it or that issues be raised fix it. In fact, > before > passing this, it is probably a good idea to first raise and resolve > languages issues to ensure it is even possible (probably is, but I'm > not > sure what that would entail). The definition of "process" need to be no better qualified than saying that in any case where an invocation of an operation can successfully pass in or out a local object as an argument, then the caller and callee are both in the same process. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 6 Nov 2002 15:54:50 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Issue 5231 proposed resolution To: harold.carr@sun.com, jon@floorboard.com Cc: jishnu@hp.com, corba-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc > >Hmmm, this appears to me to be a Java language mapping defect, not a >general problem with the concept. I would point out that the defect was introduced by the definition of local objects, which did not exist at the time that the Java language mapping was finalized. In any case, I am in favor of working towards a solution, if the core RTF decides that forwarding to a local object is legal. >I am quite sure that there are C++ >implementations that handle forwarding to local objects right now >(within the restriction that the invocation be locally generated of >course.) > Of course, the C++ mapping does not mandate portable stubs, so a C++ vendor is free to do whatever they wish for their stubs. The whole design of local objects is to make them as fast as possible, so they do not need stubs. They are also not ORB mediated; in fact, the current Java mapping does not even provide access to an ORB instance (this will change once we support an ORB accessor on org.omg.CORBA.Object). It is also a given that we cannot change the portable stub definition in the Java mapping (which predates local objects by several years) in ways that are incompatible. In any case, I think it may be possible to support location forwards to local objects with only a few small changes to the Java mappings, but it will take a bit longer to investigate this than Harold and I have this week. It may be better to delay a vote on 5231 until we have had time to prototype the mapping issues. Thanks, Ken. Date: Wed, 06 Nov 2002 23:56:17 +0000 From: Harold Carr X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en To: Jonathan Biggar CC: corba-rtf@omg.org Subject: Re: Issue 5231 proposed resolution Hello Jonathan, > To the best of my knowledge, only Java has specified the exact code of a > stub operation. There's nothing wrong with this, and is necessary due > to Java's binary level portability. > > The other language mappings leave the exact code in a stub up to the > vendor. I can unequivocably say that the way to make forwarding to a > local object work in C++ is entirely obvious, and I can also > unequivocably say that I know of at least one implementation where it > works today. Yes, the Java stubs certainly are necessary (and useful) but do cause constraints. Without portable stubs I can certainly see there would be no problem. > > The definition of "process" need to be no better qualified than >saying > that in any case where an invocation of an operation can >successfully > pass in or out a local object as an argument, then the caller and >callee > are both in the same process. That seems reasonable. It may want to say "pass in or out a local object (without copying) as an argument". I was talking a moment ago to Ken Cavanaugh. He has some ideas on this issue so expect to hear from him soon. I would request that this issue be removed from the current round while we come up with a solution that works for Java. Once again, sorry to be late on this, but I was out with the flu. Cheers, H Sender: jbiggar@Resonate.com Date: Wed, 06 Nov 2002 16:11:26 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Harold Carr CC: corba-rtf@omg.org Subject: Re: Issue 5231 proposed resolution Harold Carr wrote: > > The definition of "process" need to be no better qualified than saying > > that in any case where an invocation of an operation can successfully > > pass in or out a local object as an argument, then the caller and callee > > are both in the same process. > > That seems reasonable. It may want to say "pass in or out a local > object (without copying) as an argument". Why is this necessary? There's no copy semantic defined for local objects. > I was talking a moment ago to Ken Cavanaugh. He has some ideas on this > issue so expect to hear from him soon. I would request that this issue > be removed from the current round while we come up with a solution that > works for Java. Once again, sorry to be late on this, but I was out > with the flu. That's fine with me. [The postponement, of course, not the flu :)] -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 06 Nov 2002 19:13:33 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Harold Carr Cc: Jonathan Biggar , corba-rtf@omg.org Subject: Re: Issue 5231 proposed resolution Harold Carr wrote: > I was talking a moment ago to Ken Cavanaugh. He has some ideas on this > issue so expect to hear from him soon. I would request that this issue > be removed from the current round while we come up with a solution that > works for Java. Once again, sorry to be late on this, but I was out > with the flu. Fear not. As soon as you raised the technical objection it got taken off the table and placed in the list of issues requiring further discussion. Jishnu.