Issue 3754: Java reverse mapping local case cannot properly support Portable Intercepto (java2idl-rtf) Source: Oracle (Dr. Harold Carr, Ph.D., nobody) Nature: Uncategorized Issue Severity: Summary: The local mapping makes it impossible to determine which ending point to call. ptc/00-01-06 says: BEGIN_QUOTE 1.5.2.2 Local Stubs The stub class may provide an optimized call path for local server implementation objects. For a method echo(int x) of a remote interface Aardvark, the optimized path does the following: 1. Find out if the servant is local by calling Util.isLocal() 2. If the servant is local, call this._servant_preinvoke("echo",Aardvark.class) 3. If _servant_preinvoke returned a non-null ServantObject so, call ((Aardvark)so.servant).echo(x) 4. If _servant_preinvoke returned a non-null ServantObject so, call this._servant_postinvoke(so) 5. If _servant_preinvoke returned null, repeat step 1. The call to Util.isLocal() will return false, causing the non-optimized path to be followed. ... The following is an example of a stub class that provides this optimized call path. // Java public class _Aardvark_Stub extends javax.rmi.CORBA.Stub implements Aardvark { public int echo(int x) throws java.rmi.RemoteException, Boomerang { if (!javax.rmi.CORBA.Util.isLocal(this)) { ... } else { // local call path org.omg.CORBA.portable.ServantObject so = _servant_preinvoke("echo", Aardvark.class); if (so == null) return echo(x); try { return ((Aardvark)so.servant).echo(x); } catch (Throwable ex) { Throwable ex2 = (Throwable) javax.rmi.CORBA.Util.copyObject(ex, _orb()); if (ex2 instanceof Boomerang) throw (Boomerang)ex2; else throw javax.CORBA.Util.wrapException(ex2); } finally { _servant_postinvoke(so); } } } } END_QUOTE ClientRequestInterceptor::send_request would need to be invoked by the ORB inside _servant_preinvoke. ClientRequestInterceptor::receive_reply or receive_exception would need to be called inside _servant_postinvoke. (Note that receive_other would not happen since, if a POA were involved inside _servant_preinvoke and a servant manager raised ForwardRequest, this should cause _servant_preinvoke to return null resulting in a recursive call to the method. In this case the ORB would not call send_request in the first place, or, if it did, it would handle the call to the receive_other internally inside of _servant_preinvoke.) One is tempted to say that the ORB could remember if javax.rmi.CORBA.Util.copyObject was called on behalf of this request. In that case, when _servant_postinvoke is called it would know there was an exception (and would have it hands on the exception object - which needs to be available via Portable Interceptors). However, this does not work. The example does not show it, but if the method returns values those values are filtered through javax.rmi.CORBA.Util.copyObject before being returned to the client. Exception objects are legal return values. So there is no way to determine if copyObject was called to copy return values or exception objects resulting from an actually exception. Therefore this trick will not work. Bottom line: there is no reliable way to determine which Portable Interceptor ending point to call in the Java reverse mapping local case. Resolution: see below Revised Text: Resolution: Closed, accepted. This issue corresponds to issue 4701 in the IDL to Java RTF, and this proposed resolution is intended to be consistent with the resolution to that issue. See revised text below. Revised Text: 1. In section 1.5.2.2, replace steps 3 and 4 by the following, and renumber step 5 to step 4. 3. If _servant_preinvoke returned a non-null ServantObject so, do the following: a. Call ((Aardvark)so.servant).echo(x) b. If the invocation on the servant completed without throwing an exception, and so is an instance of ServantObjectExt, then call so.normalCompletion(). c. If the invocation on the servant threw exception exc, and so is an instance of ServantObjectExt, then call so.exceptionalCompletion(exc). d. Call this._servant_postinvoke(so) 2. In the sample code in section 1.5.2.2, replace the following code: try { return ((Aardvark)so.servant).echo(x); } catch (Throwable ex) { Throwable ex2 = (Throwable) by the following: try { int result = ((Aardvark)so.servant).echo(x); if (so instanceof ServantObjectExt) ((ServantObjectExt)so).normalCompletion() ; return result; } catch (Throwable ex) { if (so instanceof ServantObjectExt) ((ServantObjectExt)so).exceptionalCompletion(ex); Throwable ex2 = (Throwable) Actions taken: July 21, 2000: received issue July 26, 2000: moved to the IDL-Java RTF December 18, 2001: moved back to Java to IDL RTF May 13, 2002: closed issue Discussion: This issue is clearly about the Java to IDL mapping, so it belongs in the Java to IDL RTF, which is where is was originally. However, it was reassigned to this RTF I think largely because the solution requires changes to the org.omg.CORBA.portable APIs, which belong to the Java RTF. I have created issue 4701 to cover the Java mapping issues and the changes to the portable APIs. This issue should be re-assigned back to the Java to IDL RTF. End of Annotations:===== Date: Fri, 21 Jul 2000 15:50:06 -0700 (PDT) Message-Id: <200007212250.PAA27354@shorter.eng.sun.com> From: Harold Carr To: java2idl-rtf@omg.org, issues@omg.org Cc: interceptors-ftf@omg.org Subject: Java reverse mapping local case cannot properly support Portable Interceptors Content-Type: text X-UIDL: ;DA!!OS)!!hpC!!I$@!! This is a java2idl issue: The local mapping makes it impossible to determine which ending point to call. ptc/00-01-06 says: BEGIN_QUOTE 1.5.2.2 Local Stubs The stub class may provide an optimized call path for local server implementation objects. For a method echo(int x) of a remote interface Aardvark, the optimized path does the following: 1. Find out if the servant is local by calling Util.isLocal() 2. If the servant is local, call this._servant_preinvoke("echo",Aardvark.class) 3. If _servant_preinvoke returned a non-null ServantObject so, call ((Aardvark)so.servant).echo(x) 4. If _servant_preinvoke returned a non-null ServantObject so, call this._servant_postinvoke(so) 5. If _servant_preinvoke returned null, repeat step 1. The call to Util.isLocal() will return false, causing the non-optimized path to be followed. ... The following is an example of a stub class that provides this optimized call path. // Java public class _Aardvark_Stub extends javax.rmi.CORBA.Stub implements Aardvark { public int echo(int x) throws java.rmi.RemoteException, Boomerang { if (!javax.rmi.CORBA.Util.isLocal(this)) { ... } else { // local call path org.omg.CORBA.portable.ServantObject so = _servant_preinvoke("echo", Aardvark.class); if (so == null) return echo(x); try { return ((Aardvark)so.servant).echo(x); } catch (Throwable ex) { Throwable ex2 = (Throwable) javax.rmi.CORBA.Util.copyObject(ex, _orb()); if (ex2 instanceof Boomerang) throw (Boomerang)ex2; else throw javax.CORBA.Util.wrapException(ex2); } finally { _servant_postinvoke(so); } } } } END_QUOTE ClientRequestInterceptor::send_request would need to be invoked by the ORB inside _servant_preinvoke. ClientRequestInterceptor::receive_reply or receive_exception would need to be called inside _servant_postinvoke. (Note that receive_other would not happen since, if a POA were involved inside _servant_preinvoke and a servant manager raised ForwardRequest, this should cause _servant_preinvoke to return null resulting in a recursive call to the method. In this case the ORB would not call send_request in the first place, or, if it did, it would handle the call to the receive_other internally inside of _servant_preinvoke.) One is tempted to say that the ORB could remember if javax.rmi.CORBA.Util.copyObject was called on behalf of this request. In that case, when _servant_postinvoke is called it would know there was an exception (and would have it hands on the exception object - which needs to be available via Portable Interceptors). However, this does not work. The example does not show it, but if the method returns values those values are filtered through javax.rmi.CORBA.Util.copyObject before being returned to the client. Exception objects are legal return values. So there is no way to determine if copyObject was called to copy return values or exception objects resulting from an actually exception. Therefore this trick will not work. Bottom line: there is no reliable way to determine which Portable Interceptor ending point to call in the Java reverse mapping local case. Cheers, Harold Reply-To: From: "Nick Sharman" To: "Harold Carr" , , Cc: Subject: RE: Java reverse mapping local case cannot properly support Portable Interceptors Date: Mon, 24 Jul 2000 16:15:31 +0100 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <200007212250.PAA27354@shorter.eng.sun.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 8=~e9oOD!!3;~e9 -----Original Message----- > From: Harold Carr [mailto:harold.carr@eng.sun.com] > Sent: Friday, July 21, 2000 11:50 PM > To: java2idl-rtf@omg.org; issues@omg.org > Cc: interceptors-ftf@omg.org > Subject: Java reverse mapping local case cannot properly support > Portable Interceptors > > > > This is a java2idl issue: > > The local mapping makes it impossible to determine which ending point > to call. > > ptc/00-01-06 says: > > BEGIN_QUOTE > > 1.5.2.2 Local Stubs > > The stub class may provide an optimized call path for local server > implementation objects. For a method echo(int x) of a remote interface > Aardvark, the optimized path does the following: > > 1. Find out if the servant is local by calling Util.isLocal() > 2. If the servant is local, call > this._servant_preinvoke("echo",Aardvark.class) > 3. If _servant_preinvoke returned a non-null ServantObject so, call > ((Aardvark)so.servant).echo(x) > 4. If _servant_preinvoke returned a non-null ServantObject so, call > this._servant_postinvoke(so) > 5. If _servant_preinvoke returned null, repeat step 1. The call to > Util.isLocal() will return false, causing the non-optimized > path to be followed. > ... > > The following is an example of a stub class that provides this > optimized call path. > > // Java > public class _Aardvark_Stub extends javax.rmi.CORBA.Stub > implements Aardvark > { > public int echo(int x) > throws java.rmi.RemoteException, Boomerang > { > if (!javax.rmi.CORBA.Util.isLocal(this)) { > ... > } else { > // local call path > org.omg.CORBA.portable.ServantObject so = > _servant_preinvoke("echo", Aardvark.class); > if (so == null) > return echo(x); > try { > return ((Aardvark)so.servant).echo(x); > } catch (Throwable ex) { > Throwable ex2 = (Throwable) > javax.rmi.CORBA.Util.copyObject(ex, _orb()); > if (ex2 instanceof Boomerang) > throw (Boomerang)ex2; > else > throw javax.CORBA.Util.wrapException(ex2); > } finally { > _servant_postinvoke(so); > } > } > } > } > > END_QUOTE > > > ClientRequestInterceptor::send_request would need to be invoked by the > ORB inside _servant_preinvoke. > > ClientRequestInterceptor::receive_reply or receive_exception would > need to be called inside _servant_postinvoke. > > (Note that receive_other would not happen since, if a POA were > involved inside _servant_preinvoke and a servant manager raised > ForwardRequest, this should cause _servant_preinvoke to return null > resulting in a recursive call to the method. In this case the ORB > would not call send_request in the first place, or, if it did, it > would handle the call to the receive_other internally inside of > _servant_preinvoke.) > > One is tempted to say that the ORB could remember if > javax.rmi.CORBA.Util.copyObject was called on behalf of this request. > In that case, when _servant_postinvoke is called it would know there > was an exception (and would have it hands on the exception object - > which needs to be available via Portable Interceptors). > > However, this does not work. The example does not show it, but if the > method returns values those values are filtered through > javax.rmi.CORBA.Util.copyObject before being returned to the client. > Exception objects are legal return values. So there is no way to > determine if copyObject was called to copy return values or exception > objects resulting from an actually exception. Therefore this trick > will not work. > > Bottom line: there is no reliable way to determine which Portable > Interceptor ending point to call in the Java reverse mapping local > case. > > Cheers, > Harold > > Reply-To: From: "Nick Sharman" To: "Harold Carr" Cc: , , Subject: RE: Java reverse mapping local case cannot properly support Portable Interceptors Date: Tue, 25 Jul 2000 09:38:37 +0100 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <397C783B.9E4C3A0@sun.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: UAV!!"b+e92[3e94,Ie9 > -----Original Message----- > From: Harold Carr [mailto:harold.carr@sun.com] > Sent: Monday, July 24, 2000 6:09 PM > To: nick.sharman@peerlogic.com > Cc: Harold Carr; issues@omg.org; interceptors-ftf@omg.org; > java2idl-rtf@omg.org > Subject: Re: Java reverse mapping local case cannot properly support > Portable Interceptors > > > How about if the interceptor spec added another sentence to item 1 of > section 21.3.1 in ptc/2000-04-05: > > If the call path has been optimized local server implementation objects > then invocations on those objects may or may not be ORB mediated. > Yes, that sounds OK. Nick Date: Tue, 25 Jul 2000 13:21:00 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: nick.sharman@peerlogic.com CC: issues@omg.org, interceptors-ftf@omg.org, java2idl-rtf@omg.org Subject: Issue 3754 - Java reverse mapping local case cannot properly support Portable Interceptors References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ;BOd9d=(e9]lJe9J'Y!! On further thought, I think "may or may not be ORB mediated" should mean you cannot guarantee that any particular ORB will interceptor local calls. However, it also should mean that, if the call is intercepted, that all ORBs act the same. This cannot be guaranteed given the problems I raised. Perhaps a it would be better to say that local calls are not considered orb mediated. In the future, if language mapping rtfs fix the local mappings to support local with PI then they can update the PI spec to remove this clause. Comments? Should we say anything at all in PI? If so, which of the above? Or something else? Cheers, Harold Nick Sharman wrote: > > > -----Original Message----- > > From: Harold Carr [mailto:harold.carr@sun.com] > > Sent: Monday, July 24, 2000 6:09 PM > > To: nick.sharman@peerlogic.com > > Cc: Harold Carr; issues@omg.org; interceptors-ftf@omg.org; > > java2idl-rtf@omg.org > > Subject: Re: Java reverse mapping local case cannot properly support > > Portable Interceptors > > > > > > How about if the interceptor spec added another sentence to item 1 of > > section 21.3.1 in ptc/2000-04-05: > > > > If the call path has been optimized local server implementation objects > > then invocations on those objects may or may not be ORB mediated. > > > Yes, that sounds OK. > > Nick Date: Wed, 26 Jul 2000 10:07:02 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr CC: nick.sharman@peerlogic.com, issues@omg.org, interceptors-ftf@omg.org, java2idl-rtf@omg.org Subject: Re: Issue 3754 - Java reverse mapping local case cannot properly support Portable Interceptors References: <397DF6AC.B28A792D@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ?`Ce9Wff!!Gm=!!GHJava mapping, let alone with the Java->IDL mapping, but it seems we are possibly confusing invocations on "local interfaces" implemented via LocalObject with invocations on regular interfaces that happen to be colocated (client and server in the same address space and using the same ORB instance). The specification of local interfaces and LocalObject should clearly state that invocations on these are not ORB mediated. Therefore, I think it should be clear that Portable Interceptors would not be invoked during invocations on these objects. Implementors and users of local interfaces know that normal location transparency for ORB services does not apply on these local object invocations. But for regular interfaces implemented via the POA, I think it has previously been agreed that these must always be ORB mediated so that the PortableServer::Current, and the Current objects for other ORB services, can be setup to reflect the immediate invocation being processed by the servant. This is necessary to preserve location transparency. For ORB services implemented via the Portable Interceptor APIs, I think this requires the Portable Interceptors to be called. If the Java mapping and/or the Java portable stub/skeleton APIs do not make this possible, then I think something needs to be fixed. But I could be missing something. Its also possible that the reverse mapping is a completely different case, and the POA is not involved. But, unless the interfaces are actually declared "local", I think Portable Interceptors need to be invoked so that location transparency can be provided by other ORB services. Anyway, can someone please clarify exactly what is meant by "local calls" in this thread? -Bob Harold Carr wrote: > > On further thought, I think "may or may not be ORB mediated" should mean > you cannot guarantee that any particular ORB will interceptor local > calls. However, it also should mean that, if the call is intercepted, > that all ORBs act the same. This cannot be guaranteed given the > problems I raised. > > Perhaps a it would be better to say that local calls are not considered > orb mediated. In the future, if language mapping rtfs fix the local > mappings to support local with PI then they can update the PI spec to > remove this clause. > > Comments? > > Should we say anything at all in PI? > If so, which of the above? > Or something else? > > Cheers, > Harold > > Nick Sharman wrote: > > > > > -----Original Message----- > > > From: Harold Carr [mailto:harold.carr@sun.com] > > > Sent: Monday, July 24, 2000 6:09 PM > > > To: nick.sharman@peerlogic.com > > > Cc: Harold Carr; issues@omg.org; interceptors-ftf@omg.org; > > > java2idl-rtf@omg.org > > > Subject: Re: Java reverse mapping local case cannot properly support > > > Portable Interceptors > > > > > > > > > How about if the interceptor spec added another sentence to item 1 of > > > section 21.3.1 in ptc/2000-04-05: > > > > > > If the call path has been optimized local server implementation objects > > > then invocations on those objects may or may not be ORB mediated. > > > > > Yes, that sounds OK. > > > > Nick Date: Wed, 26 Jul 2000 07:13:08 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kukura CC: nick.sharman@peerlogic.com, issues@omg.org, interceptors-ftf@omg.org, java2idl-rtf@omg.org Subject: Re: Issue 3754 - Java reverse mapping local case cannot properly support Portable Interceptors References: <397DF6AC.B28A792D@sun.com> <397EF086.8B13ED07@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ]X$"!KlTd9IA2!!6e@!! Bob Kukura wrote: edited... > > I think this requires the Portable Interceptors to be called. If > the Java mapping and/or the Java portable stub/skeleton APIs do not >make > this possible, then I think something needs to be fixed. But I could >be > missing something. > Anyway, can someone please clarify exactly what is meant by "local > calls" in this thread? I am NOT talking about local interfaces. Please refer to my original message: * Java reverse mapping local case cannot properly support Portable Interceptors The local mapping makes it impossible to determine which ending point to call. ptc/00-01-06 says: BEGIN_QUOTE 1.5.2.2 Local Stubs The stub class may provide an optimized call path for local server implementation objects. For a method echo(int x) of a remote interface Aardvark, the optimized path does the following: 1. Find out if the servant is local by calling Util.isLocal() 2. If the servant is local, call this._servant_preinvoke("echo",Aardvark.class) 3. If _servant_preinvoke returned a non-null ServantObject so, call ((Aardvark)so.servant).echo(x) 4. If _servant_preinvoke returned a non-null ServantObject so, call this._servant_postinvoke(so) 5. If _servant_preinvoke returned null, repeat step 1. The call to Util.isLocal() will return false, causing the non-optimized path to be followed. ... The following is an example of a stub class that provides this optimized call path. // Java public class _Aardvark_Stub extends javax.rmi.CORBA.Stub implements Aardvark { public int echo(int x) throws java.rmi.RemoteException, Boomerang { if (!javax.rmi.CORBA.Util.isLocal(this)) { ... } else { // local call path org.omg.CORBA.portable.ServantObject so = _servant_preinvoke("echo", Aardvark.class); if (so == null) return echo(x); try { return ((Aardvark)so.servant).echo(x); } catch (Throwable ex) { Throwable ex2 = (Throwable) javax.rmi.CORBA.Util.copyObject(ex, _orb()); if (ex2 instanceof Boomerang) throw (Boomerang)ex2; else throw javax.CORBA.Util.wrapException(ex2); } finally { _servant_postinvoke(so); } } } } END_QUOTE ClientRequestInterceptor::send_request would need to be invoked by the ORB inside _servant_preinvoke. ClientRequestInterceptor::receive_reply or receive_exception would need to be called inside _servant_postinvoke. (Note that receive_other would not happen since, if a POA were involved inside _servant_preinvoke and a servant manager raised ForwardRequest, this should cause _servant_preinvoke to return null resulting in a recursive call to the method. In this case the ORB would not call send_request in the first place, or, if it did, it would handle the call to the receive_other internally inside of _servant_preinvoke.) One is tempted to say that the ORB could remember if javax.rmi.CORBA.Util.copyObject was called on behalf of this request. In that case, when _servant_postinvoke is called it would know there was an exception (and would have it hands on the exception object - which needs to be available via Portable Interceptors). However, this does not work. The example does not show it, but if the method returns values those values are filtered through javax.rmi.CORBA.Util.copyObject before being returned to the client. Exception objects are legal return values. So there is no way to determine if copyObject was called to copy return values or exception objects resulting from an actually exception. Therefore this trick will not work. Bottom line: there is no reliable way to determine which Portable Interceptor ending point to call in the Java reverse mapping local case. Cheers, Harold Date: Thu, 27 Jul 2000 00:57:20 +1000 (EST) From: Michi Henning To: Bob Kukura cc: Harold Carr , nick.sharman@peerlogic.com, issues@omg.org, interceptors-ftf@omg.org, java2idl-rtf@omg.org Subject: Re: Issue 3754 - Java reverse mapping local case cannot properly support Portable Interceptors In-Reply-To: <397EF086.8B13ED07@iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ;4?!!=1L!!TYk!!~;=!! On Wed, 26 Jul 2000, Bob Kukura wrote: > I'm getting more and more confused with what is meant by "local calls" > in this thread. I don't claim to be very familiar with the IDL->Java > mapping, let alone with the Java->IDL mapping, but it seems we are > possibly confusing invocations on "local interfaces" implemented via > LocalObject with invocations on regular interfaces that happen to be > colocated (client and server in the same address space and using the > same ORB instance). > > The specification of local interfaces and LocalObject should clearly > state that invocations on these are not ORB mediated. Therefore, I > think it should be clear that Portable Interceptors would not be invoked > during invocations on these objects. Implementors and users of local > interfaces know that normal location transparency for ORB services does > not apply on these local object invocations. I completely and utterly agree with that! 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: Thu, 27 Jul 2000 01:00:00 +1000 (EST) From: Michi Henning To: Harold Carr cc: Bob Kukura , nick.sharman@peerlogic.com, issues@omg.org, interceptors-ftf@omg.org, java2idl-rtf@omg.org Subject: Re: Issue 3754 - Java reverse mapping local case cannot properly support Portable Interceptors In-Reply-To: <397EF1F4.AF7251AE@sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: <":!!a4e!!C!l!!8-!e9 On Wed, 26 Jul 2000, Harold Carr wrote: > BEGIN_QUOTE > > 1.5.2.2 Local Stubs > > The stub class may provide an optimized call path for local server > implementation objects. For a method echo(int x) of a remote > interface > Aardvark, the optimized path does the following: > > 1. Find out if the servant is local by calling Util.isLocal() ^^^^^^^^^^^^^^ To me, it looks like the object model got stomped on big-time right there. With the flexible object-to-servant mappings offered by the POA, that's a meaningless question to ask. 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, 26 Jul 2000 08:29:30 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Bob Kukura , nick.sharman@peerlogic.com, issues@omg.org, interceptors-ftf@omg.org, java2idl-rtf@omg.org Subject: Re: Issue 3754 - Java reverse mapping local case cannot properlysupport Portable Interceptors References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: F@j!!*^K!!P1Yd9*&[!! I agree. The point now, for PI, is to deal with this broken model. I've made a proposal in previous mails. Basically say that these kind of optimized calls are not considered ORB-mediated. A mapping RTF can change that when and if they fix it. BTW: what is broke, with respect to PI, is not so much the Util.isLocal call, but the information that can be inferred in the calls to _servant_preinvoke and _servant_postinvoke (or I should say the information that CANNOT be inferred). H Michi Henning wrote: > > On Wed, 26 Jul 2000, Harold Carr wrote: > > > BEGIN_QUOTE > > > > 1.5.2.2 Local Stubs > > > > The stub class may provide an optimized call path for local server > > implementation objects. For a method echo(int x) of a remote interface > > Aardvark, the optimized path does the following: > > > > 1. Find out if the servant is local by calling Util.isLocal() > ^^^^^^^^^^^^^^ > > To me, it looks like the object model got stomped on big-time right there. > With the flexible object-to-servant mappings offered by the POA, that's > a meaningless question to ask. > > 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, 26 Jul 2000 11:41:04 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr CC: Michi Henning , nick.sharman@peerlogic.com, interceptors-ftf@omg.org, java2idl-rtf@omg.org Subject: Re: Issue 3754 - Java reverse mapping local case cannot properlysupport Portable Interceptors References: <397F03DA.11C59568@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 'DLe9DYP!!lh7e9Piid9 I'm opposed to saying these kind of calls are not ORB-mediated in the PI specification. As far as I can tell, the intent is that ORB services behave normally, with location tranparancy, on these co-located calls, and we should not change this for ORB services implemented via PI. If we can't fix it in PI, I think we need to leave it for the appropriate Java mapping RTF to fix. But we shouldn't declare it not to be broken. -Bob Harold Carr wrote: > > I agree. The point now, for PI, is to deal with this broken model. I've > made a proposal in previous mails. Basically say that these kind of > optimized calls are not considered ORB-mediated. A mapping RTF can > change that when and if they fix it. BTW: what is broke, with respect > to PI, is not so much the Util.isLocal call, but the information that > can be inferred in the calls to _servant_preinvoke and > _servant_postinvoke (or I should say the information that CANNOT be > inferred). > > H > > Michi Henning wrote: > > > > On Wed, 26 Jul 2000, Harold Carr wrote: > > > > > BEGIN_QUOTE > > > > > > 1.5.2.2 Local Stubs > > > > > > The stub class may provide an optimized call path for local server > > > implementation objects. For a method echo(int x) of a remote interface > > > Aardvark, the optimized path does the following: > > > > > > 1. Find out if the servant is local by calling Util.isLocal() > > ^^^^^^^^^^^^^^ > > > > To me, it looks like the object model got stomped on big-time right there. > > With the flexible object-to-servant mappings offered by the POA, that's > > a meaningless question to ask. > > > > 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: Thu, 27 Jul 2000 01:41:43 +1000 (EST) From: Michi Henning To: Harold Carr cc: interceptors-ftf@omg.org, java2idl-rtf@omg.org Subject: Re: Issue 3754 - Java reverse mapping local case cannot properlysupport Portable Interceptors In-Reply-To: <397F03DA.11C59568@sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: GER!!#A~e9-JWd9YLHe9 On Wed, 26 Jul 2000, Harold Carr wrote: > I agree. The point now, for PI, is to deal with this broken model. I've > made a proposal in previous mails. Basically say that these kind of > optimized calls are not considered ORB-mediated. A mapping RTF can > change that when and if they fix it. Sounds reasonable to me. > BTW: what is broke, with respect > to PI, is not so much the Util.isLocal call, but the information > that > can be inferred in the calls to _servant_preinvoke and > _servant_postinvoke (or I should say the information that CANNOT be > inferred). Sorry, I don't understand. Can you explain? What bits would you like to be able to infer? 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: Thu, 27 Jul 2000 01:45:08 +1000 (EST) From: Michi Henning To: Bob Kukura cc: interceptors-ftf@omg.org, java2idl-rtf@omg.org Subject: Re: Issue 3754 - Java reverse mapping local case cannot properlysupport Portable Interceptors In-Reply-To: <397F0690.56A3299C@iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 8$*e9508e9LR4!!ll`d9 On Wed, 26 Jul 2000, Bob Kukura wrote: > I'm opposed to saying these kind of calls are not ORB-mediated in the PI > specification. As far as I can tell, the intent is that ORB services > behave normally, with location tranparancy, on these co-located calls, > and we should not change this for ORB services implemented via PI. I don't think that was the intent, unless I misunderstood something. > > previous mails. Basically say that these kind of > > optimized calls are not considered ORB-mediated. To me, that refers to the broken optimization for Java, not collocated calls in general. If I misread the intent, then I have to agree with Bob. 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, 26 Jul 2000 09:28:40 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: interceptors-ftf@omg.org, java2idl-rtf@omg.org Subject: Re: Issue 3754 - Java reverse mapping local case cannot properlysupportPortable Interceptors References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: >Hgd97AC!!W:^d9<:)e9 Michi Henning wrote: > > On Wed, 26 Jul 2000, Harold Carr wrote: > > > BTW: what is broke, with respect > > to PI, is not so much the Util.isLocal call, but the information that > > can be inferred in the calls to _servant_preinvoke and > > _servant_postinvoke (or I should say the information that CANNOT be > > inferred). > > Sorry, I don't understand. Can you explain? What bits would you like to > be able to infer? Please refer to my original message (included below). H * Java reverse mapping local case cannot properly support Portable Interceptors The local mapping makes it impossible to determine which ending point to call. ptc/00-01-06 says: BEGIN_QUOTE 1.5.2.2 Local Stubs The stub class may provide an optimized call path for local server implementation objects. For a method echo(int x) of a remote interface Aardvark, the optimized path does the following: 1. Find out if the servant is local by calling Util.isLocal() 2. If the servant is local, call this._servant_preinvoke("echo",Aardvark.class) 3. If _servant_preinvoke returned a non-null ServantObject so, call ((Aardvark)so.servant).echo(x) 4. If _servant_preinvoke returned a non-null ServantObject so, call this._servant_postinvoke(so) 5. If _servant_preinvoke returned null, repeat step 1. The call to Util.isLocal() will return false, causing the non-optimized path to be followed. ... The following is an example of a stub class that provides this optimized call path. // Java public class _Aardvark_Stub extends javax.rmi.CORBA.Stub implements Aardvark { public int echo(int x) throws java.rmi.RemoteException, Boomerang { if (!javax.rmi.CORBA.Util.isLocal(this)) { ... } else { // local call path org.omg.CORBA.portable.ServantObject so = _servant_preinvoke("echo", Aardvark.class); if (so == null) return echo(x); try { return ((Aardvark)so.servant).echo(x); } catch (Throwable ex) { Throwable ex2 = (Throwable) javax.rmi.CORBA.Util.copyObject(ex, _orb()); if (ex2 instanceof Boomerang) throw (Boomerang)ex2; else throw javax.CORBA.Util.wrapException(ex2); } finally { _servant_postinvoke(so); } } } } END_QUOTE ClientRequestInterceptor::send_request would need to be invoked by the ORB inside _servant_preinvoke. ClientRequestInterceptor::receive_reply or receive_exception would need to be called inside _servant_postinvoke. (Note that receive_other would not happen since, if a POA were involved inside _servant_preinvoke and a servant manager raised ForwardRequest, this should cause _servant_preinvoke to return null resulting in a recursive call to the method. In this case the ORB would not call send_request in the first place, or, if it did, it would handle the call to the receive_other internally inside of _servant_preinvoke.) One is tempted to say that the ORB could remember if javax.rmi.CORBA.Util.copyObject was called on behalf of this request. In that case, when _servant_postinvoke is called it would know there was an exception (and would have it hands on the exception object - which needs to be available via Portable Interceptors). However, this does not work. The example does not show it, but if the method returns values those values are filtered through javax.rmi.CORBA.Util.copyObject before being returned to the client. Exception objects are legal return values. So there is no way to determine if copyObject was called to copy return values or exception objects resulting from an actually exception. Therefore this trick will not work. Bottom line: there is no reliable way to determine which Portable Interceptor ending point to call in the Java reverse mapping local case. ----------------------------------------------------- Date: Wed, 26 Jul 2000 09:30:42 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Bob Kukura , interceptors-ftf@omg.org, java2idl-rtf@omg.org Subject: Re: Issue 3754 - Java reverse mapping local case cannot properlysupportPortable Interceptors References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: +OI!!G+C!!%Q^!!S&&"! Yes, I am just talking about adding something with respect to the Java to IDL (reverse mapping) local optimization case. We should say that interceptors are not invoked in this case. The mapping FTF can remove this restriction when/if the fix it. H Michi Henning wrote: > > On Wed, 26 Jul 2000, Bob Kukura wrote: > > > I'm opposed to saying these kind of calls are not ORB-mediated in the PI > > specification. As far as I can tell, the intent is that ORB services > > behave normally, with location tranparancy, on these co-located calls, > > and we should not change this for ORB services implemented via PI. > > I don't think that was the intent, unless I misunderstood something. > > > > previous mails. Basically say that these kind of > > > optimized calls are not considered ORB-mediated. > > To me, that refers to the broken optimization for Java, not collocated > calls in general. If I misread the intent, then I have to agree with Bob. > > 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, 26 Jul 2000 18:49:53 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Boldt CC: issues@emerald.omg.org, java2idl-rtf@emerald.omg.org, java-rtf@omg.org, Mary Leland Subject: Re: issue 3754 -- Java to IDL RTF issue References: <4.2.0.58.20000724165719.009fec40@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 9$Ge9~UX!!`)2!!:]Zd9 Juergen, This is an IDL to Java mapping issue. Please reassign it to the IDL to Java RTF. Simon Juergen Boldt wrote: > > This is issue # 3754 (Harold Carr ) > > Java reverse mapping local case cannot properly support Portable Interceptors > > The local mapping makes it impossible to determine which ending point > to call. > > ptc/00-01-06 says: > > BEGIN_QUOTE > > 1.5.2.2 Local Stubs > > The stub class may provide an optimized call path for local server > implementation objects. For a method echo(int x) of a remote interface > Aardvark, the optimized path does the following: > > 1. Find out if the servant is local by calling Util.isLocal() > 2. If the servant is local, call > this._servant_preinvoke("echo",Aardvark.class) > 3. If _servant_preinvoke returned a non-null ServantObject so, call > ((Aardvark)so.servant).echo(x) > 4. If _servant_preinvoke returned a non-null ServantObject so, call > this._servant_postinvoke(so) > 5. If _servant_preinvoke returned null, repeat step 1. The call to > Util.isLocal() will return false, causing the non-optimized > path to be followed. > ... > > The following is an example of a stub class that provides this > optimized call path. > > // Java > public class _Aardvark_Stub extends javax.rmi.CORBA.Stub > implements Aardvark > { > public int echo(int x) > throws java.rmi.RemoteException, Boomerang > { > if (!javax.rmi.CORBA.Util.isLocal(this)) { > ... > } else { > // local call path > org.omg.CORBA.portable.ServantObject so = > _servant_preinvoke("echo", Aardvark.class); > if (so == null) > return echo(x); > try { > return ((Aardvark)so.servant).echo(x); > } catch (Throwable ex) { > Throwable ex2 = (Throwable) > javax.rmi.CORBA.Util.copyObject(ex, _orb()); > if (ex2 instanceof Boomerang) > throw (Boomerang)ex2; > else > throw javax.CORBA.Util.wrapException(ex2); > } finally { > _servant_postinvoke(so); > } > } > } > } > > END_QUOTE > > ClientRequestInterceptor::send_request would need to be invoked by the > ORB inside _servant_preinvoke. > > ClientRequestInterceptor::receive_reply or receive_exception would > need to be called inside _servant_postinvoke. > > (Note that receive_other would not happen since, if a POA were > involved inside _servant_preinvoke and a servant manager raised > ForwardRequest, this should cause _servant_preinvoke to return null > resulting in a recursive call to the method. In this case the ORB > would not call send_request in the first place, or, if it did, it > would handle the call to the receive_other internally inside of > _servant_preinvoke.) > > One is tempted to say that the ORB could remember if > javax.rmi.CORBA.Util.copyObject was called on behalf of this request. > In that case, when _servant_postinvoke is called it would know there > was an exception (and would have it hands on the exception object - > which needs to be available via Portable Interceptors). > > However, this does not work. The example does not show it, but if the > method returns values those values are filtered through > javax.rmi.CORBA.Util.copyObject before being returned to the client. > Exception objects are legal return values. So there is no way to > determine if copyObject was called to copy return values or exception > objects resulting from an actually exception. Therefore this trick > will not work. > > Bottom line: there is no reliable way to determine which Portable > Interceptor ending point to call in the Java reverse mapping local > case. > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > > ================================================================ -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Wed, 26 Jul 2000 11:25:17 -0700 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Harold Carr , Michi Henning , Bob Kukura , interceptors-ftf@omg.org, java2idl-rtf@omg.org, java-rtf@omg.org, juergen@omg.org, Mary Leland Subject: Re: Issue 3754 - Java reverse mapping local case cannot properlysupportPortable Interceptors References: <397F1232.1F4E7F3E@sun.com> <397F2514.BF1DF0D1@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 'V[d9h;5e9S3Ce9U9Wd9 Simon - Simon Nash wrote: > BTW, I think the skeleton code is broken as currently specified and should be > fixed (in both language mappings). > > Simon Could you please clarify what you mean here? Cheers, Max Date: Wed, 26 Jul 2000 21:29:55 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: "M. Mortazavi" CC: Harold Carr , Michi Henning , Bob Kukura , interceptors-ftf@omg.org, java2idl-rtf@omg.org, java-rtf@omg.org Subject: Re: Issue 3754 - Java reverse mapping local case cannot properlysupportPortable Interceptors References: <397F1232.1F4E7F3E@sun.com> <397F2514.BF1DF0D1@hursley.ibm.com> <397F2D0C.A2ED9C28@eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: H%6!!DkQ!!l-L!!Qa4e9 Max/Harold, Sorry. I meant stubs, not skeletons. Skeletons aren't used in the locally optimized case. I meant that this problem shows that we have a defect in the spec for the generated STUBS in the locally optimized case. We either need to add a new call after the local method is invoked or add an additional argument to the existing servant_postinvoke call that allows the ORB to distinguish between a normal reply and an exception reply. This would be similar to having both the createReply and createExceptionReply calls in the non-optimized case. For many reasons it is not possible to overload the copyObject(s) calls to attempt to deduce this information. Without this change we don't have remote/local transparency for interceptors. This is why I think the stubs are broken. Simon "M. Mortazavi" wrote: > > Simon - > > Simon Nash wrote: > > > BTW, I think the skeleton code is broken as currently specified and should be > > fixed (in both language mappings). > > > > Simon > > Could you please clarify what you mean here? > > Cheers, > Max -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Wed, 26 Jul 2000 14:11:07 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Simon Nash , "M. Mortazavi" , Michi Henning , Bob Kukura , interceptors-ftf@omg.org, java2idl-rtf@omg.org, java-rtf@omg.org Subject: Re: Issue 3754 - Java reverse mapping local case cannot properlysupportPortable Interceptors References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: d5$"!';Od9"6>e9#E8e9 Yeah, look back through the stack ;-) No portable way that I know of. H Polar Humenn wrote: > > Just a quick question. You can call me stupid. But is there a way for a > servent implementation to tell if the call is one that was locally > optimized? > > -Polar > > On Wed, 26 Jul 2000, Simon Nash wrote: > > > Max/Harold, > > Sorry. I meant stubs, not skeletons. Skeletons aren't used in the locally > > optimized case. > > > > I meant that this problem shows that we have a defect in the spec for the > > generated STUBS in the locally optimized case. We either need to add a new call > > after the local method is invoked or add an additional argument to the existing > > servant_postinvoke call that allows the ORB to distinguish between a normal reply > > and an exception reply. This would be similar to having both the createReply and > > createExceptionReply calls in the non-optimized case. > > > > For many reasons it is not possible to overload the copyObject(s) calls to attempt > > to deduce this information. > > > > Without this change we don't have remote/local transparency for interceptors. > > This is why I think the stubs are broken. > > > > Simon > > > > "M. Mortazavi" wrote: > > > > > > Simon - > > > > > > Simon Nash wrote: > > > > > > > BTW, I think the skeleton code is broken as currently specified and should be > > > > fixed (in both language mappings). > > > > > > > > Simon > > > > > > Could you please clarify what you mean here? > > > > > > Cheers, > > > Max > > > > -- > > Simon C Nash, Technology Architect, IBM Java Technology Centre > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com Date: Wed, 26 Jul 2000 14:50:34 -0700 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Harold Carr , Michi Henning , Bob Kukura , interceptors-ftf@omg.org, java2idl-rtf@omg.org, java-rtf@omg.org Subject: Re: Issue 3754 - Java reverse mapping local case cannot properlysupportPortable Interceptors References: <397F1232.1F4E7F3E@sun.com> <397F2514.BF1DF0D1@hursley.ibm.com> <397F2D0C.A2ED9C28@eng.sun.com> <397F4A42.54D33C6B@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 6<3e9QQVd9;^C!!D"Ke9 Simon - Simon Nash wrote: > Max/Harold, > Sorry. I meant stubs, not skeletons. Skeletons aren't used in the > locally > optimized case. > > I meant that this problem shows that we have a defect in the spec > for the > generated STUBS in the locally optimized case. We either need to > add a new call > after the local method is invoked New call to what? > or add an additional argument to the existing > servant_postinvoke call that allows the ORB to distinguish between a > normal reply > and an exception reply. What would happen to the servant_postinvoke with the old signature? Deprecated? This approach would also require getting servant_postinvoke out of the finally clause. Right? > This would be similar to having both the createReply and > createExceptionReply calls in the non-optimized case. Yes, and thanks for the clarification. M. > > > For many reasons it is not possible to overload the copyObject(s) >calls to attempt > to deduce this information. > > Without this change we don't have remote/local transparency for >interceptors. > This is why I think the stubs are broken. > > Simon > > "M. Mortazavi" wrote: > > > > Simon - > > > > Simon Nash wrote: > > > > > BTW, I think the skeleton code is broken as currently specified >and should be > > > fixed (in both language mappings). > > > > > > Simon > > > > Could you please clarify what you mean here? > > > > Cheers, > > Max > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 27 Jul 2000 11:00:57 +1000 (EST) From: Michi Henning To: Harold Carr cc: interceptors-ftf@omg.org, java2idl-rtf@omg.org Subject: Re: Issue 3754 - Java reverse mapping local case cannot properlysupportPortable Interceptors In-Reply-To: <397F11B8.DE44DCB2@sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: <\7!!o97e95`nd9Hm5!! On Wed, 26 Jul 2000, Harold Carr wrote: > > Sorry, I don't understand. Can you explain? What bits would you like to > > be able to infer? > > Please refer to my original message (included below). Ah, OK, I get it now. Sorry for being slow. > However, this does not work. The example does not show it, but if the > method returns values those values are filtered through > javax.rmi.CORBA.Util.copyObject before being returned to the client. > Exception objects are legal return values. So there is no way to > determine if copyObject was called to copy return values or exception > objects resulting from an actually exception. Therefore this trick > will not work. > > Bottom line: there is no reliable way to determine which Portable > Interceptor ending point to call in the Java reverse mapping local > case. Seems like sound reasoning to me. Looks like the reverse mapping and PI simply don't go together... 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: Jeffrey Mischkinsky Message-Id: <200007270132.SAA11950@wheel.dcn.davis.ca.us> Subject: Re: Issue 3754 - Java reverse mapping local case cannot To: michi@ooc.com.au (Michi Henning) Date: Wed, 26 Jul 2000 18:32:48 -0700 (PDT) Cc: harold.carr@sun.com (Harold Carr), interceptors-ftf@omg.org, java2idl-rtf@omg.org In-Reply-To: from "Michi Henning" at Jul 27, 2000 11:00:57 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Wejd9]mOe9ki]d9YL-!! 'Michi Henning' writes: > > On Wed, 26 Jul 2000, Harold Carr wrote: > > > > Sorry, I don't understand. Can you explain? What bits would you like to > > > be able to infer? > > > > Please refer to my original message (included below). > > Ah, OK, I get it now. Sorry for being slow. > > > However, this does not work. The example does not show it, but if the > > method returns values those values are filtered through > > javax.rmi.CORBA.Util.copyObject before being returned to the client. > > Exception objects are legal return values. So there is no way to > > determine if copyObject was called to copy return values or exception > > objects resulting from an actually exception. Therefore this trick > > will not work. > > > > Bottom line: there is no reliable way to determine which Portable > > Interceptor ending point to call in the Java reverse mapping local > > case. > > Seems like sound reasoning to me. Looks like the reverse mapping and > PI simply don't go together... And hence is a bug in the PI submission which was supposed to make any changes necessary to previously adopted specifications such as language mappings. Sounds like something that should be addressed by the FTF with advice from the Java language mapping folks. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Wed, 26 Jul 2000 21:22:04 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey Mischkinsky CC: Michi Henning , interceptors-ftf@omg.org, java2idl-rtf@omg.org Subject: Re: Issue 3754 - Java reverse mapping local case cannot References: <200007270132.SAA11950@wheel.dcn.davis.ca.us> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: J;\d9:eUd9l9V!!C3Ke9 Jeffrey Mischkinsky wrote: > > 'Michi Henning' writes: > > Seems like sound reasoning to me. Looks like the reverse mapping and > > PI simply don't go together... > > And hence is a bug in the PI submission which was supposed to make any changes > necessary to previously adopted specifications such as language mappings. > Sounds like something that should be addressed by the FTF with advice > from the Java language mapping folks. Well, we have one week to do it. Also, I do not see any way to solve it and maintain backward compatibility - stubs would need to be recompiled to work with PI. If we do not solve it in the next week (and I do not think one week is enough time) can this be addressed in the PI RTF that I assume will immediately be chartered when the FTF closes? Cheers, Harold Date: Thu, 27 Jul 2000 14:27:14 +1000 (EST) From: Michi Henning To: Harold Carr cc: Jeffrey Mischkinsky , interceptors-ftf@omg.org, java2idl-rtf@omg.org Subject: Re: Issue 3754 - Java reverse mapping local case cannot In-Reply-To: <397FB8EC.97705865@sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: &;&"! Well, we have one week to do it. Also, I do not see any way to solve it > and maintain backward compatibility - stubs would need to be recompiled > to work with PI. If we do not solve it in the next week (and I do not > think one week is enough time) can this be addressed in the PI RTF that > I assume will immediately be chartered when the FTF closes? Provided that you (or someone) puts up a proposal to charter an RTF. To do that, I think we need to make the three-week deadline to get it on the agenda? (Jeff?) 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