Issue 4429: Issue with using the local stub with for example an EJB application (java2idl-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Critical Summary: When using the local stub with for example an EJB application, we discovered the following critical issue. Let's take an simple example : public interface HelloWorld extends javax.rmi.EJBObject { void print( String message ); } The generated Stub according to the mapping rules contains the methods for the inherited interface as for example 'getEJBHome'. For a local invocation on 'getEJBHome' the following part of the stub will be used : public javax.ejb.EJBHome getEJBHome() throws java.rmi.RemoteException { while( true ) { if (!javax.rmi.CORBA.Util.isLocal(this) ) { // non local use } else { org.omg.CORBA.portable.ServantObject _so = _servant_preinvoke("EJBHome", HelloWorld.class); if ( _so == null ) return getEJBHome(); try {return ((javax.ejb.EJBObject)_so.servant).getEJBHome(); } catch ( Throwable ex ) { Throwable ex2 = ( Throwable ) javax.rmi.CORBA.Util.copyObject(ex, _orb()); throw javax.rmi.CORBA.Util.wrapException(ex2); } finally {_servant_postinvoke(_so); } } } } The '_servant_preinvoke' method will return a servant class of type 'HelloWorld' that implements the 'getEJBHome' operation. Thus, the '_HelloWorld_Tie' servant is returned. Then, the cast to convert the returned servant to 'javax.ejb.EJBObject' will fail since the servant doesn't implement this interface ( it only inherits from org.omg.PortableServer.Servant and implements javax.rmi.CORBA.Tie ). Thus, by using the local stub, it is not possible to invoke an inherited operation. Solution : The returned servant is always implementing 'javax.rmi.CORBA.Tie'. To allow the correct cast to 'javax.ejb.EJBObject' we need to access the final target instead of the servant itself. So the following solution can be always applied : javax.rmi.CORBA.Tie tie = ((javax.rmi.CORBA.Tie)_so.servant); return ((javax.ejb.EJBObject)tie.getTarget()).getEJBHome(); Resolution: Closed, accepted. See revised text below. Revised Text: section 1.5.2.2, replace the first paragraph after the numbered list by the following: The _servant_preinvoke method returns non-null if, and only if, an optimized local call may be used. It performs any security checking that may be necessary. If the _servant_preinvoke method returns non-null, then the servant field of the returned ServantObject must contain an object that implements the RMI/IDL remote interface and can be used to call the servant implementation. Actions taken: July 25, 2001: received issue May 13, 2002: closed issue Discussion: End of Annotations:===== From: webmaster@omg.org Message-Id: <200107251848.f6PImst15101@emerald.omg.org> Date: 25 Jul 2001 14:50:30 -0400 To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Issue/Bug Report Content-Type: Text/html; charset=windows-1252 X-UIDL: CEkd98cH!!Ch^d9E)*e9 Name: Jerome DANIEL Company: Intalio mailFrom: jdaniel@intalio.com Notification: Yes Specification: Java Language to IDL Mapping Section: 1.5.2.2 FormalNumber: 01-06-07 Version: 1.1 RevisionDate: June 2001 Page: 1-49 Nature: Revision Severity: Critical HTTP User Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) Description When using the local stub with for example an EJB application, we discovered the following critical issue. Let's take an simple example : public interface HelloWorld extends javax.rmi.EJBObject { void print( String message ); } The generated Stub according to the mapping rules contains the methods for the inherited interface as for example 'getEJBHome'. For a local invocation on 'getEJBHome' the following part of the stub will be used : public javax.ejb.EJBHome getEJBHome() throws java.rmi.RemoteException { while( true ) { if (!javax.rmi.CORBA.Util.isLocal(this) ) { // non local use } else { org.omg.CORBA.portable.ServantObject _so = _servant_preinvoke("EJBHome", HelloWorld.class); if ( _so == null ) return getEJBHome(); try {return ((javax.ejb.EJBObject)_so.servant).getEJBHome(); } catch ( Throwable ex ) { Throwable ex2 = ( Throwable ) javax.rmi.CORBA.Util.copyObject(ex, _orb()); throw javax.rmi.CORBA.Util.wrapException(ex2); } finally {_servant_postinvoke(_so); } } } } The '_servant_preinvoke' method will return a servant class of type 'HelloWorld' that implements the 'getEJBHome' operation. Thus, the '_HelloWorld_Tie' servant is returned. Then, the cast to convert the returned servant to 'javax.ejb.EJBObject' will fail since the servant doesn't implement this interface ( it only inherits from org.omg.PortableServer.Servant and implements javax.rmi.CORBA.Tie ). Thus, by using the local stub, it is not possible to invoke an inherited operation. Solution : The returned servant is always implementing 'javax.rmi.CORBA.Tie'. To allow the correct cast to 'javax.ejb.EJBObject' we need to access the final target instead of the servant itself. So the following solution can be always applied : javax.rmi.CORBA.Tie tie = ((javax.rmi.CORBA.Tie)_so.servant); return ((javax.ejb.EJBObject)tie.getTarget()).getEJBHome(); Importance: Normal Subject: Re: issue 4429 -- Java to IDL RTF issue To: jdaniel@intalio.com Cc: Juergen Boldt , issues@emerald.omg.org, java2idl-rtf@emerald.omg.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ann Dalton1" Date: Thu, 26 Jul 2001 10:31:12 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.6 |December 14, 2000) at 26/07/2001 10:29:38 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: M"O!!#_K!!"h"e9[]]d9 Jerome, Could you please help me with the statements > The '_servant_preinvoke' method will return a servant class of type > 'HelloWorld' that implements the 'getEJBHome' operation. and > Thus, the '_HelloWorld_Tie' servant is returned. I would have expected servant_peinvoke to return a ServantObject containing the actual servant, the target if you like, rather than the Tie. Thanks, Ann A E Dalton Java Technology Centre MP 146, IBM UK Labs, Hursley Park, Winchester, Hants. SO21 2JN Tel: UK-1962-816791 Fax: UK-1962-815388 ann_dalton@uk.ibm.com Juergen Boldt on 25/07/2001 21:30:33 Please respond to Juergen Boldt To: issues@emerald.omg.org, java2idl-rtf@emerald.omg.org cc: Subject: issue 4429 -- Java to IDL RTF issue This is issue# 4429 Jerome DANIEL jdaniel@intalio.com Issue with using the local stub with for example an EJB application When using the local stub with for example an EJB application, we discovered the following critical issue. Let's take an simple example : public interface HelloWorld extends javax.rmi.EJBObject { void print( String message ); } The generated Stub according to the mapping rules contains the methods for the inherited interface as for example 'getEJBHome'. For a local invocation on 'getEJBHome' the following part of the stub will be used : public javax.ejb.EJBHome getEJBHome() throws java.rmi.RemoteException { while( true ) { if (!javax.rmi.CORBA.Util.isLocal(this) ) { // non local use } else { org.omg.CORBA.portable.ServantObject _so = _servant_preinvoke ("EJBHome", HelloWorld.class); if ( _so == null ) return getEJBHome(); try { return ((javax.ejb.EJBObject)_so.servant).getEJBHome(); } catch ( Throwable ex ) { Throwable ex2 = ( Throwable )javax.rmi.CORBA.Util.copyObject(ex, _orb()); throw javax.rmi.CORBA.Util.wrapException(ex2); } finally { _servant_postinvoke(_so); } } } } The '_servant_preinvoke' method will return a servant class of type 'HelloWorld' that implements the 'getEJBHome' operation. Thus, the '_HelloWorld_Tie' servant is returned. Then, the cast to convert the returned servant to 'javax.ejb.EJBObject' will fail since the servant doesn't implement this interface ( it only inherits from org.omg.PortableServer.Servant and implements javax.rmi.CORBA.Tie ). Thus, by using the local stub, it is not possible to invoke an inherited operation. Solution : The returned servant is always implementing 'javax.rmi.CORBA.Tie'. To allow the correct cast to 'javax.ejb.EJBObject' we need to access the final target instead of the servant itself. So the following solution can be always applied : javax.rmi.CORBA.Tie tie = ((javax.rmi.CORBA.Tie)_so.servant); return ((javax.ejb.EJBObject)tie.getTarget()).getEJBHome(); ================================================================ 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 URL: www.omg.org ================================================================ Date: Thu, 26 Jul 2001 11:37:26 -0700 From: Vijaykumar Natarajan Subject: Re: issue 4429 -- Java to IDL RTF issue To: Ann Dalton1 Cc: jdaniel@intalio.com, Juergen Boldt , issues@emerald.omg.org, java2idl-rtf@emerald.omg.org Message-id: <3B606366.F54A119@inprise.com> Organization: Borland Software Corporation MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: Content-Type: multipart/mixed; boundary="Boundary_(ID_Kkhq5CTAU+1tE9sB5NQuDw)" X-UIDL: iH@!!cT(!!i1R!!MOHe9 Ann, Ann Dalton1 wrote: > Jerome, > > Could you please help me with the statements > > The '_servant_preinvoke' method will return a servant class of >type > > 'HelloWorld' that implements the 'getEJBHome' operation. > and > > Thus, the '_HelloWorld_Tie' servant is returned. > > I would have expected servant_peinvoke to return a ServantObject > containing the actual servant, the target if you like, rather than > the Tie. I agree that's incorrect in the example. However, the servant contained in the ServantObject is still a tie, and as per the "non-normative" example in the specification, the Tie extends only the org.omg.PortableServer.Servant and implements javax.rmi.CORBA.Tie, and never HelloWorld or EJBObject, so local invocations will fail exactly as Jerome indicates. By following standard mapping, I would have expected _HelloWorld_Tie to extend HelloWorldOperations, but the spec is unclear on this. Vijay > > > Thanks, > Ann > A E Dalton > Java Technology Centre > MP 146, IBM UK Labs, Hursley Park, Winchester, Hants. SO21 2JN > Tel: UK-1962-816791 Fax: UK-1962-815388 > ann_dalton@uk.ibm.com > > Juergen Boldt on 25/07/2001 21:30:33 > > Please respond to Juergen Boldt > > To: issues@emerald.omg.org, java2idl-rtf@emerald.omg.org > cc: > Subject: issue 4429 -- Java to IDL RTF issue > > This is issue# 4429 Jerome DANIEL jdaniel@intalio.com > > Issue with using the local stub with for example an EJB application > > When using the local stub with for example an EJB application, we > discovered the following critical issue. > > Let's take an simple example : > > public interface HelloWorld extends javax.rmi.EJBObject { > void print( String message ); > } > > The generated Stub according to the mapping rules contains the >methods for > the inherited interface as for example 'getEJBHome'. > > For a local invocation on 'getEJBHome' the following part of the >stub will > be used : > > public javax.ejb.EJBHome getEJBHome() throws >java.rmi.RemoteException { > while( true ) { > if (!javax.rmi.CORBA.Util.isLocal(this) ) { > // non local use > } > else { > org.omg.CORBA.portable.ServantObject _so = >_servant_preinvoke > ("EJBHome", HelloWorld.class); > > if ( _so == null ) > return getEJBHome(); > > try { > return >((javax.ejb.EJBObject)_so.servant).getEJBHome(); > } catch ( Throwable ex ) { > Throwable ex2 = ( Throwable > )javax.rmi.CORBA.Util.copyObject(ex, _orb()); > > throw javax.rmi.CORBA.Util.wrapException(ex2); > } finally { > _servant_postinvoke(_so); > } > } > } > } > > The '_servant_preinvoke' method will return a servant class of type > 'HelloWorld' that implements the 'getEJBHome' operation. > > Thus, the '_HelloWorld_Tie' servant is returned. > > Then, the cast to convert the returned servant to >'javax.ejb.EJBObject' > will fail since the servant doesn't implement this interface ( it >only > inherits from org.omg.PortableServer.Servant and implements > javax.rmi.CORBA.Tie ). > > Thus, by using the local stub, it is not possible to invoke an >inherited > operation. > > Solution : > > The returned servant is always implementing >'javax.rmi.CORBA.Tie'. To allow > > the correct cast to 'javax.ejb.EJBObject' we need to access the >final > target instead of the servant itself. So the following solution can >be > always applied : > > javax.rmi.CORBA.Tie tie = ((javax.rmi.CORBA.Tie)_so.servant); > > return ((javax.ejb.EJBObject)tie.getTarget()).getEJBHome(); > > ================================================================ > > 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 > URL: > www.omg.org > > ================================================================ -- ------- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. [] vnatarajan1.vcf From: "Jerome DANIEL" To: "Ann Dalton1" Cc: "Juergen Boldt" , , Subject: RE: issue 4429 -- Java to IDL RTF issue Date: Thu, 26 Jul 2001 11:46:53 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Content-Type: text/plain; charset="us-ascii" X-UIDL: YOL!!Hk*e9+@ Could you please help me with the statements > > The '_servant_preinvoke' method will return a servant class of type > > 'HelloWorld' that implements the 'getEJBHome' operation. > and > > Thus, the '_HelloWorld_Tie' servant is returned. > > I would have expected servant_peinvoke to return a ServantObject > containing the actual servant, the target if you like, rather than > the Tie. > In that case, the behavior of the _servant_preinvoke method must be clarified since the IDL to Java specification says ( page 135 ) : <<<<< The _servant_preinvoke() method is invoked by a local stub to obtain a Java reference to the servant that should be used for this request. The method takes a string containing the operation name and a Class object representing the expected type of the servant as parameters and returns a ServantObject object. <<<<< So, a servant is returned ( the tie object ) and not the final obj. I understand your argument but it means that we use two times the same method ( _servant_preinvoke ) with two different behaviors : for IDL to Java : returns the servnt for Java to IDL : returns the target ( i.e. the RMI object implementation ). I don't think that the TIE object has to implement the operation interface because in that case the TIE class would have to overload each operation defined in the operation interface. Jerome. Date: Thu, 26 Jul 2001 12:45:42 -0700 From: Vijaykumar Natarajan Subject: Re: issue 4429 -- Java to IDL RTF issue To: Jerome DANIEL Cc: Ann Dalton1 , Juergen Boldt , issues@emerald.omg.org, java2idl-rtf@emerald.omg.org Message-id: <3B607366.88C5C8EA@inprise.com> Organization: Borland Software Corporation MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: Content-Type: multipart/mixed; boundary="Boundary_(ID_mFzx0u21IJMj25+oaOZPVA)" X-UIDL: 5m[!!'J^d9@"Y!!/VVd9 Hi Jerome, Jerome DANIEL wrote: > Ann, > > > Could you please help me with the statements > > > The '_servant_preinvoke' method will return a servant class of >type > > > 'HelloWorld' that implements the 'getEJBHome' operation. > > and > > > Thus, the '_HelloWorld_Tie' servant is returned. > > > > I would have expected servant_peinvoke to return a ServantObject > > containing the actual servant, the target if you like, rather than > > the Tie. > > > > In that case, the behavior of the _servant_preinvoke method must be > clarified since the IDL to Java specification says ( page 135 ) : > > <<<<< > > The _servant_preinvoke() method is invoked by a local stub to obtain >a Java > reference to the servant that should be used for this request. The >method > takes a string > containing the operation name and a Class object representing the >expected > type of the > servant as parameters and returns a ServantObject object. > > <<<<< > > So, a servant is returned ( the tie object ) and not the final >obj. I > understand your argument but it means that we use two times the same >method > ( _servant_preinvoke ) with two different behaviors : > > for IDL to Java : returns the servnt > > for Java to IDL : returns the target ( i.e. the RMI object >implementation ). > > I don't think that the TIE object has to implement the operation >interface > because in that case the TIE class would have to overload each >operation > defined in the operation interface. > > Jerome. I disagree. In both cases, what is returned is a ServantObject class which holds a handle to the Servant. I don't see where in the Java-2-idl case, the spec says that it should return the target. In fact, in 1.5.2.2 of the java2idl spec, the example stub class does receive a ServantObject and the resultant servant is extracted and an invocation is made. The problem I see is that this part of the spec assumes the servant (which in this case will be the Tie) extends the remote interface and the description of Ties does not indicate the same. I actually think that is incorrect as well. The servant should not extend the remote interface as that will prevent us from distinguishing between a servant and an implementation that needs exporting. I believe the right answer is to follow the IDL - Java mapping w/ says that the Servant extends an Operations class which implements all the methods of the remote interface. Vijay -- ------- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. [] vnatarajan3.vcf Date: Fri, 27 Jul 2001 09:28:25 +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: Vijaykumar Natarajan CC: Jerome DANIEL , Ann Dalton1 , java2idl-rtf@emerald.omg.org Subject: Re: issue 4429 -- Java to IDL RTF issue References: <3B607366.88C5C8EA@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: BHP!!A1#e9>05e90Eg!! Vijay, Vijaykumar Natarajan wrote: > > Hi Jerome, > > Jerome DANIEL wrote: > > > Ann, > > > > > Could you please help me with the statements > > > > The '_servant_preinvoke' method will return a servant class of type > > > > 'HelloWorld' that implements the 'getEJBHome' operation. > > > and > > > > Thus, the '_HelloWorld_Tie' servant is returned. > > > > > > I would have expected servant_peinvoke to return a ServantObject > > > containing the actual servant, the target if you like, rather than > > > the Tie. > > > > > > > In that case, the behavior of the _servant_preinvoke method must be > > clarified since the IDL to Java specification says ( page 135 ) : > > > > <<<<< > > > > The _servant_preinvoke() method is invoked by a local stub to obtain a Java > > reference to the servant that should be used for this request. The method > > takes a string > > containing the operation name and a Class object representing the expected > > type of the > > servant as parameters and returns a ServantObject object. > > > > <<<<< > > > > So, a servant is returned ( the tie object ) and not the final obj. I > > understand your argument but it means that we use two times the same method > > ( _servant_preinvoke ) with two different behaviors : > > > > for IDL to Java : returns the servnt > > > > for Java to IDL : returns the target ( i.e. the RMI object implementation ). > > > > I don't think that the TIE object has to implement the operation interface > > because in that case the TIE class would have to overload each operation > > defined in the operation interface. > > > > Jerome. > > I disagree. In both cases, what is returned is a ServantObject class which holds > a handle to the Servant. > > I don't see where in the Java-2-idl case, the spec says that it should return > the target. In fact, in 1.5.2.2 of the java2idl spec, the example stub class > does receive a ServantObject and the resultant servant is extracted and an > invocation is made. > This can only work if the ServantObject contains the target, since the Tie is not required to implement the target's remote methods. > The problem I see is that this part of the spec assumes the servant (which in > this case will be the Tie) extends the remote interface and the description of > Ties does not indicate the same. I actually think that is incorrect as well. The > servant should not extend the remote interface as that will prevent us from > distinguishing between a servant and an implementation that needs exporting. I > believe the right answer is to follow the IDL - Java mapping w/ says that the > Servant extends an Operations class which implements all the methods of the > remote interface. > I don't think the Tie should be involved in these local invocations. The extra delegation call via the Tie adds overhead and I can't see any good reason for imposing this overhead. Also, the generated code in the Ties would be larger because of all the delegation methods that would need to be generated for every class in the hierarchy. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from mail.brokat.de (212.9.175.131) by hobbit.omg.org asmtp(1.1.1) id 23421; Thu, 11 Oct 2001 09:44:18 -0400 (EDT) Received: by mail.brokat.de (Smail3.2.0.111/mail.brokat.de) via LF.net GmbH Internet Services via remoteip 172.17.24.197 via remotehost pcmrumpf with smtp for hobbit.omg.org id m15rfvE-001mbtC; Thu, 11 Oct 2001 15:30:48 +0200 (CEST) Message-ID: <005e01c15258$e3dfcfe0$c51811ac@brokat.de> From: "Michael Rumpf" To: Cc: "Jerome DANIEL" , , , , , Subject: Issue 4429 (Java to IDL Mapping) Date: Thu, 11 Oct 2001 15:30:20 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: b/\!!d$Qe9P,;!!&MSd9 Sorry for including you all on the list of recipients, but the Issue archive indicates your interest on the topic. I stumbled over the same problem which has been reported by Jerome Daniels as an issue a few months ago: http://cgi.omg.org/issues/issue4429.txt. The discussion on the issue seems to got stuck and I would like to resolve it... Problem summary: ---------------------------------------- public class _MyItf_Tie extends org.omg.PortableServer.Servant // no further base classes implements javax.rmi.CORBA.Tie // derived from InvokeHandler { public void hello(); } The Tie does not have the interface MyItf in its derivation graph, instead the interface is stored in the target member of the class and can be accessed by the methods get/setTarget(). The Java to IDL Mapping spec. provides code snippets for local invocation optimizations on 1-49 (01-06-07.pdf, 1.5.2.2 Local Stubs) or on 1-47 (99-07-59.pdf, 1.5.2.2 Local Stubs). Point number three seems to provide a wrong cast: "3. If _servant_preinvoke returned a non-null ServantObject so, call ((Aardvark)so.servant).echo(x)" The ORB's _servant_preinvoke() method returns an object of type ServantObject: public class ServantObject { public java.lang.Object servant; } The servant member of ServantObject actually stores Tie objects because the Tie's base class org.omg.PortableServer.Servant qualifies a Tie as servant. But in this case the cast: ((MyItf)so.servant).hello(); will fail with a ClassCastException ! You could argue that the type of the servant member in ServantObject is not org.omg.PortableServer.Servant but java.lang.Object so that it could hold any type, even the interface, is correct, but.... In this case you would have to add some code to check for instances of type javax.rmi.CORBA.Tie into the ORB's code. Especially into POA.servant_preinvoke. This means that you add RMIoverIIOP code into your ORB. I think that this is a bad style. E.g. OpenORB's RMIoverIIOP module is developed as an extension that can be plugged under the ORB in a totally transparent way (and I guess that is one of the retionale behind the RMIoverIIOP spec. in general). So mixing up the ORB's code with RMIoverIIOP stuff should be a non-issue... I can think of two possible solutions then: 1. Jerome's proposition by changing the code to get the target object from the Tie: ((MyItf)((_MyItf_Tie)_so.servant).getTarget()).hello(); 2. Add a _servant_preinvoke method to the abstract Stub class (javax.rmi.CORBA.Stub) so that preinvoke can return the target as the servant member of the ServantObject instead of the Tie. public ServantObject _servant_preinvoke(String operation, Class expectedType) { ServantObject so = super._get_delegate().servant_preinvoke(this, operation,expectedType); so.servant = (java.lang.Object)((javax.rmi.CORBA.Tie)so.servant).getTarget(); return so; } In my eyes one of the two solutions would be the cleanest way to go. I didn' try the second one but I don't think there are any other implications. The first one looks even better because no interface change for javax.rmi.CORBA.Stub is necessary. And by the way that is the one I implemented as a workaround for OpenORB's RMIoverIIOP module and it works perfectly ;-) Regards, Michael Rumpf PS: I'm not an OMG member so I'm not sure whether this mail reaches the RTF mailing-list. If not could someone please forward it there... Date: Sun, 14 Oct 2001 18:55:00 +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: Michael Rumpf CC: Jerome DANIEL , ann_dalton@uk.ibm.com, vnatarajan@borland.com, java2idl-rtf@omg.org Subject: Re: Issue 4429 (Java to IDL Mapping) References: <005e01c15258$e3dfcfe0$c51811ac@brokat.de> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: /-(e9G1%!!jI > Sorry for including you all on the list of recipients, but the Issue archive > indicates your interest on the topic. > > I stumbled over the same problem which has been reported by Jerome Daniels > as an issue a few months ago: http://cgi.omg.org/issues/issue4429.txt. The > discussion on the issue seems to got stuck and I would like to resolve it... > > Problem summary: > ---------------------------------------- > > public class _MyItf_Tie > extends org.omg.PortableServer.Servant // no further base classes > implements javax.rmi.CORBA.Tie // derived from InvokeHandler > { > public void hello(); > } > > The Tie does not have the interface MyItf in its derivation graph, instead > the interface is stored in the target member of the class and can be > accessed by the methods get/setTarget(). > > The Java to IDL Mapping spec. provides code snippets for local invocation > optimizations on 1-49 (01-06-07.pdf, 1.5.2.2 Local Stubs) or on 1-47 > (99-07-59.pdf, 1.5.2.2 Local Stubs). Point number three seems to provide a > wrong cast: > > "3. If _servant_preinvoke returned a non-null ServantObject so, call > ((Aardvark)so.servant).echo(x)" > > The ORB's _servant_preinvoke() method returns an object of type > ServantObject: > > public class ServantObject { > public java.lang.Object servant; > } > > The servant member of ServantObject actually stores Tie objects because the > Tie's base class org.omg.PortableServer.Servant qualifies a Tie as servant. > But in this case the cast: > > ((MyItf)so.servant).hello(); > > will fail with a ClassCastException ! > > You could argue that the type of the servant member in ServantObject is not > org.omg.PortableServer.Servant but java.lang.Object so that it could hold > any type, even the interface, is correct, but.... > > In this case you would have to add some code to check for instances of type > javax.rmi.CORBA.Tie into the ORB's code. Especially into > POA.servant_preinvoke. This means that you add RMIoverIIOP code into your > ORB. I think that this is a bad style. E.g. OpenORB's RMIoverIIOP module is > developed as an extension that can be plugged under the ORB in a totally > transparent way (and I guess that is one of the retionale behind the > RMIoverIIOP spec. in general). So mixing up the ORB's code with RMIoverIIOP > stuff should be a non-issue... > > I can think of two possible solutions then: > > 1. Jerome's proposition by changing the code to get the target object from > the Tie: > > ((MyItf)((_MyItf_Tie)_so.servant).getTarget()).hello(); > > 2. Add a _servant_preinvoke method to the abstract Stub class > (javax.rmi.CORBA.Stub) so that preinvoke can return the target as the > servant > member of the ServantObject instead of the Tie. > > public ServantObject _servant_preinvoke(String operation, > Class expectedType) { > ServantObject so = super._get_delegate().servant_preinvoke(this, > operation,expectedType); > so.servant = > (java.lang.Object)((javax.rmi.CORBA.Tie)so.servant).getTarget(); > return so; > } > > In my eyes one of the two solutions would be the cleanest way to go. I didn' > try the second one but I don't think there are any other implications. The > first one looks even better because no interface change for > javax.rmi.CORBA.Stub is necessary. And by the way that is the one I > implemented as a workaround for OpenORB's RMIoverIIOP module and it works > perfectly ;-) > > Regards, > Michael Rumpf > > PS: I'm not an OMG member so I'm not sure whether this mail reaches the RTF > mailing-list. If not could someone please forward it there... -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: "Michael Rumpf" To: "Simon Nash" Cc: "Jerome DANIEL" , , , References: <005e01c15258$e3dfcfe0$c51811ac@brokat.de> <3BC9D174.A1AA6A6F@hursley.ibm.com> Subject: Re: Issue 4429 (Java to IDL Mapping) Date: Mon, 15 Oct 2001 12:07:44 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: =p#e9Bj]d92g1e9U:Be9 OK, if RMI-IIOP is a mandatory part of CORBA 2.3+ compliant Java ORBs then my objections having RMI code mixed up with the ORB's code are invalid. I was just thinking that it would be a great idea not to introduce any dependency from the ORB to RMI-IIOP. I'm fine with your modified version of the second solution, I just have to make a change in OpenORB again ;-). For me, please go ahead to make sure this is getting integrated into the spec... Michael ----- Original Message ----- From: "Simon Nash" To: "Michael Rumpf" Cc: "Jerome DANIEL" ; ; ; Sent: Sonntag, 14. Oktober 2001 19:55 Subject: Re: Issue 4429 (Java to IDL Mapping) > Michael, > Thanks for sending this. At present it seems that ORBs have solved > this > problem in one of two ways: > a. servant_preinvoke() returns an RMI-IIOP implementation instead > of an > RMI-IIOP tie. > b. servant_preinvoke() returns an RMI-IIOP tie, but this tie > implements > the remote interface (MyItf in your example) and contains code > to delegate > method calls made through this interface to the implementation. > > I think both of these are valid approaches that should continue to > be allowed. > The first is more efficient, but requires the ORB to have knowledge > of RMI-IIOP > so that it can treat RMI-IIOP Ties as servants specially. I'm not > quite sure > why you think this is a bad idea. RMI-IIOP is a mandatory part of > CORBA 2.3 > and above and all Java ORBs must support it in order to be CORBA-compliant. > However, I'm open to finding an alternative solution that avoids the > need > for putting this special case in the ORB. > > Changing the generated stub code (your option 1) is problematical > because it > means that for ORBs that currently use approach a above, old stubs > won't work > with the new runtime or vice versa. This is a major issue for > customers who > have a large number of applications already deployed (including > generated stub > code) and aren't able to upgrade their runtime as well as all their deployed > applications at the same time. > > Your option 2 is a clever idea that leaves the stubs unchanged. I'd > like to > propose a minor change to your code for compatibility with ORBs that currently > use approach a above. Here's my modified version: > public ServantObject _servant_preinvoke(String operation, Class expectedType) { > ServantObject so = super._servant_preinvoke(this, operation, expectedType); > if (so.servant instanceof javax.rmi.CORBA.Tie) > so.servant = > ((javax.rmi.CORBA.Tie)so.servant).getTarget(); > return so; > } > This works no matter whether the ORB returns the Tie or the > implementation object. > > I think this is the best solution. It is compatible with existing > stubs and > existing ORBs (no matter which approach they have adopted) and > solves the problem > of ORBs being unable to return the CORBA servant (RMI-IIOP tie) > within the > ServantObject. > > If there are no objections to this solution, I will write up a > formal proposal > for voting. > > Simon > > Michael Rumpf wrote: > > > > Sorry for including you all on the list of recipients, but the > Issue archive > > indicates your interest on the topic. > > > > I stumbled over the same problem which has been reported by Jerome Daniels > > as an issue a few months ago: > http://cgi.omg.org/issues/issue4429.txt. The > > discussion on the issue seems to got stuck and I would like to > resolve it... > > > > Problem summary: > > ---------------------------------------- > > > > public class _MyItf_Tie > > extends org.omg.PortableServer.Servant // no further base > classes > > implements javax.rmi.CORBA.Tie // derived from InvokeHandler > > { > > public void hello(); > > } > > > > The Tie does not have the interface MyItf in its derivation graph, instead > > the interface is stored in the target member of the class and can > be > > accessed by the methods get/setTarget(). > > > > The Java to IDL Mapping spec. provides code snippets for local invocation > > optimizations on 1-49 (01-06-07.pdf, 1.5.2.2 Local Stubs) or on > 1-47 > > (99-07-59.pdf, 1.5.2.2 Local Stubs). Point number three seems to > provide a > > wrong cast: > > > > "3. If _servant_preinvoke returned a non-null ServantObject so, > call > > ((Aardvark)so.servant).echo(x)" > > > > The ORB's _servant_preinvoke() method returns an object of type > > ServantObject: > > > > public class ServantObject { > > public java.lang.Object servant; > > } > > > > The servant member of ServantObject actually stores Tie objects > because the > > Tie's base class org.omg.PortableServer.Servant qualifies a Tie as servant. > > But in this case the cast: > > > > ((MyItf)so.servant).hello(); > > > > will fail with a ClassCastException ! > > > > You could argue that the type of the servant member in > ServantObject is not > > org.omg.PortableServer.Servant but java.lang.Object so that it > could hold > > any type, even the interface, is correct, but.... > > > > In this case you would have to add some code to check for > instances of type > > javax.rmi.CORBA.Tie into the ORB's code. Especially into > > POA.servant_preinvoke. This means that you add RMIoverIIOP code > into your > > ORB. I think that this is a bad style. E.g. OpenORB's RMIoverIIOP > module is > > developed as an extension that can be plugged under the ORB in a totally > > transparent way (and I guess that is one of the retionale behind > the > > RMIoverIIOP spec. in general). So mixing up the ORB's code with RMIoverIIOP > > stuff should be a non-issue... > > > > I can think of two possible solutions then: > > > > 1. Jerome's proposition by changing the code to get the target > object from > > the Tie: > > > > ((MyItf)((_MyItf_Tie)_so.servant).getTarget()).hello(); > > > > 2. Add a _servant_preinvoke method to the abstract Stub class > > (javax.rmi.CORBA.Stub) so that preinvoke can return the target > as the > > servant > > member of the ServantObject instead of the Tie. > > > > public ServantObject _servant_preinvoke(String operation, > > Class expectedType) { > > ServantObject so = super._get_delegate().servant_preinvoke(this, > > operation,expectedType); > > so.servant = > > (java.lang.Object)((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > return so; > > } > > > > In my eyes one of the two solutions would be the cleanest way to > go. I didn' > > try the second one but I don't think there are any other > implications. The > > first one looks even better because no interface change for > > javax.rmi.CORBA.Stub is necessary. And by the way that is the one > I > > implemented as a workaround for OpenORB's RMIoverIIOP module and > it works > > perfectly ;-) > > > > Regards, > > Michael Rumpf > > > > PS: I'm not an OMG member so I'm not sure whether this mail > reaches the RTF > > mailing-list. If not could someone please forward it there... > > -- > Simon C Nash, Chief Technical Officer, IBM Java Technology > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > From: "Michael Rumpf" To: "Simon Nash" Cc: "Jerome DANIEL" , , , References: <005e01c15258$e3dfcfe0$c51811ac@brokat.de> <3BC9D174.A1AA6A6F@hursley.ibm.com> <01da01c15583$524847f0$c51811ac@brokat.de> <3BCB1772.8E5D72B3@hursley.ibm.com> Subject: Re: Issue 4429 (Java to IDL Mapping) Date: Tue, 16 Oct 2001 09:05:48 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: O"De9h,!e9QLU!!*)(e9 Hi Simon, I just found out that OpenORB uses a servant_preinvoke() method internally to handle both cases, local and remote. In order to make the proposal for Issue4429 work I had to change the behaviour a little bit, but this is all OpenORB internal and should not affect the latest suggestion. But I found two other possibilities which could be worth thinking of: 1. Add a servant_preinvoke method to the interface javax.rmi.CORBA.Stub. The implementation knows that the return value is for RMI-IIOP only and calls getTarget() on the Tie object returned by the ORB's servant_preinvoke. The problem I see with this approach is that the Stub class/interface is part of the JDK and it will be hard to guarantee that the correct version of the class is loaded by the classloader. 2. Create the servant_preinvoke method above into the generated stub to avoid changing JDK classes/interfaces. The problem with this approach is that the stubs need to be regenerated. Michael ----- Original Message ----- From: "Simon Nash" To: "Michael Rumpf" Sent: Montag, 15. Oktober 2001 19:05 Subject: Re: Issue 4429 (Java to IDL Mapping) > Michael, > The servant_preinvoke() call is only intended to be called for > locally optimized > invocations. I don't understand how it could return a servant for a non-local > call, since in this case the servant will be in some other process > or machine. > > Simon > > Michael Rumpf wrote: > > > > FYI, problem with the discussed solution to Issue4429 ! > > > > I just noticed that servant_preinvoke() is called also for the > non-local > > case. In the non-local case the return ServantObject must contain > a Servant > > and not the implementation of an interface. > > > > I'm currently not sure whether this is an implementation detail of OpenORB > > or whether it is common bevaviour. If the latter is the case then > our > > solution must check whether the call was a locally optimized call > and we > > must invoke getTarget() only in this case... Some signs point into > the > > direction that the call to preinvoke for remote requests is a > special > > behaviour of OpenORB, the JavaDoc comment is "Preinvoke a local operation. A > > successfull call is always paired with a call to > servant_postinvoke." > > > > Michael > > > > ----- Original Message ----- > > From: "Simon Nash" > > To: "Michael Rumpf" > > Cc: "Jerome DANIEL" ; > ; > > ; > > Sent: Sonntag, 14. Oktober 2001 19:55 > > Subject: Re: Issue 4429 (Java to IDL Mapping) > > > > > Michael, > > > Thanks for sending this. At present it seems that ORBs have > solved this > > > problem in one of two ways: > > > a. servant_preinvoke() returns an RMI-IIOP implementation > instead of an > > > RMI-IIOP tie. > > > b. servant_preinvoke() returns an RMI-IIOP tie, but this tie implements > > > the remote interface (MyItf in your example) and contains > code to > > delegate > > > method calls made through this interface to the > implementation. > > > > > > I think both of these are valid approaches that should continue > to be > > allowed. > > > The first is more efficient, but requires the ORB to have > knowledge of > > RMI-IIOP > > > so that it can treat RMI-IIOP Ties as servants specially. I'm > not quite > > sure > > > why you think this is a bad idea. RMI-IIOP is a mandatory part > of CORBA > > 2.3 > > > and above and all Java ORBs must support it in order to be > > CORBA-compliant. > > > However, I'm open to finding an alternative solution that avoids > the need > > > for putting this special case in the ORB. > > > > > > Changing the generated stub code (your option 1) is > problematical because > > it > > > means that for ORBs that currently use approach a above, old > stubs won't > > work > > > with the new runtime or vice versa. This is a major issue for customers > > who > > > have a large number of applications already deployed (including generated > > stub > > > code) and aren't able to upgrade their runtime as well as all > their > > deployed > > > applications at the same time. > > > > > > Your option 2 is a clever idea that leaves the stubs unchanged. > I'd like > > to > > > propose a minor change to your code for compatibility with ORBs > that > > currently > > > use approach a above. Here's my modified version: > > > public ServantObject _servant_preinvoke(String operation, > Class > > expectedType) { > > > ServantObject so = super._servant_preinvoke(this, > operation, > > expectedType); > > > if (so.servant instanceof javax.rmi.CORBA.Tie) > > > so.servant = > ((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > > return so; > > > } > > > This works no matter whether the ORB returns the Tie or the implementation > > object. > > > > > > I think this is the best solution. It is compatible with > existing stubs > > and > > > existing ORBs (no matter which approach they have adopted) and > solves the > > problem > > > of ORBs being unable to return the CORBA servant (RMI-IIOP tie) > within the > > > ServantObject. > > > > > > If there are no objections to this solution, I will write up a > formal > > proposal > > > for voting. > > > > > > Simon > > > > > > Michael Rumpf wrote: > > > > > > > > Sorry for including you all on the list of recipients, but the > Issue > > archive > > > > indicates your interest on the topic. > > > > > > > > I stumbled over the same problem which has been reported by > Jerome > > Daniels > > > > as an issue a few months ago: http://cgi.omg.org/issues/issue4429.txt. > > The > > > > discussion on the issue seems to got stuck and I would like to resolve > > it... > > > > > > > > Problem summary: > > > > ---------------------------------------- > > > > > > > > public class _MyItf_Tie > > > > extends org.omg.PortableServer.Servant // no further base classes > > > > implements javax.rmi.CORBA.Tie // derived from > > InvokeHandler > > > > { > > > > public void hello(); > > > > } > > > > > > > > The Tie does not have the interface MyItf in its derivation > graph, > > instead > > > > the interface is stored in the target member of the class and > can be > > > > accessed by the methods get/setTarget(). > > > > > > > > The Java to IDL Mapping spec. provides code snippets for local > > invocation > > > > optimizations on 1-49 (01-06-07.pdf, 1.5.2.2 Local Stubs) or > on 1-47 > > > > (99-07-59.pdf, 1.5.2.2 Local Stubs). Point number three seems > to provide > > a > > > > wrong cast: > > > > > > > > "3. If _servant_preinvoke returned a non-null ServantObject > so, call > > > > ((Aardvark)so.servant).echo(x)" > > > > > > > > The ORB's _servant_preinvoke() method returns an object of > type > > > > ServantObject: > > > > > > > > public class ServantObject { > > > > public java.lang.Object servant; > > > > } > > > > > > > > The servant member of ServantObject actually stores Tie > objects because > > the > > > > Tie's base class org.omg.PortableServer.Servant qualifies a > Tie as > > servant. > > > > But in this case the cast: > > > > > > > > ((MyItf)so.servant).hello(); > > > > > > > > will fail with a ClassCastException ! > > > > > > > > You could argue that the type of the servant member in > ServantObject is > > not > > > > org.omg.PortableServer.Servant but java.lang.Object so that it > could > > hold > > > > any type, even the interface, is correct, but.... > > > > > > > > In this case you would have to add some code to check for > instances of > > type > > > > javax.rmi.CORBA.Tie into the ORB's code. Especially into > > > > POA.servant_preinvoke. This means that you add RMIoverIIOP > code into > > your > > > > ORB. I think that this is a bad style. E.g. OpenORB's > RMIoverIIOP module > > is > > > > developed as an extension that can be plugged under the ORB > in a > > totally > > > > transparent way (and I guess that is one of the retionale > behind the > > > > RMIoverIIOP spec. in general). So mixing up the ORB's code > with > > RMIoverIIOP > > > > stuff should be a non-issue... > > > > > > > > I can think of two possible solutions then: > > > > > > > > 1. Jerome's proposition by changing the code to get the target object > > from > > > > the Tie: > > > > > > > > ((MyItf)((_MyItf_Tie)_so.servant).getTarget()).hello(); > > > > > > > > 2. Add a _servant_preinvoke method to the abstract Stub class > > > > (javax.rmi.CORBA.Stub) so that preinvoke can return the > target as > > the > > > > servant > > > > member of the ServantObject instead of the Tie. > > > > > > > > public ServantObject _servant_preinvoke(String > operation, > > > > Class expectedType) { > > > > ServantObject so = > > super._get_delegate().servant_preinvoke(this, > > > > operation,expectedType); > > > > so.servant = > > > > > (java.lang.Object)((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > > > return so; > > > > } > > > > > > > > In my eyes one of the two solutions would be the cleanest way > to go. I > > didn' > > > > try the second one but I don't think there are any other implications. > > The > > > > first one looks even better because no interface change for > > > > javax.rmi.CORBA.Stub is necessary. And by the way that is the > one I > > > > implemented as a workaround for OpenORB's RMIoverIIOP module > and it > > works > > > > perfectly ;-) > > > > > > > > Regards, > > > > Michael Rumpf > > > > > > > > PS: I'm not an OMG member so I'm not sure whether this mail > reaches the > > RTF > > > > mailing-list. If not could someone please forward it there... > > > > > > -- > > > Simon C Nash, Chief Technical Officer, IBM Java Technology > > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > > > > > > -- > Simon C Nash, Chief Technical Officer, IBM Java Technology > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > Date: Tue, 16 Oct 2001 10:22:25 +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: Michael Rumpf CC: Jerome DANIEL , ann_dalton@uk.ibm.com, vnatarajan@borland.com, java2idl-rtf@omg.org Subject: Re: Issue 4429 (Java to IDL Mapping) References: <005e01c15258$e3dfcfe0$c51811ac@brokat.de> <3BC9D174.A1AA6A6F@hursley.ibm.com> <01da01c15583$524847f0$c51811ac@brokat.de> <3BCB1772.8E5D72B3@hursley.ibm.com> <028c01c15610$fc1bcb70$c51811ac@brokat.de> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: _-6e9+'He9Qpgd9dH"e9 Michael, I think your option 1 is the same as my proposal. You are correct that it needs a change in the JDK. Since Sun is on the Java to IDL RTF, they have a say as part of the discussion and voting process on whether to adopt this solution. Your option 2 has the same problem as your original proposal that required the stub code to be changed. Since we have other options that don't require any change to the stubs, I would prefer to adopt one of these as the solution. If waiting for an updated JDK isn't acceptable, we could resolve this by saying that the object returned by _servant_preinvoke() must implement the remote interface and can be used to call the servant implementation. This allows it to either be the implementation itself, or a tie that contains code to delegate remote method calls to the implementation. This approach does put RMI-IIOP dependencies into the Java ORB, but requires no stub or JDK changes. I'd like to ask all RTF members to indicate their preference for solving this. The options are: a. The ORB must ensure that the object returned by _servant_preinvoke() implements the remote interface and can be used to call the servant implementation. b. The JDK javax.rmi.CORBA.Stub class must be changed as I proposed earlier. c. Some other proposal. IBM's preference is for a. Simon Michael Rumpf wrote: > > Hi Simon, > > I just found out that OpenORB uses a servant_preinvoke() method > internally to handle both cases, local and remote. In order to make > the proposal for Issue4429 work I had to change the behaviour a > little bit, but this is all OpenORB internal and should not affect the > latest suggestion. > > But I found two other possibilities which could be worth thinking of: > > 1. Add a servant_preinvoke method to the interface > javax.rmi.CORBA.Stub. The implementation knows that the > return value is for RMI-IIOP only and calls getTarget() on the > Tie object returned by the ORB's servant_preinvoke. > The problem I see with this approach is that the Stub > class/interface is part of the JDK and it will be hard > to guarantee that the correct version of the class is loaded > by the classloader. > > 2. Create the servant_preinvoke method above into the > generated stub to avoid changing JDK classes/interfaces. > The problem with this approach is that the stubs need to be > regenerated. > > Michael > > ----- Original Message ----- > From: "Simon Nash" > To: "Michael Rumpf" > Sent: Montag, 15. Oktober 2001 19:05 > Subject: Re: Issue 4429 (Java to IDL Mapping) > > > Michael, > > The servant_preinvoke() call is only intended to be called for locally > optimized > > invocations. I don't understand how it could return a servant for a > non-local > > call, since in this case the servant will be in some other process or > machine. > > > > Simon > > > > Michael Rumpf wrote: > > > > > > FYI, problem with the discussed solution to Issue4429 ! > > > > > > I just noticed that servant_preinvoke() is called also for the non-local > > > case. In the non-local case the return ServantObject must contain a > Servant > > > and not the implementation of an interface. > > > > > > I'm currently not sure whether this is an implementation detail of > OpenORB > > > or whether it is common bevaviour. If the latter is the case then our > > > solution must check whether the call was a locally optimized call and we > > > must invoke getTarget() only in this case... Some signs point into the > > > direction that the call to preinvoke for remote requests is a special > > > behaviour of OpenORB, the JavaDoc comment is "Preinvoke a local > operation. A > > > successfull call is always paired with a call to servant_postinvoke." > > > > > > Michael > > > > > > ----- Original Message ----- > > > From: "Simon Nash" > > > To: "Michael Rumpf" > > > Cc: "Jerome DANIEL" ; ; > > > ; > > > Sent: Sonntag, 14. Oktober 2001 19:55 > > > Subject: Re: Issue 4429 (Java to IDL Mapping) > > > > > > > Michael, > > > > Thanks for sending this. At present it seems that ORBs have solved > this > > > > problem in one of two ways: > > > > a. servant_preinvoke() returns an RMI-IIOP implementation instead of > an > > > > RMI-IIOP tie. > > > > b. servant_preinvoke() returns an RMI-IIOP tie, but this tie > implements > > > > the remote interface (MyItf in your example) and contains code to > > > delegate > > > > method calls made through this interface to the implementation. > > > > > > > > I think both of these are valid approaches that should continue to be > > > allowed. > > > > The first is more efficient, but requires the ORB to have knowledge of > > > RMI-IIOP > > > > so that it can treat RMI-IIOP Ties as servants specially. I'm not > quite > > > sure > > > > why you think this is a bad idea. RMI-IIOP is a mandatory part of > CORBA > > > 2.3 > > > > and above and all Java ORBs must support it in order to be > > > CORBA-compliant. > > > > However, I'm open to finding an alternative solution that avoids the > need > > > > for putting this special case in the ORB. > > > > > > > > Changing the generated stub code (your option 1) is problematical > because > > > it > > > > means that for ORBs that currently use approach a above, old stubs > won't > > > work > > > > with the new runtime or vice versa. This is a major issue for > customers > > > who > > > > have a large number of applications already deployed (including > generated > > > stub > > > > code) and aren't able to upgrade their runtime as well as all their > > > deployed > > > > applications at the same time. > > > > > > > > Your option 2 is a clever idea that leaves the stubs unchanged. I'd > like > > > to > > > > propose a minor change to your code for compatibility with ORBs that > > > currently > > > > use approach a above. Here's my modified version: > > > > public ServantObject _servant_preinvoke(String operation, Class > > > expectedType) { > > > > ServantObject so = super._servant_preinvoke(this, operation, > > > expectedType); > > > > if (so.servant instanceof javax.rmi.CORBA.Tie) > > > > so.servant = ((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > > > return so; > > > > } > > > > This works no matter whether the ORB returns the Tie or the > implementation > > > object. > > > > > > > > I think this is the best solution. It is compatible with existing > stubs > > > and > > > > existing ORBs (no matter which approach they have adopted) and solves > the > > > problem > > > > of ORBs being unable to return the CORBA servant (RMI-IIOP tie) within > the > > > > ServantObject. > > > > > > > > If there are no objections to this solution, I will write up a formal > > > proposal > > > > for voting. > > > > > > > > Simon > > > > > > > > Michael Rumpf wrote: > > > > > > > > > > Sorry for including you all on the list of recipients, but the Issue > > > archive > > > > > indicates your interest on the topic. > > > > > > > > > > I stumbled over the same problem which has been reported by Jerome > > > Daniels > > > > > as an issue a few months ago: > http://cgi.omg.org/issues/issue4429.txt. > > > The > > > > > discussion on the issue seems to got stuck and I would like to > resolve > > > it... > > > > > > > > > > Problem summary: > > > > > ---------------------------------------- > > > > > > > > > > public class _MyItf_Tie > > > > > extends org.omg.PortableServer.Servant // no further base > classes > > > > > implements javax.rmi.CORBA.Tie // derived from > > > InvokeHandler > > > > > { > > > > > public void hello(); > > > > > } > > > > > > > > > > The Tie does not have the interface MyItf in its derivation graph, > > > instead > > > > > the interface is stored in the target member of the class and can be > > > > > accessed by the methods get/setTarget(). > > > > > > > > > > The Java to IDL Mapping spec. provides code snippets for local > > > invocation > > > > > optimizations on 1-49 (01-06-07.pdf, 1.5.2.2 Local Stubs) or on 1-47 > > > > > (99-07-59.pdf, 1.5.2.2 Local Stubs). Point number three seems to > provide > > > a > > > > > wrong cast: > > > > > > > > > > "3. If _servant_preinvoke returned a non-null ServantObject so, call > > > > > ((Aardvark)so.servant).echo(x)" > > > > > > > > > > The ORB's _servant_preinvoke() method returns an object of type > > > > > ServantObject: > > > > > > > > > > public class ServantObject { > > > > > public java.lang.Object servant; > > > > > } > > > > > > > > > > The servant member of ServantObject actually stores Tie objects > because > > > the > > > > > Tie's base class org.omg.PortableServer.Servant qualifies a Tie as > > > servant. > > > > > But in this case the cast: > > > > > > > > > > ((MyItf)so.servant).hello(); > > > > > > > > > > will fail with a ClassCastException ! > > > > > > > > > > You could argue that the type of the servant member in ServantObject > is > > > not > > > > > org.omg.PortableServer.Servant but java.lang.Object so that it could > > > hold > > > > > any type, even the interface, is correct, but.... > > > > > > > > > > In this case you would have to add some code to check for instances > of > > > type > > > > > javax.rmi.CORBA.Tie into the ORB's code. Especially into > > > > > POA.servant_preinvoke. This means that you add RMIoverIIOP code into > > > your > > > > > ORB. I think that this is a bad style. E.g. OpenORB's RMIoverIIOP > module > > > is > > > > > developed as an extension that can be plugged under the ORB in a > > > totally > > > > > transparent way (and I guess that is one of the retionale behind the > > > > > RMIoverIIOP spec. in general). So mixing up the ORB's code with > > > RMIoverIIOP > > > > > stuff should be a non-issue... > > > > > > > > > > I can think of two possible solutions then: > > > > > > > > > > 1. Jerome's proposition by changing the code to get the target > object > > > from > > > > > the Tie: > > > > > > > > > > ((MyItf)((_MyItf_Tie)_so.servant).getTarget()).hello(); > > > > > > > > > > 2. Add a _servant_preinvoke method to the abstract Stub class > > > > > (javax.rmi.CORBA.Stub) so that preinvoke can return the target > as > > > the > > > > > servant > > > > > member of the ServantObject instead of the Tie. > > > > > > > > > > public ServantObject _servant_preinvoke(String operation, > > > > > Class expectedType) { > > > > > ServantObject so = > > > super._get_delegate().servant_preinvoke(this, > > > > > operation,expectedType); > > > > > so.servant = > > > > > (java.lang.Object)((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > > > > return so; > > > > > } > > > > > > > > > > In my eyes one of the two solutions would be the cleanest way to go. > I > > > didn' > > > > > try the second one but I don't think there are any other > implications. > > > The > > > > > first one looks even better because no interface change for > > > > > javax.rmi.CORBA.Stub is necessary. And by the way that is the one I > > > > > implemented as a workaround for OpenORB's RMIoverIIOP module and it > > > works > > > > > perfectly ;-) > > > > > > > > > > Regards, > > > > > Michael Rumpf > > > > > > > > > > PS: I'm not an OMG member so I'm not sure whether this mail reaches > the > > > RTF > > > > > mailing-list. If not could someone please forward it there... > > > > > > > > -- > > > > Simon C Nash, Chief Technical Officer, IBM Java Technology > > > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > > > > > > > > > > -- > > Simon C Nash, Chief Technical Officer, IBM Java Technology > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Oct 2001 08:42:46 -0700 To: Simon Nash , Michael Rumpf From: Andy Piper Subject: Re: Issue 4429 (Java to IDL Mapping) Cc: Jerome DANIEL , ann_dalton@uk.ibm.com, vnatarajan@borland.com, java2idl-rtf@omg.org In-Reply-To: <3BCBFC50.8D3B2A7A@hursley.ibm.com> References: <005e01c15258$e3dfcfe0$c51811ac@brokat.de> <3BC9D174.A1AA6A6F@hursley.ibm.com> <01da01c15583$524847f0$c51811ac@brokat.de> <3BCB1772.8E5D72B3@hursley.ibm.com> <028c01c15610$fc1bcb70$c51811ac@brokat.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: l[Ud9d>;e9mp5e9,= X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Michael Rumpf , Jerome DANIEL , ann_dalton@uk.ibm.com, vnatarajan@borland.com, java2idl-rtf@omg.org Subject: Re: Issue 4429 (Java to IDL Mapping) References: <005e01c15258$e3dfcfe0$c51811ac@brokat.de> <3BC9D174.A1AA6A6F@hursley.ibm.com> <01da01c15583$524847f0$c51811ac@brokat.de> <3BCB1772.8E5D72B3@hursley.ibm.com> <028c01c15610$fc1bcb70$c51811ac@brokat.de> <3BCBFC50.8D3B2A7A@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: mX1e9~fB!!;5h!!O3]d9 Sun's preference is for a). This gives all ORB vendors room to implement the way they prefer. The spec should be updated accordingly. I think b) is a nice solution if we can't agree on a), but in fairness to Borland it would have to look like public ServantObject _servant_preinvoke(String operation, Class expectedType) { if (so.servant instanceof ) return so; if (so.servant instanceof javax.rmi.CORBA.Tie) so.servant = ((javax.rmi.CORBA.Tie)so.servant).getTarget(); // Hopefully they know what they are doing! return so; } The alternative of changing the stubs doesn't work from a portability standpoint. -Stefan Simon Nash wrote: > Michael, > I think your option 1 is the same as my proposal. You are correct > that it > needs a change in the JDK. Since Sun is on the Java to IDL RTF, > they have > a say as part of the discussion and voting process on whether to > adopt this > solution. > > Your option 2 has the same problem as your original proposal that > required > the stub code to be changed. Since we have other options that don't > require > any change to the stubs, I would prefer to adopt one of these as the > solution. > > If waiting for an updated JDK isn't acceptable, we could resolve > this by > saying that the object returned by _servant_preinvoke() must > implement the > remote interface and can be used to call the servant > implementation. This > allows it to either be the implementation itself, or a tie that > contains > code to delegate remote method calls to the implementation. This > approach > does put RMI-IIOP dependencies into the Java ORB, but requires no > stub or > JDK changes. > > I'd like to ask all RTF members to indicate their preference for > solving this. > The options are: > a. The ORB must ensure that the object returned by > _servant_preinvoke() > implements the remote interface and can be used to call the > servant > implementation. > b. The JDK javax.rmi.CORBA.Stub class must be changed as I proposed > earlier. > c. Some other proposal. > > IBM's preference is for a. > > Simon > > Michael Rumpf wrote: > > > > Hi Simon, > > > > I just found out that OpenORB uses a servant_preinvoke() method > > internally to handle both cases, local and remote. In order to > make > > the proposal for Issue4429 work I had to change the behaviour a > > little bit, but this is all OpenORB internal and should not affect > the > > latest suggestion. > > > > But I found two other possibilities which could be worth thinking > of: > > > > 1. Add a servant_preinvoke method to the interface > > javax.rmi.CORBA.Stub. The implementation knows that the > > return value is for RMI-IIOP only and calls getTarget() on the > > Tie object returned by the ORB's servant_preinvoke. > > The problem I see with this approach is that the Stub > > class/interface is part of the JDK and it will be hard > > to guarantee that the correct version of the class is loaded > > by the classloader. > > > > 2. Create the servant_preinvoke method above into the > > generated stub to avoid changing JDK classes/interfaces. > > The problem with this approach is that the stubs need to be > > regenerated. > > > > Michael > > > > ----- Original Message ----- > > From: "Simon Nash" > > To: "Michael Rumpf" > > Sent: Montag, 15. Oktober 2001 19:05 > > Subject: Re: Issue 4429 (Java to IDL Mapping) > > > > > Michael, > > > The servant_preinvoke() call is only intended to be called for > locally > > optimized > > > invocations. I don't understand how it could return a servant > for a > > non-local > > > call, since in this case the servant will be in some other > process or > > machine. > > > > > > Simon > > > > > > Michael Rumpf wrote: > > > > > > > > FYI, problem with the discussed solution to Issue4429 ! > > > > > > > > I just noticed that servant_preinvoke() is called also for the > non-local > > > > case. In the non-local case the return ServantObject must > contain a > > Servant > > > > and not the implementation of an interface. > > > > > > > > I'm currently not sure whether this is an implementation > detail of > > OpenORB > > > > or whether it is common bevaviour. If the latter is the case > then our > > > > solution must check whether the call was a locally optimized > call and we > > > > must invoke getTarget() only in this case... Some signs point > into the > > > > direction that the call to preinvoke for remote requests is a > special > > > > behaviour of OpenORB, the JavaDoc comment is "Preinvoke a > local > > operation. A > > > > successfull call is always paired with a call to > servant_postinvoke." > > > > > > > > Michael > > > > > > > > ----- Original Message ----- > > > > From: "Simon Nash" > > > > To: "Michael Rumpf" > > > > Cc: "Jerome DANIEL" ; > ; > > > > ; > > > > Sent: Sonntag, 14. Oktober 2001 19:55 > > > > Subject: Re: Issue 4429 (Java to IDL Mapping) > > > > > > > > > Michael, > > > > > Thanks for sending this. At present it seems that ORBs have > solved > > this > > > > > problem in one of two ways: > > > > > a. servant_preinvoke() returns an RMI-IIOP implementation > instead of > > an > > > > > RMI-IIOP tie. > > > > > b. servant_preinvoke() returns an RMI-IIOP tie, but this > tie > > implements > > > > > the remote interface (MyItf in your example) and > contains code to > > > > delegate > > > > > method calls made through this interface to the > implementation. > > > > > > > > > > I think both of these are valid approaches that should > continue to be > > > > allowed. > > > > > The first is more efficient, but requires the ORB to have > knowledge of > > > > RMI-IIOP > > > > > so that it can treat RMI-IIOP Ties as servants specially. > I'm not > > quite > > > > sure > > > > > why you think this is a bad idea. RMI-IIOP is a mandatory > part of > > CORBA > > > > 2.3 > > > > > and above and all Java ORBs must support it in order to be > > > > CORBA-compliant. > > > > > However, I'm open to finding an alternative solution that > avoids the > > need > > > > > for putting this special case in the ORB. > > > > > > > > > > Changing the generated stub code (your option 1) is > problematical > > because > > > > it > > > > > means that for ORBs that currently use approach a above, old > stubs > > won't > > > > work > > > > > with the new runtime or vice versa. This is a major issue > for > > customers > > > > who > > > > > have a large number of applications already deployed > (including > > generated > > > > stub > > > > > code) and aren't able to upgrade their runtime as well as > all their > > > > deployed > > > > > applications at the same time. > > > > > > > > > > Your option 2 is a clever idea that leaves the stubs > unchanged. I'd > > like > > > > to > > > > > propose a minor change to your code for compatibility with > ORBs that > > > > currently > > > > > use approach a above. Here's my modified version: > > > > > public ServantObject _servant_preinvoke(String operation, > Class > > > > expectedType) { > > > > > ServantObject so = super._servant_preinvoke(this, > operation, > > > > expectedType); > > > > > if (so.servant instanceof javax.rmi.CORBA.Tie) > > > > > so.servant = > ((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > > > > return so; > > > > > } > > > > > This works no matter whether the ORB returns the Tie or the > > implementation > > > > object. > > > > > > > > > > I think this is the best solution. It is compatible with > existing > > stubs > > > > and > > > > > existing ORBs (no matter which approach they have adopted) > and solves > > the > > > > problem > > > > > of ORBs being unable to return the CORBA servant (RMI-IIOP > tie) within > > the > > > > > ServantObject. > > > > > > > > > > If there are no objections to this solution, I will write up > a formal > > > > proposal > > > > > for voting. > > > > > > > > > > Simon > > > > > > > > > > Michael Rumpf wrote: > > > > > > > > > > > > Sorry for including you all on the list of recipients, but > the Issue > > > > archive > > > > > > indicates your interest on the topic. > > > > > > > > > > > > I stumbled over the same problem which has been reported > by Jerome > > > > Daniels > > > > > > as an issue a few months ago: > > http://cgi.omg.org/issues/issue4429.txt. > > > > The > > > > > > discussion on the issue seems to got stuck and I would > like to > > resolve > > > > it... > > > > > > > > > > > > Problem summary: > > > > > > ---------------------------------------- > > > > > > > > > > > > public class _MyItf_Tie > > > > > > extends org.omg.PortableServer.Servant // no further > base > > classes > > > > > > implements javax.rmi.CORBA.Tie // derived > from > > > > InvokeHandler > > > > > > { > > > > > > public void hello(); > > > > > > } > > > > > > > > > > > > The Tie does not have the interface MyItf in its > derivation graph, > > > > instead > > > > > > the interface is stored in the target member of the class > and can be > > > > > > accessed by the methods get/setTarget(). > > > > > > > > > > > > The Java to IDL Mapping spec. provides code snippets for > local > > > > invocation > > > > > > optimizations on 1-49 (01-06-07.pdf, 1.5.2.2 Local Stubs) > or on 1-47 > > > > > > (99-07-59.pdf, 1.5.2.2 Local Stubs). Point number three > seems to > > provide > > > > a > > > > > > wrong cast: > > > > > > > > > > > > "3. If _servant_preinvoke returned a non-null > ServantObject so, call > > > > > > ((Aardvark)so.servant).echo(x)" > > > > > > > > > > > > The ORB's _servant_preinvoke() method returns an object of > type > > > > > > ServantObject: > > > > > > > > > > > > public class ServantObject { > > > > > > public java.lang.Object servant; > > > > > > } > > > > > > > > > > > > The servant member of ServantObject actually stores Tie > objects > > because > > > > the > > > > > > Tie's base class org.omg.PortableServer.Servant qualifies > a Tie as > > > > servant. > > > > > > But in this case the cast: > > > > > > > > > > > > ((MyItf)so.servant).hello(); > > > > > > > > > > > > will fail with a ClassCastException ! > > > > > > > > > > > > You could argue that the type of the servant member in > ServantObject > > is > > > > not > > > > > > org.omg.PortableServer.Servant but java.lang.Object so > that it could > > > > hold > > > > > > any type, even the interface, is correct, but.... > > > > > > > > > > > > In this case you would have to add some code to check for > instances > > of > > > > type > > > > > > javax.rmi.CORBA.Tie into the ORB's code. Especially into > > > > > > POA.servant_preinvoke. This means that you add RMIoverIIOP > code into > > > > your > > > > > > ORB. I think that this is a bad style. E.g. OpenORB's > RMIoverIIOP > > module > > > > is > > > > > > developed as an extension that can be plugged under the > ORB in a > > > > totally > > > > > > transparent way (and I guess that is one of the retionale > behind the > > > > > > RMIoverIIOP spec. in general). So mixing up the ORB's code > with > > > > RMIoverIIOP > > > > > > stuff should be a non-issue... > > > > > > > > > > > > I can think of two possible solutions then: > > > > > > > > > > > > 1. Jerome's proposition by changing the code to get the > target > > object > > > > from > > > > > > the Tie: > > > > > > > > > > > > > ((MyItf)((_MyItf_Tie)_so.servant).getTarget()).hello(); > > > > > > > > > > > > 2. Add a _servant_preinvoke method to the abstract Stub > class > > > > > > (javax.rmi.CORBA.Stub) so that preinvoke can return > the target > > as > > > > the > > > > > > servant > > > > > > member of the ServantObject instead of the Tie. > > > > > > > > > > > > public ServantObject _servant_preinvoke(String > operation, > > > > > > Class expectedType) { > > > > > > ServantObject so = > > > > super._get_delegate().servant_preinvoke(this, > > > > > > operation,expectedType); > > > > > > so.servant = > > > > > > > (java.lang.Object)((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > > > > > return so; > > > > > > } > > > > > > > > > > > > In my eyes one of the two solutions would be the cleanest > way to go. > > I > > > > didn' > > > > > > try the second one but I don't think there are any other > > implications. > > > > The > > > > > > first one looks even better because no interface change > for > > > > > > javax.rmi.CORBA.Stub is necessary. And by the way that is > the one I > > > > > > implemented as a workaround for OpenORB's RMIoverIIOP > module and it > > > > works > > > > > > perfectly ;-) > > > > > > > > > > > > Regards, > > > > > > Michael Rumpf > > > > > > > > > > > > PS: I'm not an OMG member so I'm not sure whether this > mail reaches > > the > > > > RTF > > > > > > mailing-list. If not could someone please forward it > there... > > > > > > > > > > -- > > > > > Simon C Nash, Chief Technical Officer, IBM Java Technology > > > > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, > England > > > > > Internet: nash@hursley.ibm.com Lotus Notes: Simon > Nash@ibmgb > > > > > > > > > > > > > > > > -- > > > Simon C Nash, Chief Technical Officer, IBM Java Technology > > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > > > -- > Simon C Nash, Chief Technical Officer, IBM Java Technology > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: "Michael Rumpf" To: "Stefan Bauer" Cc: "Simon Nash" , "Jerome DANIEL" , , , References: <005e01c15258$e3dfcfe0$c51811ac@brokat.de> <3BC9D174.A1AA6A6F@hursley.ibm.com> <01da01c15583$524847f0$c51811ac@brokat.de> <3BCB1772.8E5D72B3@hursley.ibm.com> <028c01c15610$fc1bcb70$c51811ac@brokat.de> <3BCBFC50.8D3B2A7A@hursley.ibm.com> <3BCE01FC.2D71E110@sun.com> Subject: Re: Issue 4429 (Java to IDL Mapping) Date: Fri, 23 Nov 2001 14:47:43 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: !d>e9CnP!!?m4e95b3!! Hi, it's me again ;-) We are currently trying Sun's ECPerf Performance Test Suite and discovered that some problems with Issue4429 still exist (at least with OpenORB). For the local case we have the following stub code now code (mapping unchanged, getTarget() is called in POA.servant_preinvoke()): org.omg.CORBA.portable.ServantObject _so = _servant_preinvoke("_get_longValue",_opsClass); if ( _so == null ) return getLongValue(); try { long _arg_ret = ((test.TestItf)_so.servant).getLongValue(); return _arg_ret; } catch ( Throwable ex ) { Throwable ex2 = ( Throwable ) javax.rmi.CORBA.Util.copyObject(ex, _orb()); throw javax.rmi.CORBA.Util.wrapException(ex2); } finally { _servant_postinvoke(_so); } The problem is the _servant_postinvoke(_so) when we apply the changes we discussed recently. The POA.servant_postinvoke() is internally called at last: public void servant_postinvoke(byte[] object_key,org.omg.CORBA.portable.ServantObject srvObject) { // *snip* if(non_retain && use_manager) { // call postinvoke on the servant manager. if(servant_locate == null) throw new org.omg.CORBA.OBJ_ADAPTER(0, CompletionStatus.COMPLETED_YES); servant_locate.postinvoke(state.getObjectID(), this, state.operation, state.cookie, (Servant)state.servant); } // *snip* } When you look to the last line you will see that the ServantObject's servant is accessed and casted to a Servant type. This fails, when we apply our current solution for Issue4429, with a ClassCastException, because the previously executed getTarget() in preinvoke on the Tie placed the implementation into the servant member!!! Of course this is a very special case, when policy NON_RETAIN and USE_SERVANT_MANAGER is specified, but it occurs, as we experienced today ;-) I see currently two solutions: 1. Change the proposed solution to place the getTarget() into the stub code (under the current circumstance in my opinion the cleanest solution) and live with the portability problem that stubs need to be regenerated. 2. Hold a mapping on the server side which addresses implementations with servants (ugly hack and further performance reduction) I'm not sure whether I'm right, maybe OpenORB's POA.servant_postinvoke() is wrong here, but I think returning something special from servant_preinvoke(), i.e. loosing the original association, and expecting something different when calling servant_postinvok() is problematic... Michael ----- Original Message ----- From: "Stefan Bauer" To: "Simon Nash" Cc: "Michael Rumpf" ; "Jerome DANIEL" ; ; ; Sent: Mittwoch, 17. Oktober 2001 23:11 Subject: Re: Issue 4429 (Java to IDL Mapping) > Sun's preference is for a). This gives all ORB vendors room to implement the way > they prefer. The spec should be updated accordingly. > > I think b) is a nice solution if we can't agree on a), but in fairness to Borland > it would have to look like > > public ServantObject _servant_preinvoke(String operation, Class expectedType) { > if (so.servant instanceof ) > return so; > if (so.servant instanceof javax.rmi.CORBA.Tie) > so.servant = ((javax.rmi.CORBA.Tie)so.servant).getTarget(); > // Hopefully they know what they are doing! > return so; > } > > The alternative of changing the stubs doesn't work from a portability standpoint. > > -Stefan > > Simon Nash wrote: > > > Michael, > > I think your option 1 is the same as my proposal. You are correct that it > > needs a change in the JDK. Since Sun is on the Java to IDL RTF, they have > > a say as part of the discussion and voting process on whether to adopt this > > solution. > > > > Your option 2 has the same problem as your original proposal that required > > the stub code to be changed. Since we have other options that don't require > > any change to the stubs, I would prefer to adopt one of these as the solution. > > > > If waiting for an updated JDK isn't acceptable, we could resolve this by > > saying that the object returned by _servant_preinvoke() must implement the > > remote interface and can be used to call the servant implementation. This > > allows it to either be the implementation itself, or a tie that contains > > code to delegate remote method calls to the implementation. This approach > > does put RMI-IIOP dependencies into the Java ORB, but requires no stub or > > JDK changes. > > > > I'd like to ask all RTF members to indicate their preference for solving this. > > The options are: > > a. The ORB must ensure that the object returned by _servant_preinvoke() > > implements the remote interface and can be used to call the servant > > implementation. > > b. The JDK javax.rmi.CORBA.Stub class must be changed as I proposed earlier. > > c. Some other proposal. > > > > IBM's preference is for a. > > > > Simon > > > > Michael Rumpf wrote: > > > > > > Hi Simon, > > > > > > I just found out that OpenORB uses a servant_preinvoke() method > > > internally to handle both cases, local and remote. In order to make > > > the proposal for Issue4429 work I had to change the behaviour a > > > little bit, but this is all OpenORB internal and should not affect the > > > latest suggestion. > > > > > > But I found two other possibilities which could be worth thinking of: > > > > > > 1. Add a servant_preinvoke method to the interface > > > javax.rmi.CORBA.Stub. The implementation knows that the > > > return value is for RMI-IIOP only and calls getTarget() on the > > > Tie object returned by the ORB's servant_preinvoke. > > > The problem I see with this approach is that the Stub > > > class/interface is part of the JDK and it will be hard > > > to guarantee that the correct version of the class is loaded > > > by the classloader. > > > > > > 2. Create the servant_preinvoke method above into the > > > generated stub to avoid changing JDK classes/interfaces. > > > The problem with this approach is that the stubs need to be > > > regenerated. > > > > > > Michael > > > > > > ----- Original Message ----- > > > From: "Simon Nash" > > > To: "Michael Rumpf" > > > Sent: Montag, 15. Oktober 2001 19:05 > > > Subject: Re: Issue 4429 (Java to IDL Mapping) > > > > > > > Michael, > > > > The servant_preinvoke() call is only intended to be called for locally > > > optimized > > > > invocations. I don't understand how it could return a servant for a > > > non-local > > > > call, since in this case the servant will be in some other process or > > > machine. > > > > > > > > Simon > > > > > > > > Michael Rumpf wrote: > > > > > > > > > > FYI, problem with the discussed solution to Issue4429 ! > > > > > > > > > > I just noticed that servant_preinvoke() is called also for the non-local > > > > > case. In the non-local case the return ServantObject must contain a > > > Servant > > > > > and not the implementation of an interface. > > > > > > > > > > I'm currently not sure whether this is an implementation detail of > > > OpenORB > > > > > or whether it is common bevaviour. If the latter is the case then our > > > > > solution must check whether the call was a locally optimized call and we > > > > > must invoke getTarget() only in this case... Some signs point into the > > > > > direction that the call to preinvoke for remote requests is a special > > > > > behaviour of OpenORB, the JavaDoc comment is "Preinvoke a local > > > operation. A > > > > > successfull call is always paired with a call to servant_postinvoke." > > > > > > > > > > Michael > > > > > > > > > > ----- Original Message ----- > > > > > From: "Simon Nash" > > > > > To: "Michael Rumpf" > > > > > Cc: "Jerome DANIEL" ; ; > > > > > ; > > > > > Sent: Sonntag, 14. Oktober 2001 19:55 > > > > > Subject: Re: Issue 4429 (Java to IDL Mapping) > > > > > > > > > > > Michael, > > > > > > Thanks for sending this. At present it seems that ORBs have solved > > > this > > > > > > problem in one of two ways: > > > > > > a. servant_preinvoke() returns an RMI-IIOP implementation instead of > > > an > > > > > > RMI-IIOP tie. > > > > > > b. servant_preinvoke() returns an RMI-IIOP tie, but this tie > > > implements > > > > > > the remote interface (MyItf in your example) and contains code to > > > > > delegate > > > > > > method calls made through this interface to the implementation. > > > > > > > > > > > > I think both of these are valid approaches that should continue to be > > > > > allowed. > > > > > > The first is more efficient, but requires the ORB to have knowledge of > > > > > RMI-IIOP > > > > > > so that it can treat RMI-IIOP Ties as servants specially. I'm not > > > quite > > > > > sure > > > > > > why you think this is a bad idea. RMI-IIOP is a mandatory part of > > > CORBA > > > > > 2.3 > > > > > > and above and all Java ORBs must support it in order to be > > > > > CORBA-compliant. > > > > > > However, I'm open to finding an alternative solution that avoids the > > > need > > > > > > for putting this special case in the ORB. > > > > > > > > > > > > Changing the generated stub code (your option 1) is problematical > > > because > > > > > it > > > > > > means that for ORBs that currently use approach a above, old stubs > > > won't > > > > > work > > > > > > with the new runtime or vice versa. This is a major issue for > > > customers > > > > > who > > > > > > have a large number of applications already deployed (including > > > generated > > > > > stub > > > > > > code) and aren't able to upgrade their runtime as well as all their > > > > > deployed > > > > > > applications at the same time. > > > > > > > > > > > > Your option 2 is a clever idea that leaves the stubs unchanged. I'd > > > like > > > > > to > > > > > > propose a minor change to your code for compatibility with ORBs that > > > > > currently > > > > > > use approach a above. Here's my modified version: > > > > > > public ServantObject _servant_preinvoke(String operation, Class > > > > > expectedType) { > > > > > > ServantObject so = super._servant_preinvoke(this, operation, > > > > > expectedType); > > > > > > if (so.servant instanceof javax.rmi.CORBA.Tie) > > > > > > so.servant = ((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > > > > > return so; > > > > > > } > > > > > > This works no matter whether the ORB returns the Tie or the > > > implementation > > > > > object. > > > > > > > > > > > > I think this is the best solution. It is compatible with existing > > > stubs > > > > > and > > > > > > existing ORBs (no matter which approach they have adopted) and solves > > > the > > > > > problem > > > > > > of ORBs being unable to return the CORBA servant (RMI-IIOP tie) within > > > the > > > > > > ServantObject. > > > > > > > > > > > > If there are no objections to this solution, I will write up a formal > > > > > proposal > > > > > > for voting. > > > > > > > > > > > > Simon > > > > > > > > > > > > Michael Rumpf wrote: > > > > > > > > > > > > > > Sorry for including you all on the list of recipients, but the Issue > > > > > archive > > > > > > > indicates your interest on the topic. > > > > > > > > > > > > > > I stumbled over the same problem which has been reported by Jerome > > > > > Daniels > > > > > > > as an issue a few months ago: > > > http://cgi.omg.org/issues/issue4429.txt. > > > > > The > > > > > > > discussion on the issue seems to got stuck and I would like to > > > resolve > > > > > it... > > > > > > > > > > > > > > Problem summary: > > > > > > > ---------------------------------------- > > > > > > > > > > > > > > public class _MyItf_Tie > > > > > > > extends org.omg.PortableServer.Servant // no further base > > > classes > > > > > > > implements javax.rmi.CORBA.Tie // derived from > > > > > InvokeHandler > > > > > > > { > > > > > > > public void hello(); > > > > > > > } > > > > > > > > > > > > > > The Tie does not have the interface MyItf in its derivation graph, > > > > > instead > > > > > > > the interface is stored in the target member of the class and can be > > > > > > > accessed by the methods get/setTarget(). > > > > > > > > > > > > > > The Java to IDL Mapping spec. provides code snippets for local > > > > > invocation > > > > > > > optimizations on 1-49 (01-06-07.pdf, 1.5.2.2 Local Stubs) or on 1-47 > > > > > > > (99-07-59.pdf, 1.5.2.2 Local Stubs). Point number three seems to > > > provide > > > > > a > > > > > > > wrong cast: > > > > > > > > > > > > > > "3. If _servant_preinvoke returned a non-null ServantObject so, call > > > > > > > ((Aardvark)so.servant).echo(x)" > > > > > > > > > > > > > > The ORB's _servant_preinvoke() method returns an object of type > > > > > > > ServantObject: > > > > > > > > > > > > > > public class ServantObject { > > > > > > > public java.lang.Object servant; > > > > > > > } > > > > > > > > > > > > > > The servant member of ServantObject actually stores Tie objects > > > because > > > > > the > > > > > > > Tie's base class org.omg.PortableServer.Servant qualifies a Tie as > > > > > servant. > > > > > > > But in this case the cast: > > > > > > > > > > > > > > ((MyItf)so.servant).hello(); > > > > > > > > > > > > > > will fail with a ClassCastException ! > > > > > > > > > > > > > > You could argue that the type of the servant member in ServantObject > > > is > > > > > not > > > > > > > org.omg.PortableServer.Servant but java.lang.Object so that it could > > > > > hold > > > > > > > any type, even the interface, is correct, but.... > > > > > > > > > > > > > > In this case you would have to add some code to check for instances > > > of > > > > > type > > > > > > > javax.rmi.CORBA.Tie into the ORB's code. Especially into > > > > > > > POA.servant_preinvoke. This means that you add RMIoverIIOP code into > > > > > your > > > > > > > ORB. I think that this is a bad style. E.g. OpenORB's RMIoverIIOP > > > module > > > > > is > > > > > > > developed as an extension that can be plugged under the ORB in a > > > > > totally > > > > > > > transparent way (and I guess that is one of the retionale behind the > > > > > > > RMIoverIIOP spec. in general). So mixing up the ORB's code with > > > > > RMIoverIIOP > > > > > > > stuff should be a non-issue... > > > > > > > > > > > > > > I can think of two possible solutions then: > > > > > > > > > > > > > > 1. Jerome's proposition by changing the code to get the target > > > object > > > > > from > > > > > > > the Tie: > > > > > > > > > > > > > > ((MyItf)((_MyItf_Tie)_so.servant).getTarget()).hello(); > > > > > > > > > > > > > > 2. Add a _servant_preinvoke method to the abstract Stub class > > > > > > > (javax.rmi.CORBA.Stub) so that preinvoke can return the target > > > as > > > > > the > > > > > > > servant > > > > > > > member of the ServantObject instead of the Tie. > > > > > > > > > > > > > > public ServantObject _servant_preinvoke(String operation, > > > > > > > Class expectedType) { > > > > > > > ServantObject so = > > > > > super._get_delegate().servant_preinvoke(this, > > > > > > > operation,expectedType); > > > > > > > so.servant = > > > > > > > (java.lang.Object)((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > > > > > > return so; > > > > > > > } > > > > > > > > > > > > > > In my eyes one of the two solutions would be the cleanest way to go. > > > I > > > > > didn' > > > > > > > try the second one but I don't think there are any other > > > implications. > > > > > The > > > > > > > first one looks even better because no interface change for > > > > > > > javax.rmi.CORBA.Stub is necessary. And by the way that is the one I > > > > > > > implemented as a workaround for OpenORB's RMIoverIIOP module and it > > > > > works > > > > > > > perfectly ;-) > > > > > > > > > > > > > > Regards, > > > > > > > Michael Rumpf > > > > > > > > > > > > > > PS: I'm not an OMG member so I'm not sure whether this mail reaches > > > the > > > > > RTF > > > > > > > mailing-list. If not could someone please forward it there... > > > > > > > > > > > > -- > > > > > > Simon C Nash, Chief Technical Officer, IBM Java Technology > > > > > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > > > > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > > > > > > > > > > > > > > > > > > -- > > > > Simon C Nash, Chief Technical Officer, IBM Java Technology > > > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > > > > > > -- > > Simon C Nash, Chief Technical Officer, IBM Java Technology > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > Date: Mon, 26 Nov 2001 09:34:44 +0000 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: Michael Rumpf CC: Ken Cavanaugh , Jerome DANIEL , ann_dalton@uk.ibm.com, vnatarajan@borland.com, java2idl-rtf@omg.org Subject: Re: Issue 4429 (Java to IDL Mapping) References: <005e01c15258$e3dfcfe0$c51811ac@brokat.de> <3BC9D174.A1AA6A6F@hursley.ibm.com> <01da01c15583$524847f0$c51811ac@brokat.de> <3BCB1772.8E5D72B3@hursley.ibm.com> <028c01c15610$fc1bcb70$c51811ac@brokat.de> <3BCBFC50.8D3B2A7A@hursley.ibm.com> <3BCE01FC.2D71E110@sun.com> <00c601c17425$6da311e0$c51811ac@brokat.de> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: !KQ!!aOKe9Lk#!!JUEe9 Michael, Your code extract is incomplete and I'm not sure what the "state" object is. It doesn't seem to be the same as "_so" since "state" has fields called operation and cookie as well as a getObjectID() method. Can't you set the servant field of "state" to the POA servant, and set the servant field of "_so" to the target object? Simon Michael Rumpf wrote: > > Hi, > > it's me again ;-) > > We are currently trying Sun's ECPerf Performance Test Suite and discovered > that some problems with Issue4429 still exist (at least with OpenORB). > > For the local case we have the following stub code now code (mapping > unchanged, getTarget() is called in POA.servant_preinvoke()): > > org.omg.CORBA.portable.ServantObject _so = > _servant_preinvoke("_get_longValue",_opsClass); > if ( _so == null ) > return getLongValue(); > try > { > long _arg_ret = ((test.TestItf)_so.servant).getLongValue(); > return _arg_ret; > } > catch ( Throwable ex ) > { > Throwable ex2 = ( Throwable ) javax.rmi.CORBA.Util.copyObject(ex, > _orb()); > throw javax.rmi.CORBA.Util.wrapException(ex2); > } > finally > { > _servant_postinvoke(_so); > } > > The problem is the _servant_postinvoke(_so) when we apply the changes we > discussed recently. > The POA.servant_postinvoke() is internally called at last: > > public void servant_postinvoke(byte[] > object_key,org.omg.CORBA.portable.ServantObject srvObject) > { > // *snip* > > if(non_retain && use_manager) { > // call postinvoke on the servant manager. > if(servant_locate == null) > throw new org.omg.CORBA.OBJ_ADAPTER(0, > CompletionStatus.COMPLETED_YES); > > servant_locate.postinvoke(state.getObjectID(), this, state.operation, > state.cookie, (Servant)state.servant); > } > > // *snip* > } > > When you look to the last line you will see that the ServantObject's servant > is accessed and casted to a Servant type. This fails, when we apply our > current solution for Issue4429, with a ClassCastException, because the > previously executed getTarget() in preinvoke on the Tie placed the > implementation into the servant member!!! > Of course this is a very special case, when policy NON_RETAIN and > USE_SERVANT_MANAGER is specified, but it occurs, as we experienced today ;-) > > I see currently two solutions: > 1. Change the proposed solution to place the getTarget() into the stub code > (under the current circumstance in my opinion the cleanest solution) and > live with the portability problem that stubs need to be regenerated. > 2. Hold a mapping on the server side which addresses implementations with > servants (ugly hack and further performance reduction) > > I'm not sure whether I'm right, maybe OpenORB's POA.servant_postinvoke() is > wrong here, but I think returning something special from > servant_preinvoke(), i.e. loosing the original association, and expecting > something different when calling servant_postinvok() is problematic... > > Michael > > ----- Original Message ----- > From: "Stefan Bauer" > To: "Simon Nash" > Cc: "Michael Rumpf" ; "Jerome DANIEL" > ; ; ; > > Sent: Mittwoch, 17. Oktober 2001 23:11 > Subject: Re: Issue 4429 (Java to IDL Mapping) > > > Sun's preference is for a). This gives all ORB vendors room to implement > the way > > they prefer. The spec should be updated accordingly. > > > > I think b) is a nice solution if we can't agree on a), but in fairness to > Borland > > it would have to look like > > > > public ServantObject _servant_preinvoke(String operation, Class > expectedType) { > > if (so.servant instanceof ) > > return so; > > if (so.servant instanceof javax.rmi.CORBA.Tie) > > so.servant = ((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > // Hopefully they know what they are doing! > > return so; > > } > > > > The alternative of changing the stubs doesn't work from a portability > standpoint. > > > > -Stefan > > > > Simon Nash wrote: > > > > > Michael, > > > I think your option 1 is the same as my proposal. You are correct that > it > > > needs a change in the JDK. Since Sun is on the Java to IDL RTF, they > have > > > a say as part of the discussion and voting process on whether to adopt > this > > > solution. > > > > > > Your option 2 has the same problem as your original proposal that > required > > > the stub code to be changed. Since we have other options that don't > require > > > any change to the stubs, I would prefer to adopt one of these as the > solution. > > > > > > If waiting for an updated JDK isn't acceptable, we could resolve this by > > > saying that the object returned by _servant_preinvoke() must implement > the > > > remote interface and can be used to call the servant implementation. > This > > > allows it to either be the implementation itself, or a tie that contains > > > code to delegate remote method calls to the implementation. This > approach > > > does put RMI-IIOP dependencies into the Java ORB, but requires no stub > or > > > JDK changes. > > > > > > I'd like to ask all RTF members to indicate their preference for solving > this. > > > The options are: > > > a. The ORB must ensure that the object returned by _servant_preinvoke() > > > implements the remote interface and can be used to call the servant > > > implementation. > > > b. The JDK javax.rmi.CORBA.Stub class must be changed as I proposed > earlier. > > > c. Some other proposal. > > > > > > IBM's preference is for a. > > > > > > Simon > > > > > > Michael Rumpf wrote: > > > > > > > > Hi Simon, > > > > > > > > I just found out that OpenORB uses a servant_preinvoke() method > > > > internally to handle both cases, local and remote. In order to make > > > > the proposal for Issue4429 work I had to change the behaviour a > > > > little bit, but this is all OpenORB internal and should not affect the > > > > latest suggestion. > > > > > > > > But I found two other possibilities which could be worth thinking of: > > > > > > > > 1. Add a servant_preinvoke method to the interface > > > > javax.rmi.CORBA.Stub. The implementation knows that the > > > > return value is for RMI-IIOP only and calls getTarget() on the > > > > Tie object returned by the ORB's servant_preinvoke. > > > > The problem I see with this approach is that the Stub > > > > class/interface is part of the JDK and it will be hard > > > > to guarantee that the correct version of the class is loaded > > > > by the classloader. > > > > > > > > 2. Create the servant_preinvoke method above into the > > > > generated stub to avoid changing JDK classes/interfaces. > > > > The problem with this approach is that the stubs need to be > > > > regenerated. > > > > > > > > Michael > > > > > > > > ----- Original Message ----- > > > > From: "Simon Nash" > > > > To: "Michael Rumpf" > > > > Sent: Montag, 15. Oktober 2001 19:05 > > > > Subject: Re: Issue 4429 (Java to IDL Mapping) > > > > > > > > > Michael, > > > > > The servant_preinvoke() call is only intended to be called for > locally > > > > optimized > > > > > invocations. I don't understand how it could return a servant for a > > > > non-local > > > > > call, since in this case the servant will be in some other process > or > > > > machine. > > > > > > > > > > Simon > > > > > > > > > > Michael Rumpf wrote: > > > > > > > > > > > > FYI, problem with the discussed solution to Issue4429 ! > > > > > > > > > > > > I just noticed that servant_preinvoke() is called also for the > non-local > > > > > > case. In the non-local case the return ServantObject must contain > a > > > > Servant > > > > > > and not the implementation of an interface. > > > > > > > > > > > > I'm currently not sure whether this is an implementation detail of > > > > OpenORB > > > > > > or whether it is common bevaviour. If the latter is the case then > our > > > > > > solution must check whether the call was a locally optimized call > and we > > > > > > must invoke getTarget() only in this case... Some signs point into > the > > > > > > direction that the call to preinvoke for remote requests is a > special > > > > > > behaviour of OpenORB, the JavaDoc comment is "Preinvoke a local > > > > operation. A > > > > > > successfull call is always paired with a call to > servant_postinvoke." > > > > > > > > > > > > Michael > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Simon Nash" > > > > > > To: "Michael Rumpf" > > > > > > Cc: "Jerome DANIEL" ; > ; > > > > > > ; > > > > > > Sent: Sonntag, 14. Oktober 2001 19:55 > > > > > > Subject: Re: Issue 4429 (Java to IDL Mapping) > > > > > > > > > > > > > Michael, > > > > > > > Thanks for sending this. At present it seems that ORBs have > solved > > > > this > > > > > > > problem in one of two ways: > > > > > > > a. servant_preinvoke() returns an RMI-IIOP implementation > instead of > > > > an > > > > > > > RMI-IIOP tie. > > > > > > > b. servant_preinvoke() returns an RMI-IIOP tie, but this tie > > > > implements > > > > > > > the remote interface (MyItf in your example) and contains > code to > > > > > > delegate > > > > > > > method calls made through this interface to the > implementation. > > > > > > > > > > > > > > I think both of these are valid approaches that should continue > to be > > > > > > allowed. > > > > > > > The first is more efficient, but requires the ORB to have > knowledge of > > > > > > RMI-IIOP > > > > > > > so that it can treat RMI-IIOP Ties as servants specially. I'm > not > > > > quite > > > > > > sure > > > > > > > why you think this is a bad idea. RMI-IIOP is a mandatory part > of > > > > CORBA > > > > > > 2.3 > > > > > > > and above and all Java ORBs must support it in order to be > > > > > > CORBA-compliant. > > > > > > > However, I'm open to finding an alternative solution that avoids > the > > > > need > > > > > > > for putting this special case in the ORB. > > > > > > > > > > > > > > Changing the generated stub code (your option 1) is > problematical > > > > because > > > > > > it > > > > > > > means that for ORBs that currently use approach a above, old > stubs > > > > won't > > > > > > work > > > > > > > with the new runtime or vice versa. This is a major issue for > > > > customers > > > > > > who > > > > > > > have a large number of applications already deployed (including > > > > generated > > > > > > stub > > > > > > > code) and aren't able to upgrade their runtime as well as all > their > > > > > > deployed > > > > > > > applications at the same time. > > > > > > > > > > > > > > Your option 2 is a clever idea that leaves the stubs unchanged. > I'd > > > > like > > > > > > to > > > > > > > propose a minor change to your code for compatibility with ORBs > that > > > > > > currently > > > > > > > use approach a above. Here's my modified version: > > > > > > > public ServantObject _servant_preinvoke(String operation, > Class > > > > > > expectedType) { > > > > > > > ServantObject so = super._servant_preinvoke(this, > operation, > > > > > > expectedType); > > > > > > > if (so.servant instanceof javax.rmi.CORBA.Tie) > > > > > > > so.servant = > ((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > > > > > > return so; > > > > > > > } > > > > > > > This works no matter whether the ORB returns the Tie or the > > > > implementation > > > > > > object. > > > > > > > > > > > > > > I think this is the best solution. It is compatible with > existing > > > > stubs > > > > > > and > > > > > > > existing ORBs (no matter which approach they have adopted) and > solves > > > > the > > > > > > problem > > > > > > > of ORBs being unable to return the CORBA servant (RMI-IIOP tie) > within > > > > the > > > > > > > ServantObject. > > > > > > > > > > > > > > If there are no objections to this solution, I will write up a > formal > > > > > > proposal > > > > > > > for voting. > > > > > > > > > > > > > > Simon > > > > > > > > > > > > > > Michael Rumpf wrote: > > > > > > > > > > > > > > > > Sorry for including you all on the list of recipients, but the > Issue > > > > > > archive > > > > > > > > indicates your interest on the topic. > > > > > > > > > > > > > > > > I stumbled over the same problem which has been reported by > Jerome > > > > > > Daniels > > > > > > > > as an issue a few months ago: > > > > http://cgi.omg.org/issues/issue4429.txt. > > > > > > The > > > > > > > > discussion on the issue seems to got stuck and I would like to > > > > resolve > > > > > > it... > > > > > > > > > > > > > > > > Problem summary: > > > > > > > > ---------------------------------------- > > > > > > > > > > > > > > > > public class _MyItf_Tie > > > > > > > > extends org.omg.PortableServer.Servant // no further base > > > > classes > > > > > > > > implements javax.rmi.CORBA.Tie // derived from > > > > > > InvokeHandler > > > > > > > > { > > > > > > > > public void hello(); > > > > > > > > } > > > > > > > > > > > > > > > > The Tie does not have the interface MyItf in its derivation > graph, > > > > > > instead > > > > > > > > the interface is stored in the target member of the class and > can be > > > > > > > > accessed by the methods get/setTarget(). > > > > > > > > > > > > > > > > The Java to IDL Mapping spec. provides code snippets for local > > > > > > invocation > > > > > > > > optimizations on 1-49 (01-06-07.pdf, 1.5.2.2 Local Stubs) or > on 1-47 > > > > > > > > (99-07-59.pdf, 1.5.2.2 Local Stubs). Point number three seems > to > > > > provide > > > > > > a > > > > > > > > wrong cast: > > > > > > > > > > > > > > > > "3. If _servant_preinvoke returned a non-null ServantObject > so, call > > > > > > > > ((Aardvark)so.servant).echo(x)" > > > > > > > > > > > > > > > > The ORB's _servant_preinvoke() method returns an object of > type > > > > > > > > ServantObject: > > > > > > > > > > > > > > > > public class ServantObject { > > > > > > > > public java.lang.Object servant; > > > > > > > > } > > > > > > > > > > > > > > > > The servant member of ServantObject actually stores Tie > objects > > > > because > > > > > > the > > > > > > > > Tie's base class org.omg.PortableServer.Servant qualifies a > Tie as > > > > > > servant. > > > > > > > > But in this case the cast: > > > > > > > > > > > > > > > > ((MyItf)so.servant).hello(); > > > > > > > > > > > > > > > > will fail with a ClassCastException ! > > > > > > > > > > > > > > > > You could argue that the type of the servant member in > ServantObject > > > > is > > > > > > not > > > > > > > > org.omg.PortableServer.Servant but java.lang.Object so that it > could > > > > > > hold > > > > > > > > any type, even the interface, is correct, but.... > > > > > > > > > > > > > > > > In this case you would have to add some code to check for > instances > > > > of > > > > > > type > > > > > > > > javax.rmi.CORBA.Tie into the ORB's code. Especially into > > > > > > > > POA.servant_preinvoke. This means that you add RMIoverIIOP > code into > > > > > > your > > > > > > > > ORB. I think that this is a bad style. E.g. OpenORB's > RMIoverIIOP > > > > module > > > > > > is > > > > > > > > developed as an extension that can be plugged under the ORB > in a > > > > > > totally > > > > > > > > transparent way (and I guess that is one of the retionale > behind the > > > > > > > > RMIoverIIOP spec. in general). So mixing up the ORB's code > with > > > > > > RMIoverIIOP > > > > > > > > stuff should be a non-issue... > > > > > > > > > > > > > > > > I can think of two possible solutions then: > > > > > > > > > > > > > > > > 1. Jerome's proposition by changing the code to get the target > > > > object > > > > > > from > > > > > > > > the Tie: > > > > > > > > > > > > > > > > ((MyItf)((_MyItf_Tie)_so.servant).getTarget()).hello(); > > > > > > > > > > > > > > > > 2. Add a _servant_preinvoke method to the abstract Stub class > > > > > > > > (javax.rmi.CORBA.Stub) so that preinvoke can return the > target > > > > as > > > > > > the > > > > > > > > servant > > > > > > > > member of the ServantObject instead of the Tie. > > > > > > > > > > > > > > > > public ServantObject _servant_preinvoke(String > operation, > > > > > > > > Class expectedType) { > > > > > > > > ServantObject so = > > > > > > super._get_delegate().servant_preinvoke(this, > > > > > > > > operation,expectedType); > > > > > > > > so.servant = > > > > > > > > > (java.lang.Object)((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > > > > > > > return so; > > > > > > > > } > > > > > > > > > > > > > > > > In my eyes one of the two solutions would be the cleanest way > to go. > > > > I > > > > > > didn' > > > > > > > > try the second one but I don't think there are any other > > > > implications. > > > > > > The > > > > > > > > first one looks even better because no interface change for > > > > > > > > javax.rmi.CORBA.Stub is necessary. And by the way that is the > one I > > > > > > > > implemented as a workaround for OpenORB's RMIoverIIOP module > and it > > > > > > works > > > > > > > > perfectly ;-) > > > > > > > > > > > > > > > > Regards, > > > > > > > > Michael Rumpf > > > > > > > > > > > > > > > > PS: I'm not an OMG member so I'm not sure whether this mail > reaches > > > > the > > > > > > RTF > > > > > > > > mailing-list. If not could someone please forward it there... > > > > > > > > > > > > > > -- > > > > > > > Simon C Nash, Chief Technical Officer, IBM Java Technology > > > > > > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > > > > > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Simon C Nash, Chief Technical Officer, IBM Java Technology > > > > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > > > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > > > > > > > > > -- > > > Simon C Nash, Chief Technical Officer, IBM Java Technology > > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > > -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: "Michael Rumpf" To: "Simon Nash" Cc: "Ken Cavanaugh" , "Jerome DANIEL" , , , References: <005e01c15258$e3dfcfe0$c51811ac@brokat.de> <3BC9D174.A1AA6A6F@hursley.ibm.com> <01da01c15583$524847f0$c51811ac@brokat.de> <3BCB1772.8E5D72B3@hursley.ibm.com> <028c01c15610$fc1bcb70$c51811ac@brokat.de> <3BCBFC50.8D3B2A7A@hursley.ibm.com> <3BCE01FC.2D71E110@sun.com> <00c601c17425$6da311e0$c51811ac@brokat.de> <3C020CB4.6B6D9B26@hursley.ibm.com> Subject: Re: Issue 4429 (Java to IDL Mapping) Date: Mon, 26 Nov 2001 12:36:01 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: >ih!!eT1!!~"5e92O%e9 Hi Simon, I removed some unnecessary code fragments here. The state member in OpenORB is an instance of the class DispatchState: class DispatchState extends org.omg.CORBA.portable.ServantObject implements TargetInfo { // ... } Here the whole servant_postinvoke method: public void servant_postinvoke(byte[] object_key,org.omg.CORBA.portable.ServantObject srvObject) { DispatchState state = null; try { state = poa_current.pop(); } catch(org.omg.PortableServer.CurrentPackage.NoContext ex) { } org.openorb.util.Trace.assertTrue(srvObject == state, "Postinvoke step does not match preinvoke step"); if(non_retain && use_manager) { // call postinvoke on the servant manager. if(servant_locate == null) throw new org.omg.CORBA.OBJ_ADAPTER(0, CompletionStatus.COMPLETED_YES); servant_locate.postinvoke(state.getObjectID(), this, state.operation, state.cookie, (Servant)state.servant); } synchronized(sync_requests) { active_requests--; if(rejecting && active_requests == 0) complete_destroy(); } } Because the state object inherits from ServantObject, the state object itself is returned to the stub. But in the local invocation case our solution stuffed the implementation type into the DispatchState class. I guess I could make another hack here, by adding an additional member to the DispatchState structure. In the local invocation case for preinvoke() store the actual servant in the new member and keep it null in any other cases. When postinvoke will be called look at the new member and if it is unequal to null use it instead of the servant member... I hope you will agree, that this is a hack. I'm missing the beauty of a clean solution here... (But maybe I'm too idealistic and I should have a certain level of pragmatism when dealing with spec revisioning ;-) Michael ----- Original Message ----- From: "Simon Nash" To: "Michael Rumpf" Cc: "Ken Cavanaugh" ; "Jerome DANIEL" ; ; ; Sent: Montag, 26. November 2001 10:34 Subject: Re: Issue 4429 (Java to IDL Mapping) > Michael, > Your code extract is incomplete and I'm not sure what the "state" > object is. > It doesn't seem to be the same as "_so" since "state" has fields > called > operation and cookie as well as a getObjectID() method. Can't you > set > the servant field of "state" to the POA servant, and set the servant > field > of "_so" to the target object? > > Simon > > Michael Rumpf wrote: > > > > Hi, > > > > it's me again ;-) > > > > We are currently trying Sun's ECPerf Performance Test Suite and discovered > > that some problems with Issue4429 still exist (at least with > OpenORB). > > > > For the local case we have the following stub code now code > (mapping > > unchanged, getTarget() is called in POA.servant_preinvoke()): > > > > org.omg.CORBA.portable.ServantObject _so = > > _servant_preinvoke("_get_longValue",_opsClass); > > if ( _so == null ) > > return getLongValue(); > > try > > { > > long _arg_ret = ((test.TestItf)_so.servant).getLongValue(); > > return _arg_ret; > > } > > catch ( Throwable ex ) > > { > > Throwable ex2 = ( Throwable ) > javax.rmi.CORBA.Util.copyObject(ex, > > _orb()); > > throw javax.rmi.CORBA.Util.wrapException(ex2); > > } > > finally > > { > > _servant_postinvoke(_so); > > } > > > > The problem is the _servant_postinvoke(_so) when we apply the > changes we > > discussed recently. > > The POA.servant_postinvoke() is internally called at last: > > > > public void servant_postinvoke(byte[] > > object_key,org.omg.CORBA.portable.ServantObject srvObject) > > { > > // *snip* > > > > if(non_retain && use_manager) { > > // call postinvoke on the servant manager. > > if(servant_locate == null) > > throw new org.omg.CORBA.OBJ_ADAPTER(0, > > CompletionStatus.COMPLETED_YES); > > > > servant_locate.postinvoke(state.getObjectID(), this, state.operation, > > state.cookie, (Servant)state.servant); > > } > > > > // *snip* > > } > > > > When you look to the last line you will see that the > ServantObject's servant > > is accessed and casted to a Servant type. This fails, when we > apply our > > current solution for Issue4429, with a ClassCastException, because > the > > previously executed getTarget() in preinvoke on the Tie placed the > > implementation into the servant member!!! > > Of course this is a very special case, when policy NON_RETAIN and > > USE_SERVANT_MANAGER is specified, but it occurs, as we experienced > today ;-) > > > > I see currently two solutions: > > 1. Change the proposed solution to place the getTarget() into the > stub code > > (under the current circumstance in my opinion the cleanest > solution) and > > live with the portability problem that stubs need to be > regenerated. > > 2. Hold a mapping on the server side which addresses > implementations with > > servants (ugly hack and further performance reduction) > > > > I'm not sure whether I'm right, maybe OpenORB's > POA.servant_postinvoke() is > > wrong here, but I think returning something special from > > servant_preinvoke(), i.e. loosing the original association, and expecting > > something different when calling servant_postinvok() is > problematic... > > > > Michael > > > > ----- Original Message ----- > > From: "Stefan Bauer" > > To: "Simon Nash" > > Cc: "Michael Rumpf" ; "Jerome DANIEL" > > ; ; ; > > > > Sent: Mittwoch, 17. Oktober 2001 23:11 > > Subject: Re: Issue 4429 (Java to IDL Mapping) > > > > > Sun's preference is for a). This gives all ORB vendors room to implement > > the way > > > they prefer. The spec should be updated accordingly. > > > > > > I think b) is a nice solution if we can't agree on a), but in > fairness to > > Borland > > > it would have to look like > > > > > > public ServantObject _servant_preinvoke(String operation, > Class > > expectedType) { > > > if (so.servant instanceof ) > > > return so; > > > if (so.servant instanceof javax.rmi.CORBA.Tie) > > > so.servant = > ((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > > // Hopefully they know what they are doing! > > > return so; > > > } > > > > > > The alternative of changing the stubs doesn't work from a > portability > > standpoint. > > > > > > -Stefan > > > > > > Simon Nash wrote: > > > > > > > Michael, > > > > I think your option 1 is the same as my proposal. You are > correct that > > it > > > > needs a change in the JDK. Since Sun is on the Java to IDL > RTF, they > > have > > > > a say as part of the discussion and voting process on whether > to adopt > > this > > > > solution. > > > > > > > > Your option 2 has the same problem as your original proposal > that > > required > > > > the stub code to be changed. Since we have other options that > don't > > require > > > > any change to the stubs, I would prefer to adopt one of these > as the > > solution. > > > > > > > > If waiting for an updated JDK isn't acceptable, we could > resolve this by > > > > saying that the object returned by _servant_preinvoke() must implement > > the > > > > remote interface and can be used to call the servant > implementation. > > This > > > > allows it to either be the implementation itself, or a tie > that contains > > > > code to delegate remote method calls to the implementation. > This > > approach > > > > does put RMI-IIOP dependencies into the Java ORB, but requires > no stub > > or > > > > JDK changes. > > > > > > > > I'd like to ask all RTF members to indicate their preference > for solving > > this. > > > > The options are: > > > > a. The ORB must ensure that the object returned by _servant_preinvoke() > > > > implements the remote interface and can be used to call > the servant > > > > implementation. > > > > b. The JDK javax.rmi.CORBA.Stub class must be changed as I > proposed > > earlier. > > > > c. Some other proposal. > > > > > > > > IBM's preference is for a. > > > > > > > > Simon > > > > > > > > Michael Rumpf wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > I just found out that OpenORB uses a servant_preinvoke() > method > > > > > internally to handle both cases, local and remote. In order > to make > > > > > the proposal for Issue4429 work I had to change the > behaviour a > > > > > little bit, but this is all OpenORB internal and should not > affect the > > > > > latest suggestion. > > > > > > > > > > But I found two other possibilities which could be worth > thinking of: > > > > > > > > > > 1. Add a servant_preinvoke method to the interface > > > > > javax.rmi.CORBA.Stub. The implementation knows that the > > > > > return value is for RMI-IIOP only and calls getTarget() > on the > > > > > Tie object returned by the ORB's servant_preinvoke. > > > > > The problem I see with this approach is that the Stub > > > > > class/interface is part of the JDK and it will be hard > > > > > to guarantee that the correct version of the class is > loaded > > > > > by the classloader. > > > > > > > > > > 2. Create the servant_preinvoke method above into the > > > > > generated stub to avoid changing JDK classes/interfaces. > > > > > The problem with this approach is that the stubs need to > be > > > > > regenerated. > > > > > > > > > > Michael > > > > > > > > > > ----- Original Message ----- > > > > > From: "Simon Nash" > > > > > To: "Michael Rumpf" > > > > > Sent: Montag, 15. Oktober 2001 19:05 > > > > > Subject: Re: Issue 4429 (Java to IDL Mapping) > > > > > > > > > > > Michael, > > > > > > The servant_preinvoke() call is only intended to be called > for > > locally > > > > > optimized > > > > > > invocations. I don't understand how it could return a > servant for a > > > > > non-local > > > > > > call, since in this case the servant will be in some other process > > or > > > > > machine. > > > > > > > > > > > > Simon > > > > > > > > > > > > Michael Rumpf wrote: > > > > > > > > > > > > > > FYI, problem with the discussed solution to Issue4429 ! > > > > > > > > > > > > > > I just noticed that servant_preinvoke() is called also > for the > > non-local > > > > > > > case. In the non-local case the return ServantObject > must contain > > a > > > > > Servant > > > > > > > and not the implementation of an interface. > > > > > > > > > > > > > > I'm currently not sure whether this is an implementation detail of > > > > > OpenORB > > > > > > > or whether it is common bevaviour. If the latter is the > case then > > our > > > > > > > solution must check whether the call was a locally > optimized call > > and we > > > > > > > must invoke getTarget() only in this case... Some signs > point into > > the > > > > > > > direction that the call to preinvoke for remote requests > is a > > special > > > > > > > behaviour of OpenORB, the JavaDoc comment is "Preinvoke > a local > > > > > operation. A > > > > > > > successfull call is always paired with a call to > > servant_postinvoke." > > > > > > > > > > > > > > Michael > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Simon Nash" > > > > > > > To: "Michael Rumpf" > > > > > > > Cc: "Jerome DANIEL" ; > > ; > > > > > > > ; > > > > > > > Sent: Sonntag, 14. Oktober 2001 19:55 > > > > > > > Subject: Re: Issue 4429 (Java to IDL Mapping) > > > > > > > > > > > > > > > Michael, > > > > > > > > Thanks for sending this. At present it seems that > ORBs have > > solved > > > > > this > > > > > > > > problem in one of two ways: > > > > > > > > a. servant_preinvoke() returns an RMI-IIOP > implementation > > instead of > > > > > an > > > > > > > > RMI-IIOP tie. > > > > > > > > b. servant_preinvoke() returns an RMI-IIOP tie, but > this tie > > > > > implements > > > > > > > > the remote interface (MyItf in your example) and contains > > code to > > > > > > > delegate > > > > > > > > method calls made through this interface to the > > implementation. > > > > > > > > > > > > > > > > I think both of these are valid approaches that should continue > > to be > > > > > > > allowed. > > > > > > > > The first is more efficient, but requires the ORB to > have > > knowledge of > > > > > > > RMI-IIOP > > > > > > > > so that it can treat RMI-IIOP Ties as servants > specially. I'm > > not > > > > > quite > > > > > > > sure > > > > > > > > why you think this is a bad idea. RMI-IIOP is a > mandatory part > > of > > > > > CORBA > > > > > > > 2.3 > > > > > > > > and above and all Java ORBs must support it in order > to be > > > > > > > CORBA-compliant. > > > > > > > > However, I'm open to finding an alternative solution > that avoids > > the > > > > > need > > > > > > > > for putting this special case in the ORB. > > > > > > > > > > > > > > > > Changing the generated stub code (your option 1) is > > problematical > > > > > because > > > > > > > it > > > > > > > > means that for ORBs that currently use approach a > above, old > > stubs > > > > > won't > > > > > > > work > > > > > > > > with the new runtime or vice versa. This is a major > issue for > > > > > customers > > > > > > > who > > > > > > > > have a large number of applications already deployed (including > > > > > generated > > > > > > > stub > > > > > > > > code) and aren't able to upgrade their runtime as well > as all > > their > > > > > > > deployed > > > > > > > > applications at the same time. > > > > > > > > > > > > > > > > Your option 2 is a clever idea that leaves the stubs unchanged. > > I'd > > > > > like > > > > > > > to > > > > > > > > propose a minor change to your code for compatibility > with ORBs > > that > > > > > > > currently > > > > > > > > use approach a above. Here's my modified version: > > > > > > > > public ServantObject _servant_preinvoke(String > operation, > > Class > > > > > > > expectedType) { > > > > > > > > ServantObject so = > super._servant_preinvoke(this, > > operation, > > > > > > > expectedType); > > > > > > > > if (so.servant instanceof javax.rmi.CORBA.Tie) > > > > > > > > so.servant = > > ((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > > > > > > > return so; > > > > > > > > } > > > > > > > > This works no matter whether the ORB returns the Tie > or the > > > > > implementation > > > > > > > object. > > > > > > > > > > > > > > > > I think this is the best solution. It is compatible > with > > existing > > > > > stubs > > > > > > > and > > > > > > > > existing ORBs (no matter which approach they have > adopted) and > > solves > > > > > the > > > > > > > problem > > > > > > > > of ORBs being unable to return the CORBA servant > (RMI-IIOP tie) > > within > > > > > the > > > > > > > > ServantObject. > > > > > > > > > > > > > > > > If there are no objections to this solution, I will > write up a > > formal > > > > > > > proposal > > > > > > > > for voting. > > > > > > > > > > > > > > > > Simon > > > > > > > > > > > > > > > > Michael Rumpf wrote: > > > > > > > > > > > > > > > > > > Sorry for including you all on the list of > recipients, but the > > Issue > > > > > > > archive > > > > > > > > > indicates your interest on the topic. > > > > > > > > > > > > > > > > > > I stumbled over the same problem which has been > reported by > > Jerome > > > > > > > Daniels > > > > > > > > > as an issue a few months ago: > > > > > http://cgi.omg.org/issues/issue4429.txt. > > > > > > > The > > > > > > > > > discussion on the issue seems to got stuck and I > would like to > > > > > resolve > > > > > > > it... > > > > > > > > > > > > > > > > > > Problem summary: > > > > > > > > > ---------------------------------------- > > > > > > > > > > > > > > > > > > public class _MyItf_Tie > > > > > > > > > extends org.omg.PortableServer.Servant // no > further base > > > > > classes > > > > > > > > > implements javax.rmi.CORBA.Tie // > derived from > > > > > > > InvokeHandler > > > > > > > > > { > > > > > > > > > public void hello(); > > > > > > > > > } > > > > > > > > > > > > > > > > > > The Tie does not have the interface MyItf in its derivation > > graph, > > > > > > > instead > > > > > > > > > the interface is stored in the target member of the > class and > > can be > > > > > > > > > accessed by the methods get/setTarget(). > > > > > > > > > > > > > > > > > > The Java to IDL Mapping spec. provides code snippets > for local > > > > > > > invocation > > > > > > > > > optimizations on 1-49 (01-06-07.pdf, 1.5.2.2 Local > Stubs) or > > on 1-47 > > > > > > > > > (99-07-59.pdf, 1.5.2.2 Local Stubs). Point number > three seems > > to > > > > > provide > > > > > > > a > > > > > > > > > wrong cast: > > > > > > > > > > > > > > > > > > "3. If _servant_preinvoke returned a non-null ServantObject > > so, call > > > > > > > > > ((Aardvark)so.servant).echo(x)" > > > > > > > > > > > > > > > > > > The ORB's _servant_preinvoke() method returns an > object of > > type > > > > > > > > > ServantObject: > > > > > > > > > > > > > > > > > > public class ServantObject { > > > > > > > > > public java.lang.Object servant; > > > > > > > > > } > > > > > > > > > > > > > > > > > > The servant member of ServantObject actually stores > Tie > > objects > > > > > because > > > > > > > the > > > > > > > > > Tie's base class org.omg.PortableServer.Servant > qualifies a > > Tie as > > > > > > > servant. > > > > > > > > > But in this case the cast: > > > > > > > > > > > > > > > > > > ((MyItf)so.servant).hello(); > > > > > > > > > > > > > > > > > > will fail with a ClassCastException ! > > > > > > > > > > > > > > > > > > You could argue that the type of the servant member > in > > ServantObject > > > > > is > > > > > > > not > > > > > > > > > org.omg.PortableServer.Servant but java.lang.Object > so that it > > could > > > > > > > hold > > > > > > > > > any type, even the interface, is correct, but.... > > > > > > > > > > > > > > > > > > In this case you would have to add some code to > check for > > instances > > > > > of > > > > > > > type > > > > > > > > > javax.rmi.CORBA.Tie into the ORB's code. Especially > into > > > > > > > > > POA.servant_preinvoke. This means that you add > RMIoverIIOP > > code into > > > > > > > your > > > > > > > > > ORB. I think that this is a bad > style. E.g. OpenORB's > > RMIoverIIOP > > > > > module > > > > > > > is > > > > > > > > > developed as an extension that can be plugged under > the ORB > > in a > > > > > > > totally > > > > > > > > > transparent way (and I guess that is one of the > retionale > > behind the > > > > > > > > > RMIoverIIOP spec. in general). So mixing up the > ORB's code > > with > > > > > > > RMIoverIIOP > > > > > > > > > stuff should be a non-issue... > > > > > > > > > > > > > > > > > > I can think of two possible solutions then: > > > > > > > > > > > > > > > > > > 1. Jerome's proposition by changing the code to get > the target > > > > > object > > > > > > > from > > > > > > > > > the Tie: > > > > > > > > > > > > > > > > > > ((MyItf)((_MyItf_Tie)_so.servant).getTarget()).hello(); > > > > > > > > > > > > > > > > > > 2. Add a _servant_preinvoke method to the abstract > Stub class > > > > > > > > > (javax.rmi.CORBA.Stub) so that preinvoke can > return the > > target > > > > > as > > > > > > > the > > > > > > > > > servant > > > > > > > > > member of the ServantObject instead of the Tie. > > > > > > > > > > > > > > > > > > public ServantObject > _servant_preinvoke(String > > operation, > > > > > > > > > Class expectedType) { > > > > > > > > > ServantObject so = > > > > > > > super._get_delegate().servant_preinvoke(this, > > > > > > > > > operation,expectedType); > > > > > > > > > so.servant = > > > > > > > > > > > (java.lang.Object)((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > > > > > > > > return so; > > > > > > > > > } > > > > > > > > > > > > > > > > > > In my eyes one of the two solutions would be the > cleanest way > > to go. > > > > > I > > > > > > > didn' > > > > > > > > > try the second one but I don't think there are any > other > > > > > implications. > > > > > > > The > > > > > > > > > first one looks even better because no interface > change for > > > > > > > > > javax.rmi.CORBA.Stub is necessary. And by the way > that is the > > one I > > > > > > > > > implemented as a workaround for OpenORB's > RMIoverIIOP module > > and it > > > > > > > works > > > > > > > > > perfectly ;-) > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Michael Rumpf > > > > > > > > > > > > > > > > > > PS: I'm not an OMG member so I'm not sure whether > this mail > > reaches > > > > > the > > > > > > > RTF > > > > > > > > > mailing-list. If not could someone please forward it there... > > > > > > > > > > > > > > > > -- > > > > > > > > Simon C Nash, Chief Technical Officer, IBM Java > Technology > > > > > > > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > > > > > > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Simon C Nash, Chief Technical Officer, IBM Java Technology > > > > > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, > England > > > > > > Internet: nash@hursley.ibm.com Lotus Notes: Simon > Nash@ibmgb > > > > > > > > > > > > > > -- > > > > Simon C Nash, Chief Technical Officer, IBM Java Technology > > > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > > > > > > -- > Simon C Nash, Chief Technical Officer, IBM Java Technology > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > Date: Mon, 26 Nov 2001 15:12:00 +0000 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: Michael Rumpf CC: Ken Cavanaugh , Jerome DANIEL , ann_dalton@uk.ibm.com, vnatarajan@borland.com, java2idl-rtf@omg.org Subject: Re: Issue 4429 (Java to IDL Mapping) References: <005e01c15258$e3dfcfe0$c51811ac@brokat.de> <3BC9D174.A1AA6A6F@hursley.ibm.com> <01da01c15583$524847f0$c51811ac@brokat.de> <3BCB1772.8E5D72B3@hursley.ibm.com> <028c01c15610$fc1bcb70$c51811ac@brokat.de> <3BCBFC50.8D3B2A7A@hursley.ibm.com> <3BCE01FC.2D71E110@sun.com> <00c601c17425$6da311e0$c51811ac@brokat.de> <3C020CB4.6B6D9B26@hursley.ibm.com> <01f101c1766e$86a8e3e0$c51811ac@brokat.de> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ZCi!!ACJe9EU/e9XH(e9 Michael, Michael Rumpf wrote: > > Hi Simon, > > I removed some unnecessary code fragments here. The state member in OpenORB > is an instance of the class DispatchState: > > class DispatchState > extends org.omg.CORBA.portable.ServantObject > implements TargetInfo > { > // ... > } > > Here the whole servant_postinvoke method: > > public void servant_postinvoke(byte[] > object_key,org.omg.CORBA.portable.ServantObject srvObject) > { > DispatchState state = null; > try { > state = poa_current.pop(); > } > catch(org.omg.PortableServer.CurrentPackage.NoContext ex) { > } > > org.openorb.util.Trace.assertTrue(srvObject == state, "Postinvoke step > does not match preinvoke step"); > > if(non_retain && use_manager) { > // call postinvoke on the servant manager. > if(servant_locate == null) > throw new org.omg.CORBA.OBJ_ADAPTER(0, > CompletionStatus.COMPLETED_YES); > > servant_locate.postinvoke(state.getObjectID(), this, state.operation, > state.cookie, (Servant)state.servant); > } > > synchronized(sync_requests) { > active_requests--; > if(rejecting && active_requests == 0) > complete_destroy(); > } > } > > Because the state object inherits from ServantObject, the state object > itself is returned to the stub. But in the local invocation case our > solution stuffed the implementation type into the DispatchState class. > > I guess I could make another hack here, by adding an additional member to > the DispatchState structure. In the local invocation case for preinvoke() > store the actual servant in the new member and keep it null in any other > cases. When postinvoke will be called look at the new member and if it is > unequal to null use it instead of the servant member... > I would suggest always storing the actual servant in the new member, and always having postinvoke get the actual servant from the new member. Then it is not necessary to set the new member to null in some cases or to test the new member for a null value. > I hope you will agree, that this is a hack. I'm missing the beauty of a > clean solution here... (But maybe I'm too idealistic and I should have a > certain level of pragmatism when dealing with spec revisioning ;-) > I think the current implementation could be seen as less than completely clean, since it mixes the state needed for the correct operation of the OmniORB POA with the state needed for correct operation of the RMI-IIOP stub. Having DispatchState provide the former state and ServantObject provide the latter state (without an overlapping "servant" state member that is used by both the POA and the stub) doesn't strike me as a hack but as a reasonable separation of different concerns. I also admit to being somewhat pragmatic when dealing with spec revision and compatibility issues :-) Simon > Michael > > ----- Original Message ----- > From: "Simon Nash" > To: "Michael Rumpf" > Cc: "Ken Cavanaugh" ; "Jerome DANIEL" > ; ; > ; > > Sent: Montag, 26. November 2001 10:34 > Subject: Re: Issue 4429 (Java to IDL Mapping) > > > Michael, > > Your code extract is incomplete and I'm not sure what the "state" > object > is. > > It doesn't seem to be the same as "_so" since "state" has fields > called > > operation and cookie as well as a getObjectID() method. Can't you > set > > the servant field of "state" to the POA servant, and set the > servant field > > of "_so" to the target object? > > > > Simon > > > > Michael Rumpf wrote: > > > > > > Hi, > > > > > > it's me again ;-) > > > > > > We are currently trying Sun's ECPerf Performance Test Suite and > discovered > > > that some problems with Issue4429 still exist (at least with > OpenORB). > > > > > > For the local case we have the following stub code now code > (mapping > > > unchanged, getTarget() is called in POA.servant_preinvoke()): > > > > > > org.omg.CORBA.portable.ServantObject _so = > > > _servant_preinvoke("_get_longValue",_opsClass); > > > if ( _so == null ) > > > return getLongValue(); > > > try > > > { > > > long _arg_ret = ((test.TestItf)_so.servant).getLongValue(); > > > return _arg_ret; > > > } > > > catch ( Throwable ex ) > > > { > > > Throwable ex2 = ( Throwable ) > javax.rmi.CORBA.Util.copyObject(ex, > > > _orb()); > > > throw javax.rmi.CORBA.Util.wrapException(ex2); > > > } > > > finally > > > { > > > _servant_postinvoke(_so); > > > } > > > > > > The problem is the _servant_postinvoke(_so) when we apply the > changes we > > > discussed recently. > > > The POA.servant_postinvoke() is internally called at last: > > > > > > public void servant_postinvoke(byte[] > > > object_key,org.omg.CORBA.portable.ServantObject srvObject) > > > { > > > // *snip* > > > > > > if(non_retain && use_manager) { > > > // call postinvoke on the servant manager. > > > if(servant_locate == null) > > > throw new org.omg.CORBA.OBJ_ADAPTER(0, > > > CompletionStatus.COMPLETED_YES); > > > > > > servant_locate.postinvoke(state.getObjectID(), this, > state.operation, > > > state.cookie, (Servant)state.servant); > > > } > > > > > > // *snip* > > > } > > > > > > When you look to the last line you will see that the > ServantObject's > servant > > > is accessed and casted to a Servant type. This fails, when we > apply our > > > current solution for Issue4429, with a ClassCastException, > because the > > > previously executed getTarget() in preinvoke on the Tie placed > the > > > implementation into the servant member!!! > > > Of course this is a very special case, when policy NON_RETAIN > and > > > USE_SERVANT_MANAGER is specified, but it occurs, as we > experienced today > ;-) > > > > > > I see currently two solutions: > > > 1. Change the proposed solution to place the getTarget() into > the stub > code > > > (under the current circumstance in my opinion the cleanest > solution) and > > > live with the portability problem that stubs need to be > regenerated. > > > 2. Hold a mapping on the server side which addresses > implementations > with > > > servants (ugly hack and further performance reduction) > > > > > > I'm not sure whether I'm right, maybe OpenORB's > POA.servant_postinvoke() > is > > > wrong here, but I think returning something special from > > > servant_preinvoke(), i.e. loosing the original association, and > expecting > > > something different when calling servant_postinvok() is > problematic... > > > > > > Michael > > > > > > ----- Original Message ----- > > > From: "Stefan Bauer" > > > To: "Simon Nash" > > > Cc: "Michael Rumpf" ; "Jerome DANIEL" > > > ; ; > ; > > > > > > Sent: Mittwoch, 17. Oktober 2001 23:11 > > > Subject: Re: Issue 4429 (Java to IDL Mapping) > > > > > > > Sun's preference is for a). This gives all ORB vendors room to > implement > > > the way > > > > they prefer. The spec should be updated accordingly. > > > > > > > > I think b) is a nice solution if we can't agree on a), but in > fairness > to > > > Borland > > > > it would have to look like > > > > > > > > public ServantObject _servant_preinvoke(String operation, > Class > > > expectedType) { > > > > if (so.servant instanceof ) > > > > return so; > > > > if (so.servant instanceof javax.rmi.CORBA.Tie) > > > > so.servant = > ((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > > > // Hopefully they know what they are doing! > > > > return so; > > > > } > > > > > > > > The alternative of changing the stubs doesn't work from a > portability > > > standpoint. > > > > > > > > -Stefan > > > > > > > > Simon Nash wrote: > > > > > > > > > Michael, > > > > > I think your option 1 is the same as my proposal. You are > correct > that > > > it > > > > > needs a change in the JDK. Since Sun is on the Java to IDL > RTF, > they > > > have > > > > > a say as part of the discussion and voting process on > whether to > adopt > > > this > > > > > solution. > > > > > > > > > > Your option 2 has the same problem as your original proposal > that > > > required > > > > > the stub code to be changed. Since we have other options > that don't > > > require > > > > > any change to the stubs, I would prefer to adopt one of > these as the > > > solution. > > > > > > > > > > If waiting for an updated JDK isn't acceptable, we could > resolve > this by > > > > > saying that the object returned by _servant_preinvoke() must > implement > > > the > > > > > remote interface and can be used to call the servant > implementation. > > > This > > > > > allows it to either be the implementation itself, or a tie > that > contains > > > > > code to delegate remote method calls to the > implementation. This > > > approach > > > > > does put RMI-IIOP dependencies into the Java ORB, but > requires no > stub > > > or > > > > > JDK changes. > > > > > > > > > > I'd like to ask all RTF members to indicate their preference > for > solving > > > this. > > > > > The options are: > > > > > a. The ORB must ensure that the object returned by > _servant_preinvoke() > > > > > implements the remote interface and can be used to call > the > servant > > > > > implementation. > > > > > b. The JDK javax.rmi.CORBA.Stub class must be changed as I > proposed > > > earlier. > > > > > c. Some other proposal. > > > > > > > > > > IBM's preference is for a. > > > > > > > > > > Simon > > > > > > > > > > Michael Rumpf wrote: > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > I just found out that OpenORB uses a servant_preinvoke() > method > > > > > > internally to handle both cases, local and remote. In > order to > make > > > > > > the proposal for Issue4429 work I had to change the > behaviour a > > > > > > little bit, but this is all OpenORB internal and should > not affect > the > > > > > > latest suggestion. > > > > > > > > > > > > But I found two other possibilities which could be worth > thinking > of: > > > > > > > > > > > > 1. Add a servant_preinvoke method to the interface > > > > > > javax.rmi.CORBA.Stub. The implementation knows that > the > > > > > > return value is for RMI-IIOP only and calls > getTarget() on the > > > > > > Tie object returned by the ORB's servant_preinvoke. > > > > > > The problem I see with this approach is that the Stub > > > > > > class/interface is part of the JDK and it will be hard > > > > > > to guarantee that the correct version of the class is > loaded > > > > > > by the classloader. > > > > > > > > > > > > 2. Create the servant_preinvoke method above into the > > > > > > generated stub to avoid changing JDK > classes/interfaces. > > > > > > The problem with this approach is that the stubs need > to be > > > > > > regenerated. > > > > > > > > > > > > Michael > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Simon Nash" > > > > > > To: "Michael Rumpf" > > > > > > Sent: Montag, 15. Oktober 2001 19:05 > > > > > > Subject: Re: Issue 4429 (Java to IDL Mapping) > > > > > > > > > > > > > Michael, > > > > > > > The servant_preinvoke() call is only intended to be > called for > > > locally > > > > > > optimized > > > > > > > invocations. I don't understand how it could return a > servant > for a > > > > > > non-local > > > > > > > call, since in this case the servant will be in some > other > process > > > or > > > > > > machine. > > > > > > > > > > > > > > Simon > > > > > > > > > > > > > > Michael Rumpf wrote: > > > > > > > > > > > > > > > > FYI, problem with the discussed solution to Issue4429 > ! > > > > > > > > > > > > > > > > I just noticed that servant_preinvoke() is called also > for the > > > non-local > > > > > > > > case. In the non-local case the return ServantObject > must > contain > > > a > > > > > > Servant > > > > > > > > and not the implementation of an interface. > > > > > > > > > > > > > > > > I'm currently not sure whether this is an > implementation > detail of > > > > > > OpenORB > > > > > > > > or whether it is common bevaviour. If the latter is > the case > then > > > our > > > > > > > > solution must check whether the call was a locally > optimized > call > > > and we > > > > > > > > must invoke getTarget() only in this case... Some > signs point > into > > > the > > > > > > > > direction that the call to preinvoke for remote > requests is a > > > special > > > > > > > > behaviour of OpenORB, the JavaDoc comment is > "Preinvoke a > local > > > > > > operation. A > > > > > > > > successfull call is always paired with a call to > > > servant_postinvoke." > > > > > > > > > > > > > > > > Michael > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Simon Nash" > > > > > > > > To: "Michael Rumpf" > > > > > > > > Cc: "Jerome DANIEL" ; > > > ; > > > > > > > > ; > > > > > > > > Sent: Sonntag, 14. Oktober 2001 19:55 > > > > > > > > Subject: Re: Issue 4429 (Java to IDL Mapping) > > > > > > > > > > > > > > > > > Michael, > > > > > > > > > Thanks for sending this. At present it seems that > ORBs have > > > solved > > > > > > this > > > > > > > > > problem in one of two ways: > > > > > > > > > a. servant_preinvoke() returns an RMI-IIOP > implementation > > > instead of > > > > > > an > > > > > > > > > RMI-IIOP tie. > > > > > > > > > b. servant_preinvoke() returns an RMI-IIOP tie, but > this > tie > > > > > > implements > > > > > > > > > the remote interface (MyItf in your example) and > contains > > > code to > > > > > > > > delegate > > > > > > > > > method calls made through this interface to the > > > implementation. > > > > > > > > > > > > > > > > > > I think both of these are valid approaches that > should > continue > > > to be > > > > > > > > allowed. > > > > > > > > > The first is more efficient, but requires the ORB to > have > > > knowledge of > > > > > > > > RMI-IIOP > > > > > > > > > so that it can treat RMI-IIOP Ties as servants > specially. > I'm > > > not > > > > > > quite > > > > > > > > sure > > > > > > > > > why you think this is a bad idea. RMI-IIOP is a > mandatory > part > > > of > > > > > > CORBA > > > > > > > > 2.3 > > > > > > > > > and above and all Java ORBs must support it in order > to be > > > > > > > > CORBA-compliant. > > > > > > > > > However, I'm open to finding an alternative solution > that > avoids > > > the > > > > > > need > > > > > > > > > for putting this special case in the ORB. > > > > > > > > > > > > > > > > > > Changing the generated stub code (your option 1) is > > > problematical > > > > > > because > > > > > > > > it > > > > > > > > > means that for ORBs that currently use approach a > above, old > > > stubs > > > > > > won't > > > > > > > > work > > > > > > > > > with the new runtime or vice versa. This is a major > issue > for > > > > > > customers > > > > > > > > who > > > > > > > > > have a large number of applications already deployed > (including > > > > > > generated > > > > > > > > stub > > > > > > > > > code) and aren't able to upgrade their runtime as > well as > all > > > their > > > > > > > > deployed > > > > > > > > > applications at the same time. > > > > > > > > > > > > > > > > > > Your option 2 is a clever idea that leaves the stubs > unchanged. > > > I'd > > > > > > like > > > > > > > > to > > > > > > > > > propose a minor change to your code for > compatibility with > ORBs > > > that > > > > > > > > currently > > > > > > > > > use approach a above. Here's my modified version: > > > > > > > > > public ServantObject _servant_preinvoke(String > operation, > > > Class > > > > > > > > expectedType) { > > > > > > > > > ServantObject so = > super._servant_preinvoke(this, > > > operation, > > > > > > > > expectedType); > > > > > > > > > if (so.servant instanceof javax.rmi.CORBA.Tie) > > > > > > > > > so.servant = > > > ((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > > > > > > > > return so; > > > > > > > > > } > > > > > > > > > This works no matter whether the ORB returns the Tie > or the > > > > > > implementation > > > > > > > > object. > > > > > > > > > > > > > > > > > > I think this is the best solution. It is compatible > with > > > existing > > > > > > stubs > > > > > > > > and > > > > > > > > > existing ORBs (no matter which approach they have > adopted) > and > > > solves > > > > > > the > > > > > > > > problem > > > > > > > > > of ORBs being unable to return the CORBA servant > (RMI-IIOP > tie) > > > within > > > > > > the > > > > > > > > > ServantObject. > > > > > > > > > > > > > > > > > > If there are no objections to this solution, I will > write up > a > > > formal > > > > > > > > proposal > > > > > > > > > for voting. > > > > > > > > > > > > > > > > > > Simon > > > > > > > > > > > > > > > > > > Michael Rumpf wrote: > > > > > > > > > > > > > > > > > > > > Sorry for including you all on the list of > recipients, but > the > > > Issue > > > > > > > > archive > > > > > > > > > > indicates your interest on the topic. > > > > > > > > > > > > > > > > > > > > I stumbled over the same problem which has been > reported > by > > > Jerome > > > > > > > > Daniels > > > > > > > > > > as an issue a few months ago: > > > > > > http://cgi.omg.org/issues/issue4429.txt. > > > > > > > > The > > > > > > > > > > discussion on the issue seems to got stuck and I > would > like to > > > > > > resolve > > > > > > > > it... > > > > > > > > > > > > > > > > > > > > Problem summary: > > > > > > > > > > ---------------------------------------- > > > > > > > > > > > > > > > > > > > > public class _MyItf_Tie > > > > > > > > > > extends org.omg.PortableServer.Servant // no > further > base > > > > > > classes > > > > > > > > > > implements javax.rmi.CORBA.Tie // > derived > from > > > > > > > > InvokeHandler > > > > > > > > > > { > > > > > > > > > > public void hello(); > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > The Tie does not have the interface MyItf in its > derivation > > > graph, > > > > > > > > instead > > > > > > > > > > the interface is stored in the target member of > the class > and > > > can be > > > > > > > > > > accessed by the methods get/setTarget(). > > > > > > > > > > > > > > > > > > > > The Java to IDL Mapping spec. provides code > snippets for > local > > > > > > > > invocation > > > > > > > > > > optimizations on 1-49 (01-06-07.pdf, 1.5.2.2 Local > Stubs) > or > > > on 1-47 > > > > > > > > > > (99-07-59.pdf, 1.5.2.2 Local Stubs). Point number > three > seems > > > to > > > > > > provide > > > > > > > > a > > > > > > > > > > wrong cast: > > > > > > > > > > > > > > > > > > > > "3. If _servant_preinvoke returned a non-null > ServantObject > > > so, call > > > > > > > > > > ((Aardvark)so.servant).echo(x)" > > > > > > > > > > > > > > > > > > > > The ORB's _servant_preinvoke() method returns an > object of > > > type > > > > > > > > > > ServantObject: > > > > > > > > > > > > > > > > > > > > public class ServantObject { > > > > > > > > > > public java.lang.Object servant; > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > The servant member of ServantObject actually > stores Tie > > > objects > > > > > > because > > > > > > > > the > > > > > > > > > > Tie's base class org.omg.PortableServer.Servant > qualifies > a > > > Tie as > > > > > > > > servant. > > > > > > > > > > But in this case the cast: > > > > > > > > > > > > > > > > > > > > ((MyItf)so.servant).hello(); > > > > > > > > > > > > > > > > > > > > will fail with a ClassCastException ! > > > > > > > > > > > > > > > > > > > > You could argue that the type of the servant > member in > > > ServantObject > > > > > > is > > > > > > > > not > > > > > > > > > > org.omg.PortableServer.Servant but > java.lang.Object so > that it > > > could > > > > > > > > hold > > > > > > > > > > any type, even the interface, is correct, but.... > > > > > > > > > > > > > > > > > > > > In this case you would have to add some code to > check for > > > instances > > > > > > of > > > > > > > > type > > > > > > > > > > javax.rmi.CORBA.Tie into the ORB's > code. Especially into > > > > > > > > > > POA.servant_preinvoke. This means that you add > RMIoverIIOP > > > code into > > > > > > > > your > > > > > > > > > > ORB. I think that this is a bad > style. E.g. OpenORB's > > > RMIoverIIOP > > > > > > module > > > > > > > > is > > > > > > > > > > developed as an extension that can be plugged > under the > ORB > > > in a > > > > > > > > totally > > > > > > > > > > transparent way (and I guess that is one of the > retionale > > > behind the > > > > > > > > > > RMIoverIIOP spec. in general). So mixing up the > ORB's code > > > with > > > > > > > > RMIoverIIOP > > > > > > > > > > stuff should be a non-issue... > > > > > > > > > > > > > > > > > > > > I can think of two possible solutions then: > > > > > > > > > > > > > > > > > > > > 1. Jerome's proposition by changing the code to > get the > target > > > > > > object > > > > > > > > from > > > > > > > > > > the Tie: > > > > > > > > > > > > > > > > > > > > > ((MyItf)((_MyItf_Tie)_so.servant).getTarget()).hello(); > > > > > > > > > > > > > > > > > > > > 2. Add a _servant_preinvoke method to the abstract > Stub > class > > > > > > > > > > (javax.rmi.CORBA.Stub) so that preinvoke can > return > the > > > target > > > > > > as > > > > > > > > the > > > > > > > > > > servant > > > > > > > > > > member of the ServantObject instead of the > Tie. > > > > > > > > > > > > > > > > > > > > public ServantObject > _servant_preinvoke(String > > > operation, > > > > > > > > > > Class expectedType) { > > > > > > > > > > ServantObject so = > > > > > > > > super._get_delegate().servant_preinvoke(this, > > > > > > > > > > operation,expectedType); > > > > > > > > > > so.servant = > > > > > > > > > > > > > (java.lang.Object)((javax.rmi.CORBA.Tie)so.servant).getTarget(); > > > > > > > > > > return so; > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > In my eyes one of the two solutions would be the > cleanest > way > > > to go. > > > > > > I > > > > > > > > didn' > > > > > > > > > > try the second one but I don't think there are any > other > > > > > > implications. > > > > > > > > The > > > > > > > > > > first one looks even better because no interface > change > for > > > > > > > > > > javax.rmi.CORBA.Stub is necessary. And by the way > that is > the > > > one I > > > > > > > > > > implemented as a workaround for OpenORB's > RMIoverIIOP > module > > > and it > > > > > > > > works > > > > > > > > > > perfectly ;-) > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Michael Rumpf > > > > > > > > > > > > > > > > > > > > PS: I'm not an OMG member so I'm not sure whether > this > mail > > > reaches > > > > > > the > > > > > > > > RTF > > > > > > > > > > mailing-list. If not could someone please forward > it > there... > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Simon C Nash, Chief Technical Officer, IBM Java > Technology > > > > > > > > > Tel. +44-1962-815156 Fax +44-1962-818999 > Hursley, > England > > > > > > > > > Internet: nash@hursley.ibm.com Lotus Notes: Simon > Nash@ibmgb > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Simon C Nash, Chief Technical Officer, IBM Java > Technology > > > > > > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, > England > > > > > > > Internet: nash@hursley.ibm.com Lotus Notes: Simon > Nash@ibmgb > > > > > > > > > > > > > > > > > -- > > > > > Simon C Nash, Chief Technical Officer, IBM Java Technology > > > > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, > England > > > > > Internet: nash@hursley.ibm.com Lotus Notes: Simon > Nash@ibmgb > > > > > > > > > > > > -- > > Simon C Nash, Chief Technical Officer, IBM Java Technology > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb